What Mozilla's Firefox hardening effort teaches other maintainers about AI bug-hunting

Mozilla’s security team has published a detailed account of how it used Claude Mythos Preview and other models to find and fix a large batch of Firefox vulnerabilities. The Mozilla Hacks post is worth reading for the workflow more than the headline count. Below is a summary of what they did, what surfaced, and which pieces transfer to a smaller project.

The turning point: reports that are actually good

The authors start with a problem every maintainer knows. AI-generated security reports used to be mostly noise. Writing a plausible but wrong report costs almost nothing, while checking it costs a maintainer real time.

Mozilla says that changed over a few months for two reasons. The models got more capable, and Mozilla got much better at steering, scaling and stacking them so the noise was filtered out. The second reason matters most for you, because it is something you control.

What a useful harness looks like

Mozilla says its early experiments, with models such as GPT 4 and Sonnet 3.5 statically analyzing risky code, showed promise but produced too many false positives to scale.

The change was the agentic harness. The key property is that, given the right interfaces and instructions, the model can create and run reproducible test cases to check its own hypotheses. A claim that can’t be reproduced gets dropped. That is what separates a harness from a chatbot reading code.

Mozilla’s build-up went roughly like this:

1. Fix the first batch of issues Anthropic sent in February.
2. Build a harness on top of the existing fuzzing infrastructure.
3. Run small experiments asking for sandbox escapes with Claude Opus 4.6, supervised live in a terminal to tune prompts and logic.
4. Parallelize across ephemeral VMs, each assigned one target file and writing findings to a storage bucket.

The inner loop stays simple, in Mozilla’s words: there is a bug in this part of the code, find it and build a testcase. The orchestration around it grew, but the core prompt did not.

The pipeline matters more than the model

Mozilla is clear that discovery alone isn’t enough. To scale, it had to connect the harness to the whole security bug lifecycle: deciding what to look for and where, then deduplicating against known issues, tracking, triaging and shipping fixes.

The post says harnesses may be reusable across projects, but this surrounding pipeline is project-specific. It reflects each codebase’s semantics, tooling and processes. Mozilla reports that building it took a lot of iteration, with a tight feedback loop with the engineers receiving the bugs.

The post doesn’t go deep on the mechanics of its triage. It does describe the shape of the work. Over 100 people contributed code, and the work also covered building the pipeline, triaging, testing fixes and managing the release for each bug. The authors also say the volume meant long days. If you adopt this approach, budget for the human side. Finding bugs is the cheap part, and every bug still needs careful fixing.

A practical benefit of building the pipeline first is that swapping models becomes trivial. Mozilla says upgrades improved the whole system at once: finding candidates, producing proof-of-concept tests, and explaining the impact.

What kinds of bugs surfaced

Mozilla unhid a deliberately mixed sample of reports, noting the selection was “somewhat arbitrary”. The sample suggests how broad the findings were:

• JIT and WebAssembly: an incorrect equality check let the JIT optimize away initialization of a live WebAssembly GC struct, in code that had been heavily fuzzed.
• Long-lived logic bugs: a 15-year-old bug in the <legend> element, and a 20-year-old XSLT bug where reentrant key() calls caused a rehash that freed memory still in use.
• IPC and sandbox escapes: races over IPC that let a compromised content process corrupt parent-process state, and a raw NaN crossing an IPC boundary that could pass as a tagged JS object pointer.
• Event-loop and lifetime tangles: use-after-free bugs reached through nested event loops, pagehide listeners, garbage collection and actor teardown.
• Network edge cases: a buffer over-read in HTTPS RR and ECH parsing, reproduced by simulating a malicious DNS server through intercepted glibc calls.
• Trust-boundary reasoning: a parent process that would decode an arbitrary wallpaper image sent by a compromised content process. Mozilla calls this difficult-to-automate reasoning about input trust levels.
• Sandbox library gaps: an escape from RLBox, Firefox’s in-process sandboxing for third-party libraries, through a hole in the verification logic that copies values out of the untrusted side.
• Tiny testcases fuzzers missed: a small HTML table case using rowspan=0 and more than 65535 rows to overflow a 16-bit layout bitfield, which fuzzers had missed for years.

The common thread is that many of these need reasoning across distant parts of the code, or across process boundaries. Mozilla says sandbox escapes in particular are notoriously hard for fuzzing, and that AI analysis gives much broader coverage there.

For sandbox-escape work, the model was allowed to patch Firefox’s source, as long as the patched code ran only in the sandboxed process. This simulates an attacker who already controls the renderer. It is a useful design for any multiprocess project: you can assume the first compromise and test the second boundary.

The bugs it didn’t find

Mozilla also points to what the models failed to do. Researchers had previously escaped the sandbox by triggering prototype pollution in the privileged parent process. Instead of fixing each report, Mozilla froze those prototypes by default. In the harness logs, the team saw many attempts down that route fail because of this design.

This is a good argument for fixing bug classes architecturally. An AI harness doubles as a regression test for your mitigations, and the logs show which defenses held.

Reading the numbers

Mozilla’s FAQ clears up an apparent mismatch in counts:

Item	Count
Bugs found with Claude Mythos Preview, fixed in Firefox 150	271
Externally reported bugs fixed in April releases	41
Other internally found bugs fixed in April	111
Total security bugs fixed in April releases	423

The three internal rollup CVEs for Firefox 150 cover 154, 55 and 107 bugs, which adds up to 316. That is more than 271 because the security team also uses fuzzing, manual review and other models. Of the 271, 180 were sec-high, 80 sec-moderate and 11 sec-low.

On severity, Mozilla says sec-critical and sec-high both cover bugs triggerable through normal browsing. Sec-critical is reserved for issues that are public or exploited in the wild. Sec-moderate covers bugs that would be sec-high but need unusual victim steps.

What to copy

You don’t need Mozilla’s scale to use the main ideas:

• Start simple. Mozilla recommends beginning with basic prompting, then observing and iterating. Its first prompts were close to publicly described ones.
• Require a reproducer. Make the agent write and run a test case. If it can’t demonstrate the bug, don’t read the report.
• Scope by file or function. Mozilla points the system at specific areas, chosen through human judgment and automated signals. Each job gets a narrow target.
• Reuse existing infrastructure. Mozilla built on its fuzzing setup, so you may already have the sandboxing and execution machinery.
• Plan for deduplication and tracking. Without these, a productive harness becomes a flood.
• Keep the model swappable. A pipeline that treats the model as a replaceable component benefits from every upgrade.
• Treat survivors as signals. Failed exploit attempts show which mitigations are working.

Mozilla’s next step is to run this analysis in continuous integration, scanning patches as they land rather than only files. The authors expect patch-based scanning to work as well or better, since models accept flexible context. That is a reasonable direction for any project that wants to catch bugs before they ship.

One caveat: these results come from a large, well-resourced team with extensive fuzzing and a long-running security process. The post doesn’t claim a small project would see the same yield. The transferable lesson is the workflow, not the count.