AI-Powered Security Vulnerability Detection Pipeline for Browser Hardening

mozilla · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Browser security auditing and vulnerability remediation

Mozilla needed to find latent Firefox security vulnerabilities, especially complex sandbox escapes and multiprocess browser-engine bugs, without drowning maintainers in plausible but wrong AI-generated reports.

Constraints:

• early LLM code audits produced high false-positive rates
• security reports impose asymmetric triage cost on maintainers
• browser vulnerabilities can involve distant subsystems, IPC races, fuzzing-resistant edge cases, and sandbox boundaries
• every discovered bug still needed deduplication, triage, tracking, fixing, testing, and release management
• reports had to stay private long enough to protect users slow to update

Architecture

Mozilla built an agentic vulnerability-discovery harness on top of its existing Firefox fuzzing infrastructure and integrated it into the security bug lifecycle. The harness gives modern models interfaces and instructions to create and run reproducible test cases, dynamically validating hypotheses rather than producing static speculation. Mozilla first supervised terminal sessions to tune prompts and logic, then parallelized jobs across ephemeral VMs, each aimed at a target file and writing findings to a bucket. Downstream project-specific pipeline stages determine what to scan, where to scan, deduplicate against known issues, track bugs, triage, test fixes, and ship releases.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  scan-target-selector["scan-target-selector"] --> agentic-security-harness["agentic-security-harness"]
  model-upgrade-interface["model-upgrade-interface"] --> agentic-security-harness
  existing-fuzzing-infrastructure["existing-fuzzing-infrastructure"] --> agentic-security-harness
  agentic-security-harness --> ephemeral-vm-workers["ephemeral-vm-workers"]
  ephemeral-vm-workers --> findings-bucket["findings-bucket"]
  findings-bucket --> security-bug-lifecycle["security-bug-lifecycle"]
  security-bug-lifecycle --> firefox-release-process["firefox-release-process"]

Components

Data flow

Human judgment and automated signals select files/functions or future patches for scanning. A harness task runs on an ephemeral VM with a modern model, Firefox-specific interfaces, and a target instruction such as finding a bug and building a testcase. The model analyzes code, patches the browser when allowed for sandbox-escape testing, creates reproducible proof-of-concept test cases, and writes findings to a bucket. Mozilla's security workflow then deduplicates findings, opens/tracks bugs, triages severity, coordinates fixes and reviews, tests patches, and ships release/advisory updates.

Why this architecture

Mozilla moved beyond static LLM code review because plausible but wrong reports were too costly to scale. The agentic harness changes that by letting models test their own hypotheses with reproducible cases and dismiss speculation. Building on existing fuzzing infrastructure gave the model a dynamic validation surface, while the full security lifecycle turned discoveries into shipped fixes. Model-agnostic orchestration meant new model capabilities improved the whole pipeline without a rebuild.

"the high rate of false positives made them impractical to scale.

The introduction of agentic harnesses that can reliably detect security issues has completely changed this."

Models used: Claude Mythos Preview · Claude Opus 4.6 · Claude Sonnet 3.5 · GPT-4

Scale

• Mozilla reported an unprecedented number of Firefox bugs identified and fixed with Claude Mythos Preview and other AI models.
  “we had identified and fixed an unprecedented number of latent security bugs in Firefox with the help of Claude Mythos Preview and other AI models.”article, stated
• Firefox security bug fixes were normally around 20-30 per month in 2025, spiking to 423 in April 2026.
  “trending in the 20-30 range throughout each month in 2025, with a spike to 60-70 in February and March 2026, up to 423 in April 2026”article, stated
• Claude Mythos Preview identified 271 bugs announced for Firefox 150.
  “Astute readers will notice the number of bugs in those internal rollups adds up to 316, which is more than the 271 we announced finding with Claude Mythos Preview.”article, stated
• Firefox 150 internal rollups contained 316 bugs across three CVEs.
  “there were three internal rollups: CVE-2026-6784 (154 bugs), CVE-2026-6785 (55 bugs), and CVE-2026-6786 (107 bugs).”article, stated
• Mozilla fixed 423 total security bugs in April releases.
  “We fixed a total of 423 security bugs in releases in April.”article, stated
• Of the 271 Firefox 150 bugs, 180 were sec-high, 80 sec-moderate, and 11 sec-low.
  “Of the 271 bugs we announced for Firefox 150: 180 were sec-high, 80 were sec-moderate, and 11 were sec-low.”article, stated
• More than 100 people contributed code to the fixing and release effort.
  “Over 100 people contributed code to this effort to ship the most secure Firefox yet.”article, stated

Alternatives considered (roads not taken)

static LLM code audits

Rejected because: Earlier GPT-4 and Claude Sonnet 3.5 experiments showed promise but produced too many false positives to scale.

pure discovery harness without lifecycle integration

Rejected because: Discovery alone did not handle target selection, deduplication, bug tracking, triage, fixing, and release shipping.

one-off project-independent harness

Rejected because: Mozilla says the pipeline must reflect each codebase's semantics, tooling, and processes.

fixing each prototype-pollution sandbox escape separately

Rejected because: Mozilla instead made an architectural hardening change that blocked many model attempts along that line.

Patterns

tool-use-orchestration (agent-architecture)

The harness gives models interfaces for code analysis and dynamic testcase execution, allowing them to validate vulnerability hypotheses.

eval-driven-development (quality)

Mozilla supervised terminal sessions, observed outputs, tuned prompts and logic, and iterated alongside Firefox engineers receiving incoming bugs.

model-routing (model-operations)

The pipeline was built so model upgrades could be swapped in and improve bug finding, testcase generation, and impact explanation across the pipeline.

batch-offline-processing (operations)

Mozilla parallelized target-specific bug hunts across ephemeral VMs and collected findings in a bucket for downstream lifecycle processing.

Tradeoffs

Unhide a small sample of bug reports early.

Chose sharing selected reports despite normal private embargo practices over keeping all details private for several months.

Rationale: Mozilla judged ecosystem urgency and interest high enough to justify showing representative examples while still limiting exposure.

Let the model patch Firefox source code during sandbox-escape crafting.

Chose allowing sandboxed-process-only source patches for testing over forbidding code modification during harness exploration.

Rationale: For sandbox-escape research, permitting constrained patches helps the model explore compromised-content-process scenarios while respecting the boundary under test.

Use file/function targeted scanning before CI-wide patch scanning.

Chose specific code areas based on human judgment and automated signals over immediate continuous scanning of all landing patches.

Rationale: Mozilla's current system focuses scanning on areas likely to matter, while the planned next step is patch-based CI integration.

Gotchas (what bit them)

AI-generated vulnerability reports can impose asymmetric maintainer cost.

Root cause: It is cheap to produce plausible wrong reports and slow for maintainers to disprove them.

Resolution: Require dynamic reproduction through an agentic harness before scaling the pipeline.

Finding a bug is not enough to improve security at scale.

Root cause: Security work still needs deduplication, tracking, triage, fixes, testing, advisories, and release process.

Resolution: Integrate the harness with Firefox's full security bug lifecycle.

AI discovery created an unprecedented remediation workload.

Root cause: The harness surfaced hundreds of real security bugs in a short period.

Resolution: Mozilla mobilized more than 100 contributors across patching, review, scaling, triage, testing, and release management.

Security severity is not identical to practical exploitability.

Root cause: Firefox defense-in-depth means one high-severity bug may still require chaining with sandbox or OS mitigations.

Resolution: Mozilla rates predictable memory-safety symptoms conservatively to reduce false negatives and focus on fixing more vulnerabilities.

Evaluation

Mozilla evaluated the system through reproduced vulnerability findings, fixed bug counts, severity distribution, comparison with fuzzing/manual discovery, and operational ability to push fixes through release channels.

Metrics: 271 bugs identified by Claude Mythos Preview for Firefox 150 · 423 total security bugs fixed in April releases · 180 sec-high, 80 sec-moderate, 11 sec-low among the 271 announced bugs · 316 internal rollup bugs across three CVEs for Firefox 150 · more than 100 contributors to the effort

Outcomes

• Mozilla fixed hundreds of latent Firefox security bugs using the agentic pipeline and other methods
• the system found complex bugs including sandbox escapes, UAFs, IPC races, stale vulnerabilities, and fuzzing-resistant edge cases
• the pipeline set Mozilla up to benefit quickly from new model releases
• the work demonstrated that prior architectural hardening blocked many model attempts

The article reports 271 Mythos-identified bugs for Firefox 150, 423 total April security fixes, 180 sec-high bugs among the announced 271, and over 100 contributors.