AI exploits in the Firefox patch gap: what Epoch AI shows

A security fix can be publicly visible while the regular browser release does not yet contain it. Epoch AI investigated exactly this window using an AI model. Its report, published on 29 October 2026, demonstrates successful file access through six Firefox releases available at the time.

A second detail is essential to interpreting the findings today: the experiments also required a previously unpublished vulnerability. According to Epoch, it was fixed in Firefox 159, released on 27 October. The research therefore establishes neither an ongoing wave of attacks nor that every Firefox version in use today can be attacked in the same way. Editorial cut-off: 30 October 2026.

Key points

• The research examined the period between a publicly visible fix and an update’s general release.
• The demonstrated harm was reading and transferring a local file when a user visited a malicious webpage.
• The additional, then-unpublished component of the exploit chain has since been patched, according to the researchers.
• Approximately US$1,000 refers to marginal API costs after the experimental environment had been built; total Firefox research API spending exceeded US$100,000.

The gap starts before the regular update

The Epoch report examines a particular part of the patch gap: a correction can already be identified in public development builds, but has not yet reached the generally available product release. Attackers can read the change as a clue to where the existing release remains vulnerable.

This differs from the later period between an update’s release and its actual use on an endpoint. Both windows can matter, but they have different owners and require different responses.

This distinction prevents a common reasoning error: a published correction represents progress in development. Its protective effect on a particular system needs to be established separately.

What the model actually achieved

Epoch used GLM 5.3, a model with publicly available weights. The researchers provided an isolated environment and information already available when each target version was released. The model had no internet access during the experiments.

The six releases examined from 17 September through 26 October were 156.0, 156.0.1, 157.0, 157.0.1, 158.0 and 158.0.1. According to the report, testing used Ubuntu 26.04 with default settings and Firefox obtained from the official release. After the setup, the model independently developed exploit chains in which visiting a webpage caused a local file to be read and transferred.

This is a controlled research demonstration. It is not a statistic about users actually attacked, Windows installations, every browser or arbitrary enterprise environments. According to the report, the researchers did not achieve arbitrary code execution on the computer beyond this in recent Firefox releases. Their Chrome experiments had also produced no equivalent exploit by the time of publication.

The negative Chrome result is not a security guarantee either. It describes the experimental setup and the results achieved up to that point.

Firefox 159 changes the state that was tested

The successful chain did not rely solely on publicly identifiable fixes. Access to files outside the browser’s normally enforced isolation required another vulnerability that was unpublished at the time. Epoch reported it to Mozilla and states that it was fixed in Firefox 159.

The Mozilla release notes date its general release to 27 October 2026. Security advisory MFSA 2026-118 documents the security issues fixed in Firefox 159. We do not infer a definitive mapping between Epoch’s finding and a particular CVE listed there.

At publication, Epoch had not confirmed whether a comparable chain would succeed against version 159. A claim that “all current Firefox releases can be taken over for US$1,000” would therefore be inaccurate. Equally, the sources do not support a claim that “this update rules out every conceivable patch-gap attack.”

Why the cost figure needs context

Approximately US$1,000 refers to additional API costs per successfully attacked Firefox version after the researchers had built their environment and developed the approach. Total Firefox API spending, including preparation and preliminary experiments, was more than US$100,000.

The smaller figure therefore indicates the cost of further attempts under the conditions established. It is not a complete project budget or a universal price for a successful attack. Conversely, the substantial setup effort does not erase the result’s significance: an established process can be used repeatedly. The research did not comprehensively measure how easily other actors could reproduce it.

Our assessment: three states instead of one green patch ticket

For IT leaders, the research shows why the status “patch available” says little on its own about residual risk in a particular environment. A development team may have completed a correction, the vendor may have shipped it, and a company may already have distributed it. These are three different statements.

Vendors face a trade-off between reviewable changes, sufficient testing and prompt release. Faster release cannot justify arbitrarily sacrificing operational quality. The study also does not establish a blanket case for closing source code or abandoning open development processes.

Operators benefit from a precise completion criterion. When a browser update is marked complete, it should be clear whether that means package approval, successful distribution or the version actually in use. Mozilla notes for directly downloaded Firefox installations that updates are applied after a restart. Linux package management and the Microsoft Store have their own distribution paths. An available download therefore answers only part of the operational question.

An exception should remain connected to the affected systems: which devices or services are still outstanding, who owns the decision and when will it be reviewed? An exception without a link to a specific system can later be difficult to distinguish from a forgotten task. A justified delay also needs a verifiable end.

The origin of the finding should remain visible as well. A vendor advisory, demonstrated exploitation in a research setup and confirmed access within the organization require different work. That distinction is just as important as in the testmetest findings involving armed GitHub repositories: a technical finding starts the organization’s own scoping work; it is not a ready-made victim statistic.

Kopexa can connect affected assets with risks, measures, owners and verification evidence. Software distribution and technical version checks remain with the operational tools used for those tasks. What matters is that the responsible teams can jointly trace outstanding systems, exceptions and the completion check.

The new finding in Epoch’s report concerns the combination of visible corrections and automated analysis. For organizations, it leaves a concrete leadership task: the period between “fix known” and “protection verified on the system” must not disappear into an ambiguous status.