AI can turn security fixes into working exploits before users receive an update
A · Strong evidence Epoch AI's benchmarking team documents a controlled, disclosed experiment in which a public open-weight model exploited six consecutive Firefox releases, with stated setup, costs, failures and safety measures; exploit details are withheld, so outsiders cannot reproduce it.
Summary based on the full text·Original: about 12 minutes to read
In short
An Epoch AI report (29 October 2026) by Aiden Ament, Yafah Edelman and four colleagues. GLM 5.3, an open-weight model released by Z.ai in August, read security fixes that Mozilla had published but not yet shipped, worked out which changes were security patches, and built a web page that, when visited in Firefox, read a local file and sent it to the attacker with no further user action. It succeeded on all six releases from 17 September to 26 October, at about $1,000 each once the harness was built. No provider refused or flagged the work.
Key numbers
- sixFirefox releases (September 17 to October 26) that GLM 5.3 compromised using the patch gap
- $1,000approximate marginal API cost to compromise each new Firefox version
- 12 hoursfastest successful exploit attempt, out of a 48-hour budget
- $100,000total API spend on Firefox research (exceeded), and roughly the same spent on failed Chrome attempts
As reported by the source.
English·Web page·opens epoch.ai
What it reports
- The "patch gap" is the window between a fix becoming public (in code, betas or nightly branches) and reaching users. Fixes are disguised as ordinary changes; the model identified them anyway.
- Successful attacks chained a patch-gap flaw (code execution in the content process) with an unpublished sandbox-escape flaw the model rediscovered on every attempt. Epoch disclosed it; Firefox 159.0 (27 October) patches it.
- The model diagnosed crashes, dropped failed approaches and built multi-stage chains without user input beyond the initial instruction.
- Time budget 48 hours; fastest success 12 hours. Total Firefox research spend exceeded $100,000; the marginal cost per version was about $1,000.
- Releases tested: 156.0 through 158.0.1. Code execution beyond file reads did not succeed.
- The same harness against Chrome failed after about $100,000 of attempts; the authors do not treat this as evidence Chrome is safe.
- Context cited: patch-gap exploits against Chrome in September 2026, and PHP patched builds published more than six hours before a coordinated release.
How they got it
An isolated cloud instance with no network access; the model received the target version, basic tools and the public information available at each release date. Access was through Z.ai's and third-party APIs, framed as a security exercise. A near-real-time monitor alerted researchers to risky behaviour; runs were paused once when broken environments let agents act outside the sandbox.
Limits
- One model, one browser; Chrome attempts failed.
- Success depended on a second, unpublished flaw that is now patched; results on 159.0 are unconfirmed.
- Exploit details are withheld, so the result rests on Epoch's account and Mozilla's response.
- Closed-source software was not tested.
Why it matters for companies
Open-weight models put patch-gap attacks within reach of low-skill attackers at the price of a laptop. For software vendors, the time a fix sits public before release is now an exposure window measured in hours. For every organisation, update speed becomes a security control: browsers, VPN clients, routers and phone fleets that lag a release are open targets. The authors' recommendations for vendors are concrete: keep fixes private until shipping, shorten beta-to-release, and avoid landing chainable fixes together.
Summary based on the full text. Read the original for the full argument and data.Read the original on epoch.ai