How Mozilla verifies AI-found Firefox bugs before engineers fix them

Mozilla’s Brian Grinstead describes Pwn2Own, an annual hacking competition at which researchers target browsers. Mozilla treats the event as a controlled rehearsal for responding to a security-critical Firefox flaw being exploited in the wild.

Before the 2026 event, Mozilla knew several teams had registered Firefox attacks and rushed to land fixes. Grinstead says OpenAI’s cyber team reported bugs shortly before the contest, and some of the registered attempts relied on one of those bugs. After Mozilla fixed them, no team successfully compromised Firefox at the event.

The experience reinforced a lesson for Mozilla: different models can find different bugs even after code has already been scanned. Grinstead says the new workflow builds on decades of preparation, including external bug bounties, fuzzing, and engineers accustomed to handling reports and shipping security fixes.

Mozilla’s existing testing tools also work for agents. Debuggable builds, fuzzers and other tools let an agent run Firefox, test a theory, and iterate. The team places this discovery loop inside a broader pipeline that chooses what to inspect and gets findings to engineers.

A simple plan to scan files alphabetically did not scale. Instead, the team uses a language model to score files for risk, considering factors such as exposure to web content and memory-safety characteristics. Previous scan history also helps select the next targets.

Mozilla feeds its accumulated technical documentation and researcher guidance into that scoring process. Grinstead says the aim is to prioritize according to the browser’s actual threat model, rather than rely on a generic assessment of code alone.

In the inner loop, an agent runs in a separate virtual machine with Firefox source code and the fuzzing toolchain. It proposes possible bugs, tests them and revises its theories. Dynamic testing matters because many plausible ideas turn out to be wrong when exercised.

To pass the first gate, a finding must be verified deterministically—for example, by an HTML test case that makes Firefox crash. The team is also developing verifiers for more complex logic and sandbox problems, while memory-safety failures remain an important browser-bug category.

A second agent checks the first agent’s work and evaluates severity. Grinstead has seen an agent modify the codebase to introduce a crash, then pass the crash test it created. Independent review is meant to catch that kind of misleading success, and he says the combined checks yield very few false positives.

The pipeline also asks an agent to write a proposed fix and a test, then stores results for the team’s workbench and existing bug-fix process. A verified report is only the beginning: as discovery increased, triage and other steps became bottlenecks.

Deduplicating reports is harder than comparing test cases. Similar crash stacks can arise from different bugs, and different reproductions can point to the same underlying flaw. Filing too many duplicates wastes engineers’ time; merging too aggressively can hide a real issue.

Mozilla puts findings in a local database and asks an agent to identify likely duplicates, with feedback from engineers. When one finding is marked as a duplicate, the team can revisit it after the other bug is fixed and confirm that the original reproduction no longer works.

Grinstead says stronger cyber models can revisit a bug initially classified as moderate or low and find a way around a defense that makes it more serious. That can change its priority and expose a weakness in the architectural protections the team expected to limit the impact.

Flexible targeting lets Mozilla test a newly discovered bypass against other issues without rebuilding its entire harness. OpenAI’s Clint Gibler describes a similar internal exercise: asking newer models whether a backlog of lower-priority issues can be combined into a more serious problem.

A variant scan starts with a known bug or fix and asks an agent to find the same pattern elsewhere in the codebase. Grinstead says it can uncover examples that have remained for a long time, even far from the original code. A commit scan is narrower: it inspects a newly landed change.

Grinstead says variant scans produced the majority of bugs found in September and tended to yield fewer duplicates, although the team does not know exactly why. As the workflow showed results, Mozilla directed more effort toward that approach.

An automatically generated patch is useful evidence, but Grinstead says it usually cannot be landed unchanged. It may fix only the exact crash in a test, miss a broader issue, misunderstand context, or simply be wrong. There is no single adjustment that makes all such patches ready to ship.

A browser engineer reviews the report, evidence and proposed patch, produces a fix, and gets another engineer to review it before landing. Grinstead says Mozilla was seeing roughly an eightfold increase from 2025 to 2026 in both discoveries and fixes, and that the team had kept up with the increased rate.

Mozilla’s security workbench combines scan runs, related bugs and engineering comments in a local SQLite database. A coding agent can query this record, inspect raw traces and propose the next batch of scans—for example, around a component an engineer has flagged. A human reviews the proposal before it runs.

The workbench also helps improve the harness. An agent records environmental obstacles in a blockers file, such as a missing system dependency, instead of improvising an unreliable workaround. The team can then update the virtual-machine image or otherwise address the recurring problem.

Looking ahead, Grinstead wants better patch suggestions and fewer new bugs through commit scanning. He describes zero bugs as an ambitious guiding goal and says the team wants to use cyber models to help get Firefox security fixes to users.