Insights & Updates on Application Security

Anthropic Mythos found 271 Firefox bugs. What does it cost to fix them? | AppSecAI

Written by Bruce Fram | May 22, 2026 6:11:19 PM

Executive summary: what AI-driven vulnerability discovery costs to remediate

AppSecAI — May 2026

The problem in one sentence

AI-driven vulnerability discovery is scaling faster than any organization's ability to fix what it finds. The security bottleneck is shifting from detection to remediation, and the cost of that shift is quantifiable.

What happened

In April 2026, Mozilla disclosed that Anthropic's Mythos red-team program identified 271 vulnerabilities in Firefox. Mozilla's 271 figure includes rollup CVEs, Extended Support Release (ESR) branch and submodule fixes, and vulnerabilities not separately credited; the public surface is 131 directly-described CVEs across Firefox 148, 149, and 150 (three releases spanning eight weeks). We analyzed those 131 to model what remediation costs. The full methodology, rubric, and per-CVE data are available in our detailed technical analysis.

Mozilla's May 2026 retrospective disclosed that more than one hundred contributors landed those fixes across Firefox 148, 149, and 150. The find side scaled with one AI model; the fix side scaled with more than a hundred people. That asymmetry is the cost story this brief quantifies.

The numbers

We scored the 111 CVEs that carry real exploit risk: remote code execution, chain enablers, and reachable attack surface (tiers T1 through T3 in our rubric). The remaining CVEs are defense-in-depth hardening with minimal risk impact.

  Conservative — no AI Central — 25% AI Optimistic — 50% AI
Engineer-days (8-week window) 656 492 328
Fully-loaded labor cost (8-week window) ~$1.23M ~$922K ~$615K
Annualized cost ~$5.33M ~$4.00M ~$2.66M
FTE required (8-week / annualized) 16.4 / 14.2 12.3 / 10.7 8.2 / 7.1
Cost per CVE ~$11,070 ~$8,300 ~$5,540

These are fully-loaded labor costs at $375K per engineer-year, which includes salary, benefits, management allocation, CI/CD compute, AI tooling, G&A, and recruiting amortization (breakdown in the detailed analysis). They do not include other parts of the process beyond engineering such as triage, tracking, communication, program management, etc. Thus we beliefe these numbers to be conservative.

Where the money goes

Application security is one of the rare cost-side functions that directly consumes a revenue input: developer time. The actual economic footprint of remediation is therefore typically several multiples larger than the visible AppSec budget line, because the cost travels through engineering throughput as well as through security spend.

The cost distribution is not even:

Two-thirds of the budget goes to the most dangerous bugs. The 61 T1 CVEs (remote code execution, memory corruption, sandbox escapes) account for ~$818K of the ~$1.23M baseline, or 67% of total cost from 55% of the CVE count. These are the bugs attackers can exploit, and they are also the most expensive to fix.

The long-tail rule

About a third of mapped CVEs — those scoring 10+ on our difficulty rubric — consume roughly 60% of total engineer-days. This is the security-remediation equivalent of the Pareto distribution, and it changes how a security organization should plan. Three concrete implications:

  • Average per-CVE cost is misleading. Capacity planning on the per-CVE average understates true workload by roughly 2×, because the average is pulled down by the trivial tail. A single JIT correctness bug can take 30 working days to fix properly; ten trivial validation fixes can take a single afternoon. The arithmetic mean tells you neither.
  • Staff for the tail, not the average. Two senior specialists who can ship JIT correctness, sandbox-semantics, or GC-marking fixes account for more risk-relevant output than five generalists handling trivial bugs. "We need N more security engineers" undersells the staffing problem — you need specific engineers, and those are the ones the market is most thinly supplied with.
  • AI compression is asymmetric. AI coding assistants help most on mid-difficulty fixes (score 6–12), where they can accelerate diagnosis and test generation. The highest-difficulty work — JIT correctness, sandbox semantics, GC marking — has irreducible review and fuzzing-validation time that AI cannot shortcut. Doubling AI investment does not double remediation throughput on the bugs that actually consume your budget.

The risk

This is one browser, one quarter, one AI red-team program in preview. The pattern will repeat and accelerate:

  • Other AI discovery programs are already running. Google, OpenAI, Microsoft, and independent researchers are deploying similar tools against their own and others' codebases.
  • Successor models will find more, not fewer, vulnerabilities. Mythos is a preview. Production-scale AI red-teaming will increase the find rate by an order of magnitude.
  • Fix capacity does not scale the same way. Hiring senior security engineers who can fix JIT bugs takes months. AI discovery programs scale in weeks. The gap between find rate and fix rate will widen.

Double the discovery rate without expanding fix capacity and you do not get twice the security. You get twice the backlog.

What this means for budgeting

  Conservative — no AI Central — 25% AI Optimistic — 50% AI
Per-CVE cost (fully-loaded) ~$11,070 ~$8,300 ~$5,540
Annualized (at current CVE rates) ~$5.33M ~$4.00M ~$2.66M
FTE devoted to remediation (annualized) 14.2 10.7 7.1

The Conservative column is the baseline: what remediation costs with experienced engineers working without AI tooling. The Central and Optimistic columns reflect 25% and 50% productivity gains from AI coding assistants, consistent with published studies (METR, DORA 2024, GitHub Copilot field data); 25% is the defensible portfolio-average central case, 50% reads better as an upper bound. All figures use a $375K fully-loaded cost per FTE.

Three takeaways for planning:

  1. Even with AI assistance, remediation is expensive. At 50% AI compression — the optimistic end of current evidence — each CVE still costs ~$5,540 fully-loaded and requires ~7 FTEs of dedicated security engineering capacity at current Firefox CVE rates.
  2. The savings from AI show up in capacity, not just dollars. A 25% improvement frees ~3.5 FTEs of engineering time. That is capacity that can go toward proactive security work, architecture review, or reducing the fix backlog. A 50% improvement frees ~7 FTEs.
  3. Plan for volume and shape, not averages. Apply the long-tail rule above when modeling growth. If AI discovery programs double your inbound CVE rate, your remediation budget does not double — it grows non-linearly, because the high-difficulty tail (where the budget actually lives) grows faster than the trivial bucket. A 2× increase in CVE volume can easily mean a 3× increase in cost if the inflow is skewed toward harder classes, which is exactly what AI-driven discovery programs are best at surfacing.

This summary is based on publicly available Mozilla advisory data and our three-axis difficulty rubric. The full technical analysis, including per-CVE scoring, methodology, and sensitivity analysis, is available at appsecai.io/research/firefox-cve-remediation-cost. Analysis by AppSecAI, May 2026.

How AppSecAI closes the gap. Our Expert Triage Automation (ETA) validates each scanner finding, prioritizes by severity and reachability, and routes false positives off your queue. Expert Fix Automation (EFA) writes the patch, generates the regression test, and opens a PR for human review. Pay-per-fix: you pay for outcomes, not seats.

If your codebase is in that flow, we'd like to talk.