Partnering with Mozilla to improve Firefox’s security

cybersecurityvulnerability discoveryopen sourcefrontier red teamdisclosure

Anthropic reports that Claude Opus 4.6 found 22 vulnerabilities in Firefox over two weeks, 14 of them rated high-severity by Mozilla, but turned a vulnerability into a working exploit in only two of several hundred attempts, in a test environment with browser protections removed; the post describes how the reports were made trustworthy for maintainers and argues that defenders should use the gap between finding and exploiting bugs while it lasts.

Anthropic · 2026-03-06 · original

Can a language model find serious security flaws in software that is already heavily tested, and can it then use them? This post, published on 6 March 2026 under Anthropic's Policy and Frontier Red Team labels, reports a two-week collaboration with Mozilla in which Claude Opus 4.6 searched the Firefox browser for vulnerabilities. It follows an earlier Anthropic report, linked in the post, that Claude had found more than 500 zero-day vulnerabilities (flaws unknown to a software's maintainers) in well-tested open-source software. The post is short and has no technical appendix; the numbers below are the post's own.

From an evaluation to a partnership

The work began as an evaluation (section "From model evaluations to a security partnership"). In late 2025 Anthropic noticed that Claude Opus 4.5 was close to solving all tasks in CyberGym, a benchmark that asks models to reproduce known vulnerabilities, and wanted a harder test with more technically complex flaws. Firefox was chosen because it is a complex codebase and, in the post's words, one of the most well-tested and secure open-source projects; browser flaws are also especially dangerous because browsers routinely process untrusted content.

The team first built a dataset of past Firefox CVEs (Common Vulnerabilities and Exposures, the public catalogue of disclosed flaws) and found that Opus 4.6 could reproduce a high percentage of them. Because some of those CVEs might be in Claude's training data, the team then asked Claude to find new flaws in the current version of Firefox, which by definition could not have been reported before. The search started with the JavaScript engine, a part of the browser that can be analyzed in isolation and that processes untrusted code from the web, and later widened to other components.

After twenty minutes of exploration Claude reported a use-after-free bug in the JavaScript engine, a memory error that can let an attacker overwrite data. One researcher validated it in a separate virtual machine with the latest Firefox release, two more researchers validated it again, and the team filed it in Mozilla's Bugzilla tracker with a description and a candidate patch written by Claude and checked by the team. By the time that first report was filed, Claude had found fifty more unique crashing inputs.

At that point a Mozilla researcher contacted the team and, after a technical discussion, encouraged them to submit findings in bulk without validating each one, even when it was unclear whether a crash had security implications. In total the team scanned nearly 6,000 C++ files and submitted 112 unique reports. Most were fixed in Firefox 148, with the rest scheduled for later releases.

What it found

The post reports that Claude found 22 vulnerabilities over the two weeks, of which Mozilla rated 14 high-severity; the 112 reports included these along with crashes that did not all turn out to be security-relevant. The post says the 14 are almost a fifth of all high-severity Firefox vulnerabilities remediated in 2025 (introduction). A chart in the post shows Firefox security vulnerabilities reported from all sources by month; its caption says the 22 found in February 2026 exceed the number reported in any single month of 2025. Mozilla researchers have since begun experimenting with Claude internally for security work.

Finding versus exploiting

A second evaluation asked whether Claude could exploit the bugs it had found (section "From identifying vulnerabilities to writing primitive exploits"). Claude was given the submitted vulnerabilities and asked to build an exploit for each, with success defined as reading and writing a local file on the target system, as an attacker would. Across several hundred attempts with different starting points, costing about $4,000 in API credits, Opus 4.6 produced a working exploit in two cases.

The post draws two conclusions: Claude is much better at finding these bugs than at exploiting them, and finding them costs about an order of magnitude less than exploiting them. It also calls the two successes "concerning." It stresses that the exploits were "crude": they worked only in a test environment that had removed some modern browser protections, most importantly the sandbox, which limits what a compromised component can reach. Firefox's layered defenses would have stopped these particular exploits, though the post notes that sandbox escapes do occur and that Claude's exploit would be one necessary part of a complete attack. A technical account of one exploit is on Anthropic's Frontier Red Team blog.

The section "What's next for AI-enabled cybersecurity" gives practices learned from the work, which footnote 1 says should apply to any LLM:

  • Task verifiers. A task verifier is a trusted way of checking whether an agent's output achieves its goal, which lets the agent iterate until it does. The post says verifiers helped find the Firefox bugs and are also useful for fixing them. A patching agent should check at least two things: that the vulnerability can no longer be triggered, and that the program's intended behavior is preserved, for example by running the existing test suite to catch regressions. Passing both is described as the minimum for a plausible patch, not a guarantee that it is ready to merge, and the post recommends that maintainers review AI-written patches as they would any external contribution.
  • Evidence for maintainers. The Firefox team named three parts of the submissions as key to trusting them: minimal test cases, detailed proofs of concept, and candidate patches. The post encourages others using LLM-based vulnerability tools to include similar evidence.
  • Disclosure procedures. Anthropic points to its published Coordinated Vulnerability Disclosure operating principles, which it says follow standard industry norms for now and may need to change as models improve.

The argument about timing

The closing section, "The urgency of the moment," states that Opus 4.6 is currently far better at finding and fixing vulnerabilities than at exploiting them, which it says gives defenders the advantage, and that Claude has also been used to find vulnerabilities in other projects such as the Linux kernel. It predicts that the gap between discovery and exploitation is unlikely to last long, says Anthropic would need to consider additional safeguards if models break through the "exploitation barrier," and urges developers to use the window to secure their software. It mentions Claude Code Security, then in limited research preview, as a way of bringing discovery and patching to customers and maintainers.

Limitations and open questions

  • Reported by one party. The counts of vulnerabilities and severities come from the post; Mozilla's advisory and its own blog post are linked but were not read for this note.
  • Training-data contamination. The post itself raises this for the historical CVE test, which is why the main result rests on new bugs in the current codebase. It does not give the reproduction rate for historical CVEs.
  • The exploit test is narrow. Two successes in several hundred attempts, with protections removed, measure one capability under one setup; the post does not report how results varied with starting points or model versions.
  • Human effort is not quantified. Validation, triage and Mozilla's work on 112 reports are described but not measured, so the cost of the process to maintainers is unknown.

Research questions

  1. How does the find-to-exploit ratio change across model generations? The post predicts that the gap will close. Running the same exploit evaluation on successive models, with the same targets and budget, would measure the trend directly.
  2. What share of AI-generated crash reports are security-relevant? The team submitted 112 reports and the post counts 22 vulnerabilities, without breaking down the rest. Classifying all reports by outcome (security bug, ordinary bug, duplicate, not a bug) would show what bulk submission costs maintainers.
  3. How much do task verifiers improve patch quality? The post says verifiers "dramatically" improve patches but gives no numbers. Comparing patches produced with and without vulnerability and regression checks, as judged by maintainers, would measure the effect.
  4. Does the sandbox hold against model-written exploit chains? The exploits worked only with the sandbox removed. Testing whether models can produce sandbox escapes, under controlled conditions, would show how much the layered defense contributes.
  5. Which elements of a report most affect whether maintainers act on it? Mozilla named test cases, proofs of concept and candidate patches. Measuring triage time and fix rates for reports with and without each element would test that judgment.

How it connects

  • The post links to two Frontier Red Team posts (on the 500 zero-day vulnerabilities and on the exploit), Mozilla's advisory and blog post, and Anthropic's Coordinated Vulnerability Disclosure principles. None of these is in this library's list, and the post cites no other item in the collection.

References

  • Anthropic. (2026, March 6). Partnering with Mozilla to improve Firefox's security. https://www.anthropic.com/research/mozilla-firefox-security
  • Linked from the post and not read for this note: Mozilla Foundation Security Advisory 2026-13, https://www.mozilla.org/en-US/security/advisories/mfsa2026-13/; Mozilla's post on the collaboration, https://blog.mozilla.org/en/firefox/hardening-firefox-anthropic-red-team/; Anthropic Frontier Red Team, https://red.anthropic.com/2026/zero-days/ and https://red.anthropic.com/2026/exploit/.