AI Exploited the Gap Between a Firefox Fix and Its Release

A software team can finish a security fix and still leave its users exposed. If the repair becomes visible before it reaches the released product, it can also reveal where the unprotected version is weak.

In a report published October 29, Epoch AI tested whether GLM 5.3, a downloadable model from Z.ai, could turn that opening into an attack. In an isolated experiment, it built attacks against six Firefox releases that read a file from the test computer when a specially prepared webpage was visited. Every successful attack also depended on a separate, previously unpublished vulnerability. This was a laboratory result, not a report of attacks on Firefox users.

The finding matters because it concerns a period when keeping a browser up to date is not yet enough. The relevant repair has not shipped.

There Are Two Different Gaps in an Update

The familiar gap starts after an update becomes available. Someone delays installing it, a business needs to test it, or a device stops receiving support. The fix exists, but the running software does not have it.

Epoch investigated an earlier gap: a change becomes visible in public development work before it reaches the version most people use. Developers may need time to test a change before distributing it widely. During that interval, the repair can become a clue to the weakness it is meant to remove.

This is not a newly discovered property of open-source software. The new evidence concerns who can do the work of turning the clue into a working attack. It also differs from the question in our earlier GLM 5.3 benchmark analysis, where different scoring rules produced misleadingly comparable percentages. Here, the researchers tested a concrete outcome against specific browser releases.

The Agent Worked Alone Inside a Human-Built Test

Epoch targeted six Firefox releases from September 17 through October 26. The test machines ran Ubuntu 26.04 with default security settings. The model had no internet access. Researchers supplied the materials it could use, restricting them to information available when each browser version was released.

Once given the task and environment, the agent selected approaches, tested its work and changed direction without further human instructions. In the successful tests, visiting its webpage was enough to read and transfer the target file without another user action.

That is a consequential result, but “autonomous” does not mean nobody prepared the experiment. People built the environment, chose the objective and arranged the resources. Nor did the demonstration establish unrestricted control over the computer: Epoch says it had not achieved general execution of arbitrary code on recent Firefox releases.

The additional unpublished vulnerability is equally important. These successes were not produced solely from fixes already visible to everyone. That second weakness helped the attacks cross a further security boundary.

The $1,000 Figure Is Not the Whole Cost

Epoch reports spending more than $100,000 in API charges on its Firefox research, including preliminary work and the offline test environment. After that setup, the extra model-service cost to compromise another tested Firefox version was about $1,000.

Those figures answer different questions. The smaller one describes repeating an established workflow; the larger one includes getting that workflow to work. Treating $1,000 as the full cost would erase the preparation.

There was also a meaningful failure. Epoch spent about $100,000 trying a similar approach against Chrome without obtaining an equivalent result. That does not prove Chrome cannot be attacked this way, but it prevents the Firefox successes from becoming a claim about every browser.

A Fix Has Shipped, but the New Outcome Is Unconfirmed

Epoch says it disclosed the unpublished vulnerability to Mozilla and that Firefox 159, released October 27, fixed it. Mozilla’s advisory independently confirms a security release for Firefox 159 on that date. It does not independently verify Epoch’s experiment or identify the particular vulnerability as Epoch’s finding.

At publication, Epoch had not established whether a similar attack would succeed against version 159. Its expectation that the repair makes the task harder is not a measured result on the updated browser.

Installing available security updates still matters. The distinction is that users cannot install a repair that has not been released. That part of the problem belongs to the software release process, not to someone ignoring an update notification.

Our PHP repair explainer follows the later journey from a released patch to a running website. Epoch’s experiment exposes the earlier handoff. Finding and fixing a flaw are not the finish line: the protection has to reach the product people can actually use before the repair itself becomes useful to an attacker.