Epoch AI says an open model built exploits for six Firefox releases from public fixes
The controlled attacks needed an additional unpublished vulnerability, now patched. Mozilla is changing how it releases security fixes to make similar chains harder to assemble.
Epoch AI’s tests show that public fix information can help an open model turn a browser bug into a working exploit before a patched release reaches users. The successful Firefox attacks also required an unpublished sandbox-escape vulnerability, which GLM 5.3 rediscovered and Mozilla patched in Firefox 159.0 on October 27, 2026. The finding points to a disclosure-timing problem for browser makers, but does not establish that updated Firefox remains vulnerable or that Chrome can be exploited this way.
01
Epoch tested all six Firefox releases issued from September 17 through October 26, 2026, using information available when each version shipped.
02
GLM 5.3’s fastest successful attempt took 12 hours; researchers allowed up to 48 hours and provided an offline test environment.
03
The repeated-attack cost was measured after setup; Epoch’s Chrome attempts produced no equivalent exploit despite about $100,000 in API spending.
Security fixes are meant to protect users. Epoch AI’s October 29 research shows how they can also supply an AI attacker with clues: GLM 5.3 built working exploits for six Firefox releases before fixes reached stable users. In controlled tests, simply opening a model-built webpage caused the browser to read and transmit a local file.
The weakness is called the patch gap: a security fix becomes visible before it reaches users. Epoch studied the interval before general release, rather than people continuing to run old software afterward. Its experiments covered all six Firefox releases issued between September 17 and October 26, 2026, using only information available when each version shipped.
Mozilla’s response acknowledges the problem: GLM 5.3 can exploit some fixes for bugs originally found by more advanced models. That creates a route for attackers to benefit indirectly from the tools defenders received first.
From a public fix to local files
Epoch designed the experiment to approximate an attacker with limited technical experience and standard development tools. Researchers supplied a target Firefox version, basic tools and instructions to investigate upcoming fixes. They blocked internet access to avoid affecting third parties, instead providing the public information they thought the model would need. The offline environment was a researcher-built starting point, not something the model assembled entirely by itself.
After those instructions, GLM 5.3 worked without further user input. It identified security fixes, chose vulnerabilities and built multi-stage attacks. Epoch says the model recognized security-relevant changes even when fixes were disguised as ordinary improvements. Researchers allowed up to 48 hours; the fastest successful attempt took 12.
In one attempt, an upcoming fix revealed a flaw that let the model read and change browser memory. That alone did not give it access to the target file. The model diagnosed crashes, dropped failed approaches and added stages to get past the remaining protections. The successful attacks also depended on an unpublished vulnerability that bypassed the browser’s sandbox, a protective boundary limiting access to the computer.
GLM 5.3 rediscovered that unpublished vulnerability in each attempt against recent releases, Epoch says. The team disclosed it to Mozilla, which patched it in Firefox 159.0 on October 27. Epoch had not confirmed whether similar attacks could succeed against the updated version, but expected the patch to make them substantially harder.
Editorial illustration for Epoch AI says an open model built exploits for six Firefox releases from public fixes.Source: blog.mozilla.org.
The cost depends on where counting starts
The attention-grabbing price is the cost of repeating the attack against another Firefox version after the setup was ready. It is not the full bill for the research, which included preliminary experiments and building a realistic offline environment.
The provider safeguards did not interrupt the work. Epoch accessed GLM 5.3 through Z.ai and third-party APIs and framed the task as a security exercise. It reported no refusals or usage restrictions, while arguing that the technical actions were otherwise indistinguishable from an attempt to target real users.
The same approach did not produce an equivalent Chrome exploit, despite about $100,000 in API spending on those attempts. That is a meaningful limit on this experiment, not proof that Chrome is immune. Epoch cautions that different methods for directing the model, or more capable models, could produce another result. The comparison used the same test setup and techniques.
Mozilla wants to separate the ingredients
Mozilla’s October 29 response explains why simply eliminating the gap is difficult. Browser builds need at least a few days of testing before reaching hundreds of millions of people on different hardware. Users also do not update immediately. Mozilla says Firefox has already taken several steps to shorten the window or make published changes harder to exploit:
Weekly releases: Mozilla says it halved Firefox’s release cycle earlier this year so new builds reach users every week.
Confidential tests: It is holding back regression tests until fixes ship, after finding GLM 5.3 much less effective without those tests.
Commit scanning: It is checking new code changes for newly introduced bugs before they reach a release.
Its proposed structural defense uses the fact that compromising Firefox generally requires multiple vulnerabilities. In the simplest case, attackers need both a flaw in the part that processes webpages and a way out of its sandbox. Mozilla intends to group fixes so the exposure windows for different protective layers do not overlap. An attacker following public patches would then still need to find at least one additional vulnerability from scratch.
That change is planned, not a completed defense. Mozilla says coordinating the engineering process may take time, and it wants to avoid slowing security fixes. It also says Firefox will remain open-source. Its approach is therefore not to hide the whole codebase, but to control when particular clues and complementary fixes become available.
Editorial analysis
Our Read
These results suggest that restricting access to the most capable models cannot be the whole defense. A less capable system may not need to discover the hardest bugs if published fixes point it toward discoveries already made by stronger tools. That changes how to judge defensive AI programs: finding more flaws is only part of the job; safely delivering their fixes matters too. Mozilla’s proposed separation of fixes is a concrete test of that idea. The next evidence to watch is whether that release process can frustrate comparable attacks without slowing security updates.
Reader comments
Newest comments first. Replies stay oldest first.