The patch gap across six Firefox releases: what the GLM study does and does not prove

Epoch AI published a study on 29 October 2026 that operators of a Firefox estate should read to the end. The open-weight model GLM 5.3 built working attacks on Firefox out of security fixes that were published but not yet shipped, across six releases and for around 1,000 dollars per version.

The value of the study is not that number. It is the chain Epoch supplies along with it, including the points that argue against its own headline. That chain is worked through here, separated into what the primary source supports and what it does not. The patch gap is nothing new; what is new is who it now reaches.

What stays open, I will say plainly. Epoch has published neither the harness code nor the dataset, and Mozilla's four countermeasures are vendor statements on its own blog, one of them written as an intention. What matters for us is the update policy.

What happens when a page gets visited

The demonstration is a single page visit. A user opens the page, the page then reads a local file and sends its contents to the attacker, with no further click. Epoch lists the consequences as harvested passwords, stolen authentication cookies and read private files. Firefox stands at over 200 million active users according to the study.

Two limits belong to that finding, and both come from Epoch. First, there is no code-execution success on current Firefox releases; the report states that word for word as of the time of writing. The demonstrated harm is file contents being read. Second, every successful attack needed a second, previously undisclosed vulnerability, a sandbox bypass. Without it the attack fails. Epoch reported that gap; it is closed in Firefox 159.0 of 27 October 2026.

The second row explains the strategy Mozilla described shortly after, and it is the reason I would not read the six releases as "Firefox is attackable for six weeks".

The two cost figures people mix up

Around 1,000 dollars is the marginal compute cost per successful version, and only after the environment existed. Epoch puts total Firefox spend at over 100,000 dollars, and the Chrome attempts at another 100,000 or so without the same result.

The 1-to-100 ratio in some headlines only holds against the marginal cost per version. Spread the total of over 100,000 dollars across the six versions and it is more than 16,000 dollars per version. Epoch's own reading belongs here too: the group explicitly does not treat the Chrome failures as evidence that such attacks would not succeed there.

Epoch measures a hard limit of 48 hours per attempt; the fastest successful approach needed 12 hours, with no human input after the initial brief.

What the countermeasure already did, and what it did not

Firefox disguises published security fixes as ordinary improvements so attackers cannot read them off the changeset. The study records that GLM 5.3 defeated that disguise: the model read the code and decided which changes were security patches. The mechanism keeps working, just with more effort on both sides.

Epoch publishes neither code nor dataset; the bibliographic entry lists the publication page itself as the URL. That makes the count of six releases impossible to reproduce independently. The timeline is reproducible, and I measured it myself on 1 November 2026.

The two Debian rows are the uncomfortable ones in that chart, because they concern a distribution we run in-house. The ESR line is why I do not apply the 14-day cadence to workspace machines.

Cadence, measured rather than recounted

On 1 November 2026 the machine-readable file firefox_versions.json on product-details.mozilla.org shows LATEST_FIREFOX_VERSION 159.0, FIREFOX_ESR 153.6.0esr and FIREFOX_ESR115 115.44.0esr, plus LAST_RELEASE_DATE 27 Oct 2026 and NEXT_RELEASE_DATE 06 Nov 2026. The release notes give 18 August, 1, 15 and 29 September, and 13 and 27 October. The main releases from 155.0 to 159.0 ship at a fixed 14-day interval, and the point releases 156.0.1, 157.0.1 and 158.0.1 follow seven days after their main release, on 22 September, 6 and 20 October.

Between 156.0 on 15 September and 159.0 on 27 October lie 42 days, my own difference from those two release dates. Epoch's own window, 17 September to 26 October, is 39 days: it starts two days after 156.0 and ends one day before 159.0.

For managed estates the ESR line is the real case, and it trails. In the measured state the main line sits at 159.0, ESR at 153.6.0esr. On the Debian branch the first firefox-esr security package for Debian 13 was reported on 3 October 2026, and the ESR publications 153.5.0, 153.5.1 and 153.6.0 reached Debian together in DSA-6590-1 on 28 October. Whoever sits on a distribution inherits its rhythm.

One counting change is worth knowing before reading "167 fixes" as an explosion: Mozilla stopped bundling memory-safety issues into a single umbrella CVE. The Firefox 159.0 advisory lists 167 CVEs, 108 of them rated high. So the method changed alongside the number.

What Mozilla is doing about it, and how much of it holds

Mozilla answered the same day on its own blog with four measures. The main line moved to weekly shipping, roughly halving cycle time. Regression tests stay under embargo until after the fix ships; without them, Epoch observed GLM 5.3 to be markedly weaker. Every new commit gets scanned. And the windows for renderer fixes and sandbox fixes are to be separated, so the two components of a browser attack never sit in the same window.

The last measure is the most interesting because it attacks the second row of the chain, but it is a declaration of intent: Mozilla writes that it will apply the approach. The other three are likewise vendor statements from a party describing its own prospects: more than seven times as many security fixes as in the comparable 2025 period, attacker models some generations behind, a finite stock of gaps. I know of no independent measurement of any of that.

What scepticism is circulating does not survive checking. The Hacker News thread, 13 points and 9 comments, contains no methodological objection; a Mozilla employee discusses the study's limitations there but disputes no result. The sharpest caveats about this study are inside the study.

What we measured and what follows from it

We do not quote a Firefox figure from our own fleet here, because we did not measure one for this post. For operators this is a question of update policy rather than of inventory anyway. What we do run through regularly on our own stack is the sequence from advisory to rolled-out state, for example on the PHP patch day or the LiteLLM supply-chain incident. Our yield from this study is a rule for our own policies.

The browser client counts like a server

The demonstration in this study needs no exploit against a server entrance, only one page visit. A browser on a company laptop is therefore run like a service: with a shipping date, an owner and a deadline.

A short cadence only if it actually rolls out

The halved cycle time at the vendor is wasted if the distribution or a policy branch does not follow. We measured that gap on the two Debian rows above.

Two components instead of one switch

Where an attack needs a renderer bug plus a sandbox escape, a branch that catches both is a strong lever. Anyone running sandboxing on clients should keep it current, otherwise exactly the component that makes the difference stays unpatched.

Read the count together with the method

A figure like 167 CVEs is a method change without the counting rule, not a state. That applies to our own reports just as much.

Further reading

• epoch.ai/publications/open-weight-models-patch-gap
• epochai.substack.com/p/glm-patch-gap-exploit-firefox
• blog.mozilla.org/en/firefox/privacy-security/defending-patch-gap
• product-details.mozilla.org/1.0/firefox.json
• lwn.net/Articles/1100702
• lwn.net/Articles/1103614
• mozilla.org/en-US/firefox/153.0/releasenotes
• ubuntu.com/security/notices/USN-8501-1
• anthropic.com/research/n-days
• proofpoint.com/us/blog/threat-insight
• news.ycombinator.com/item