www.it-connect.fr
Mozilla Delays Firefox Patches to Stop AI from Turning Them into Exploits
A visible fix in the code, but not yet on your machines: a gap that AI can now exploit in Firefox. Mozilla is fighting back. Here’s how.
Through Bobby Holley, Mozilla has unveiled its new strategy to deal with what is known as the patch gap. The term is not new: it refers to the window between a security fix appearing in the code and its deployment to the majority of users. During that interval, an attacker can study the change, work backward to the flaw, and target unpatched installations.
If Mozilla is thinking about this issue, it’s no coincidence: AI is changing the game when it comes to the patch gap. In the past, this technique required strong technical skills and, above all, speed. According to Mozilla, models such as GLM 5.3 can exploit certain security fixes discovered by more advanced models.
As a reminder, since February, the Firefox team has been tracking security flaws with Anthropic and OpenAI models, which has led to a surge in the number of security patches. The downside? Every published fix reveals the location of the flaw... and that is especially true when the code is open source.
In parallel with Mozilla’s announcement, an Epoch AI study highlighted the problem. GLM 5.3, an open-weight model from Z.ai released in August, made it possible to compromise 6 Firefox versions ranging from 156.0 to 158.0.1, based on public patches that had not yet been shipped. These findings still came at a cost estimated at $1,000 per version, and 12 hours of AI work for the fastest attempt. But the result was a zero-day exploit in Mozilla Firefox, which is no small matter. This becomes even more significant when simply visiting a booby-trapped page was enough to exfiltrate a local file. "We triggered no guardrails or refusals from any provider, including Z.ai, by using GLM 5.3 in this way.", the researchers noted.
Never deliver both pieces of the puzzle at the same time
The Firefox browser relies on multiple layers of sandboxing. In practical terms, that means an attacker must chain at least two flaws in the simplest case: one to execute code in the renderer process (the renderer, which runs web content) and one sandbox escape. A single flaw is not enough to compromise the system.
Mozilla wants to use this to counter the patch gap. Here is the chosen approach: delay the release of patches by defense layer, so that the patch gaps of the different layers never overlap. "At any given time, only one of the multiple ingredients needed to compromise the browser would be available in the patch gap.", Bobby Holley explains. The attacker would then have to find at least one new flaw on their own.
This diagram proposed by Mozilla makes the logic clear:
That said, putting this into practice is not straightforward because it requires coordination across Mozilla’s engineering processes, and it could take time.
What has already changed, and what it means for you
In the meantime, Mozilla has already taken some steps:
- Weekly builds: as a reminder, Mozilla cut its cycle in half this year. Major releases now ship every two weeks, as I explained this summer, with a fix release in between.
- Regression tests: Mozilla keeps them confidential again until the fix is delivered, and GLM 5.3 is far less effective without them.
- Scanning every commit: every code change is analyzed to detect bugs introduced before they reach the stable release.
And no, Firefox will not close its code. "Firefox is proudly open source and we have no intention of changing that.", the vendor says, for whom hiding the source code would at best only slow down reverse-engineering tools.
On the enterprise side, the patch gap has a second dimension: endpoints that are slow to update. Here, the responsibility is yours. Make sure your fleet is at least on Firefox 159.0.1, released on November 3 (ESR 153.6 or 115.44 for the ESR channel, see Mozilla’s security advisories).
Finally, Mozilla’s thinking around the patch gap is both legitimate and relevant. Other vendors are certainly asking themselves the same questions.
What do you think?
