The renderer (called ContentProcess in Firefox) is the process that's interacting with untrusted web content, so this is the process you would initially have to compromise. But that process is heavily sandboxed (can't just read files or run unsandboxed code), so in order to break out of that, you need a second exploit in one of the higher privileged processes.
There are some heavy limitations worth highlighting here.
Firefox compromises also depended on a separate, previously unpublished vulnerability. Mozilla patched that vulnerability in Firefox 159.0 on October 27, 2026.
The researchers were unable to reproduce comparable results against Chrome, despite spending roughly $100,000 testing it.
Closing the patch gap completely is unfortunately impossible.
One strategy that can help in the meantime is to make sure that we never have fixes for both renderer vulnerabilities and sandbox escapes in one patch gap at the same time. That's a new strategy we're working on right now.
The problem is also only relevant as long as security vulnerabilities still make it into release. The models are getting better and better at finding the pre-existing ones as well as newly introduced ones by commit scanning (which never make it to release then).
The article doesn't establish whether AI ultimately benefits attackers more than defenders. Open weight models give defenders access to the same capabilities. At the very least the community has a level of symmetry they wouldn't otherwise have.
Right now, we are in this transition phase where models discovers tons of latent bugs everywhere. That makes it easier for attackers of course to find a single bug, and lots of fixes means lots of things to reverse-engineer in the patch-gap. But that won't be going on forever, as the number of bugs to find here are finite. Assuming that we use the same models/techniques to scan all commits being made, we'll end up with a codebase that is much much safer than what we had before.
Excluding the modern equivalent of a script kiddie, even a "budget" attacker will have for sure invested enough to run a serious model (GLM 5.3 in this case, which requires hundreds of GB of RAM).
On the other hand - the defense - there is a large spectrum, and that's where the problem lies. There are surely companies that can defend themselves (either via cloud solution with granted cyber capabilities, or on local powerful machines), but there is a large amount of people that don't even know how to run a local LLM, let alone compile a program like Firefox.
We put out something that describes our new approach to handle the patch gap: https://blog.mozilla.org/en/firefox/privacy-security/defendi...
Thank you for the link. Could you explain why an attacker needs an exploit in both the renderer and sandbox? Why is an RCE in just one not game over?
The renderer (called ContentProcess in Firefox) is the process that's interacting with untrusted web content, so this is the process you would initially have to compromise. But that process is heavily sandboxed (can't just read files or run unsandboxed code), so in order to break out of that, you need a second exploit in one of the higher privileged processes.
There are some heavy limitations worth highlighting here.
Firefox compromises also depended on a separate, previously unpublished vulnerability. Mozilla patched that vulnerability in Firefox 159.0 on October 27, 2026.
The researchers were unable to reproduce comparable results against Chrome, despite spending roughly $100,000 testing it.
What is the solution implied here? Attackers - whoever they are - already have them, so perhaps it's time we close the patch gap instead.
Closing the patch gap completely is unfortunately impossible.
One strategy that can help in the meantime is to make sure that we never have fixes for both renderer vulnerabilities and sandbox escapes in one patch gap at the same time. That's a new strategy we're working on right now.
The problem is also only relevant as long as security vulnerabilities still make it into release. The models are getting better and better at finding the pre-existing ones as well as newly introduced ones by commit scanning (which never make it to release then).
The article doesn't establish whether AI ultimately benefits attackers more than defenders. Open weight models give defenders access to the same capabilities. At the very least the community has a level of symmetry they wouldn't otherwise have.
Ultimately, I would say it favors the defenders.
Right now, we are in this transition phase where models discovers tons of latent bugs everywhere. That makes it easier for attackers of course to find a single bug, and lots of fixes means lots of things to reverse-engineer in the patch-gap. But that won't be going on forever, as the number of bugs to find here are finite. Assuming that we use the same models/techniques to scan all commits being made, we'll end up with a codebase that is much much safer than what we had before.
It depends on who attacker and defender are.
Excluding the modern equivalent of a script kiddie, even a "budget" attacker will have for sure invested enough to run a serious model (GLM 5.3 in this case, which requires hundreds of GB of RAM).
On the other hand - the defense - there is a large spectrum, and that's where the problem lies. There are surely companies that can defend themselves (either via cloud solution with granted cyber capabilities, or on local powerful machines), but there is a large amount of people that don't even know how to run a local LLM, let alone compile a program like Firefox.