Epoch AI reports that GLM 5.3 built webpages that read and transmitted a local file when visited in six Firefox releases. Its October 29 research used publicly visible security fixes that had yet to reach the tested release. That interval is the patch gap.

Evidence status: researcher-reported controlled demonstrations, not reported attacks on users. The tested environment was Ubuntu 26.04 with default security settings and official Firefox builds. The report does not establish equivalent results on Windows, macOS or every Firefox distribution.

Epoch says Firefox 159.0, released October 27, patches an additional, previously unpublished vulnerability used in the chains. Mozilla’s advisory confirms security fixes in Firefox 159. Epoch had not established whether equivalent attacks could succeed against that release.

Reading a fix exposed only part of the chain

The tested versions were 156.0, 156.0.1, 157.0, 157.0.1, 158.0 and 158.0.1, released between September 17 and October 26. Epoch supplied information available when each version shipped. The model worked offline with prepared resources and tools, rather than freely browsing the internet.

The chains combined two kinds of weakness:

  • A renderer flaw, affecting the process that handles webpage content. An upcoming fix helped the model find and exploit it.
  • A separate, unpublished sandbox weakness, bypassing the boundary that normally prevents a compromised webpage process from reading local files.

The resulting demonstration read a file and sent its contents away without further interaction after visiting the page. Epoch reports no success achieving arbitrary system-level code execution on recent Firefox releases. Execution within a renderer and unrestricted execution on the computer are different outcomes.

The setup also matters to the cost claim. Roughly $1,000 per Firefox version was the marginal API cost after building the environment. Total Firefox research spending exceeded $100,000. Attempts ran for up to 48 hours, with the fastest success taking 12 hours.

Epoch also spent roughly $100,000 attempting an equivalent Chrome result without succeeding. That bounds this experiment; it cannot certify Chrome’s safety or measure the net advantage these models give attackers over defenders.

Mozilla wants to keep the ingredients from lining up

Bobby Holley’s October 29 Mozilla response describes defenses already in use: weekly releases, withholding regression tests until fixes ship, and scanning incoming code for new bugs. Mozilla says GLM 5.3 was less effective when the tests were unavailable.

Mozilla also plans to separate the patch gaps for renderer fixes and sandbox-escape fixes. If both ingredients are visible before users receive them, an attacker can work backward from both. Separating their release windows aims to force discovery of at least one additional flaw from scratch.

That coordination is planned work, not an already-proven guarantee. The technique depends on layered isolation, and Epoch’s chains already needed a previously unpublished weakness. Faster releases and effective sandboxing remain complementary defenses.

Mozilla’s broader prediction that models may eventually find all software defects is an outlook, not a result established by these experiments.

Update the browser and verify the running release

For users on the tested release line, install Firefox 159.0 or a later supported security release, then restart the browser to activate it. For managed or distributor-provided builds, check that supplier’s security notice and deployed package; this study supplies no separate ESR fix matrix.

For release teams, measure the interval from a security change becoming visible to its deployment. Include packaging, staged rollouts and user restarts. A merged fix leaves exposed users waiting until a repaired build actually runs.

What the thread adds

In the ranked Hacker News discussion, mozdeco links Mozilla’s response and writes, “Closing the patch gap completely is unfortunately impossible.” Their reply to zb3 proposes keeping renderer and sandbox fixes out of the same gap.

The linked Mozilla article independently documents that plan. xscott’s reply asks why both flaws are needed: the sandbox exists precisely to contain a compromised renderer. These comments help explain the release strategy, without adding independent exploitation evidence.

From an 8-comment thread, in HN’s own order.

Caveat: Epoch reports its own experiments and Mozilla describes its own defenses. Neither source supplies a measured count of compromised users or proves that the next release eliminates this class of attack.