How Google Scaled Chrome's Bug-Hunting Pipeline to Fix More Flaws in Two Releases Than the Prior 23 Combined

Chrome 149 and 150 both shipped in June 2026, and together they fixed 1,072 security bugs. The 23 stable releases before them, roughly two years of Chrome, fixed 1,036 combined. Two releases outran two years of work.

Google's own chart traces the climb. Releases sat near ~50 bugs each up to M145, then jumped to ~80, ~130, and ~350 before the final leap. It is a hockey stick, roughly doubling release over release and then breaking loose.

Two things were straining under the load. Triaging a single security report took a human 5 to 30+ minutes, and by March 2026 external researchers, many running their own AI tools, filed more reports in a single month than in all of 2025. The human-review process could not absorb the flood.

In early 2026 Google deployed an agent harness built on Gemini that scans the entire Chrome codebase, not just the paths a fuzzer can reach. Its knowledge base is built from Chrome's full Git history plus every prior CVE, so the model can reason about code that predates its own training cutoff.

The clever part is a separate critic agent that reads the SECURITY.md files developers maintain per component, which describe each part's trust boundaries and threat model. That is what lets the system ask "is this a security failure" rather than just "does this crash."

The headline catch was a 13-year-old sandbox escape (CVE-2026-3545, CVSS 9.6) in the Navigation component, where a compromised renderer could trick the browser into reading local files. No fuzzer or external report surfaced it, because traditional review only revisits code that is actively changing or producing crashes. Nothing systematically re-audits stable code that has sat untouched for a decade. Meanwhile BigSleep and CodeMender now run in CI across all changelists every 24 hours, blocking over 20 vulnerabilities pre-merge in May alone, including one rated critical.

The report flood is where the pipeline earns its keep. Google runs a four-stage automated triage that mixes rule-based filtering with AI: discard the noise, reproduce the bug, enrich it, then route it.

The reproduce step spins up a virtual environment matching the exact browser and OS combo and, if the bug reproduces, attaches a stack trace. By the time a report lands on an engineer's desk it is already reproduced, enriched, and addressed to the right owner. Google estimates this saves hundreds of developer hours a month, while candidly hedging that the number is hard to measure precisely.

Fixing is a multi-agent handoff. A fixing agent generates several candidate patches, a critic agent evaluates them and produces review artifacts for humans, and a test-writing agent writes cross-platform tests that run before a human ever looks. Google says the test-first step alone can save weeks of iteration.

LLMs now generate candidate fixes for most vulnerabilities, which is what actually drives the 1,072 number. The obvious danger is a hallucinated fix shipped to half the adults on the planet that then fails in the field, which is exactly why the critic and test-writing stages sit between the fixing agent and human review.

Once a fix lands in the public open-source tree, attackers can reverse-engineer it into an N-day exploit before most users are patched. That interval, the patch gap, historically ran weeks. Google now merges security fixes straight from main into the active Stable branch, is moving major milestones to a two-week cadence with weekly security updates, and is piloting two security releases a week.

Shipping a fix is not the same as applying it: the fix is inert until the user restarts, and users defer restarts for days. Dynamic patching uses Chrome's multi-process design to sequentially swap background child processes, the Renderer and GPU process, for updated binaries without a full restart. In Chrome 150 on macOS, where apps often keep running after their last window closes, Chrome now detects a pending update in that windowless state and silently auto-restarts to apply it.

The flood of low-quality external AI reports, combined with internal AI now catching most routine bugs itself, pushed Google to restructure Chrome's Vulnerability Reward Program. It steers outside researchers toward bugs that are additive to internal findings and formatted to feed the automated pipeline, leaving humans most valuable for novel cross-component chains that need real creativity.

Success created its own bottleneck. Writing CVE descriptions and release notes at the new volume overwhelmed the team, so Google is automating that too. A week after 149 and 150, Chrome 151 added 370 more fixes, 349 of them found by Google itself, pushing the three-release total to 1,442.

Running alongside the pipeline is a prevention track aimed at cutting how many bugs get written at all: a centralized Rust SDK for historically bug-dense code like parsers, image codecs, and font stacks, plus "spanification" that has 97% of first-party Chrome code compiling cleanly under strict unsafe-buffer warnings. And even under pressure to move twice a week, Google commits to publicly document every Stable bug, internal or external.