As described in our blog posts, our harness/pipeline only looks for crashes so all of the bugs resulting from that do have PoCs. There is a smaller number of bugs found by manual auditing that didn't have PoCs but I'd…
> But report [1] says that "Some of these bugs showed evidence of memory corruption...", which implies that majority of these (which includes 271 bugs from Mythos) don't have evidence at all. Do I not understand…
No, it's a new post, see also https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
No, we actually just posted a follow-up story with more details and opened several bugs, see also: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
Mythos did in fact write PoCs for all bugs that crash with demonstration of memory-unsafe behavior (e.g. use-after-free, out-of-bounds reads/writes, etc). For us this is substantial enough evidence to consider it a…
The bugs are at least of the same quality as our internal fuzzing bugs. They are either crashes or assertion failures, both of these are considered bugs by us. But they have of course a varying value. Not every single…
[working for Mozilla] That's because there were none. All bugs came with verifiable testcases (crash tests) that crashed the browser or the JS shell. For the JS shell, similar to fuzzing, a small fraction of these bugs…
[work at Mozilla] I agree that LLMs are sometimes wrong, which is why this new method here is so valuable - it provides us with easily verifiable testcases rather than just some kind of analysis that could be right or…
And the Firefox side of the story: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...
The infinite busy loop in this case was not the tab no (neither visible or invisible). The loop was directly in the network stack, as stated in the post, not in the caller.
> code that can end up blocking forever should have a timeout and recover from that timeout happening. There was no way for the calling code to do this. This was literally an infinite loop inside the network stack.…
All requests go through one socket thread, no matter which HTTP version. I am not a Necko engineer, but since requests can be upgraded, an HTTP/1 request could switch to HTTP/2 and if there was a separation by protocol,…
> the fix has to be in the code that communicates back, it should fail gracefully. The bug that caused the hang was in the network stack itself. There was no way the calling code could have prevented this in any way.…
At this point, the code relied on the Content-Length header being present because the higher-level API was supposed to add it. The field that is supposed to be populated by Content-Length (mRequestBodyLenRemaining) is…
Firefox generally does not block if a remote connection does not work. As explained in the post, the infinite loop was a bug in the network stack itself. So yes, you can use Firefox in any offline environment.
This is absolutely true and hence we combine not only our tests with TSan, but also fuzzing, to explore even more corner cases. On the static vs. dynamic side, I would always opt for the dynamic when it can guarantee me…
It would probably be fairly easy to change Qt's Mutex implementation to be TSan-compatible and only do so for TSan builds (by swapping out the fences for atomics when building with TSan). This is what we did in Firefox.
As described in our blog posts, our harness/pipeline only looks for crashes so all of the bugs resulting from that do have PoCs. There is a smaller number of bugs found by manual auditing that didn't have PoCs but I'd…
> But report [1] says that "Some of these bugs showed evidence of memory corruption...", which implies that majority of these (which includes 271 bugs from Mythos) don't have evidence at all. Do I not understand…
No, it's a new post, see also https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
No, we actually just posted a follow-up story with more details and opened several bugs, see also: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
Mythos did in fact write PoCs for all bugs that crash with demonstration of memory-unsafe behavior (e.g. use-after-free, out-of-bounds reads/writes, etc). For us this is substantial enough evidence to consider it a…
The bugs are at least of the same quality as our internal fuzzing bugs. They are either crashes or assertion failures, both of these are considered bugs by us. But they have of course a varying value. Not every single…
[working for Mozilla] That's because there were none. All bugs came with verifiable testcases (crash tests) that crashed the browser or the JS shell. For the JS shell, similar to fuzzing, a small fraction of these bugs…
[work at Mozilla] I agree that LLMs are sometimes wrong, which is why this new method here is so valuable - it provides us with easily verifiable testcases rather than just some kind of analysis that could be right or…
And the Firefox side of the story: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...
The infinite busy loop in this case was not the tab no (neither visible or invisible). The loop was directly in the network stack, as stated in the post, not in the caller.
> code that can end up blocking forever should have a timeout and recover from that timeout happening. There was no way for the calling code to do this. This was literally an infinite loop inside the network stack.…
All requests go through one socket thread, no matter which HTTP version. I am not a Necko engineer, but since requests can be upgraded, an HTTP/1 request could switch to HTTP/2 and if there was a separation by protocol,…
> the fix has to be in the code that communicates back, it should fail gracefully. The bug that caused the hang was in the network stack itself. There was no way the calling code could have prevented this in any way.…
At this point, the code relied on the Content-Length header being present because the higher-level API was supposed to add it. The field that is supposed to be populated by Content-Length (mRequestBodyLenRemaining) is…
Firefox generally does not block if a remote connection does not work. As explained in the post, the infinite loop was a bug in the network stack itself. So yes, you can use Firefox in any offline environment.
This is absolutely true and hence we combine not only our tests with TSan, but also fuzzing, to explore even more corner cases. On the static vs. dynamic side, I would always opt for the dynamic when it can guarantee me…
It would probably be fairly easy to change Qt's Mutex implementation to be TSan-compatible and only do so for TSan builds (by swapping out the fences for atomics when building with TSan). This is what we did in Firefox.