AI agents built a $250,000 Chrome exploit chain in six days — what it means for patching

Security firm XBOW says its researchers, working with AI agents running OpenAI's publicly available GPT-5.6 Sol model, built a full Google Chrome exploit chain in six days for an estimated $40,000 in AI usage — work it says would once have taken a team of four 6–9 months. Google paid a $250,000 bug bounty, and all three bugs are fixed. Your action is simple: confirm Chrome is at version 152.0.7977.82 or later and that browsers actually restart to apply updates.

What happened, in plain English

A "full chain" is a set of bugs used one after another to completely take over a computer from a web page. Modern browsers are built like a building with locked inner rooms: web pages run inside a restricted area called a sandbox, so even if a page finds a bug, it should stay trapped there. A full chain needs one bug to get in, and more bugs to pick each lock on the way out.

On October 13, 2026, XBOW published how it did exactly this against Chrome on Windows. The first bug was in V8, Chrome's JavaScript engine (the part that runs website code). The second was in the code that decodes animated WebP images, and it was used to get a single write outside V8's own protected memory area. The third was in Crashpad, the component that collects crash reports — which runs outside the sandbox, so a bug there meant code running with normal user rights. In XBOW's demonstration, simply loading a web page launched the Windows Calculator — the classic proof that an attacker could run anything.

The AI agents searched Chrome's source code, tested ideas and built the exploit pieces; human researchers chose targets, checked results and decided how to combine them. XBOW reported everything through Google's Vulnerability Reward Program (VRP), and Google fixed the bugs in August and September. XBOW says the chain was never used against real users, and Google's release notes make no in-the-wild claim for these bugs.

Are you affected? What to do now

Most readers have little to do: Chrome updates itself, and the fixes shipped in August and September. The real lesson is about how fast you patch, not this specific chain.

Who should care

Anyone running Google Chrome on Windows older than 152.0.7977.82 (Chrome's Windows and Mac release of September 3, 2026, was 152.0.7977.82/.83).
Teams managing browser fleets, kiosks, VDI images or "golden" images that pin or delay browser versions.
Vendors of other Chromium-based browsers and apps that embed Chromium: check with them whether and when they took these fixes — we have not seen confirmation for each product.

Checklist

On a sample of machines, open chrome://settings/help and confirm the version is 152.0.7977.82 or later. Current releases are newer, which is fine.
Use your endpoint management tool or software inventory to find outdated Chrome versions across the fleet — not just the machines you can see.
Make sure updates are not blocked by policy and that users actually relaunch. An update is downloaded in the background but only applies after a restart; consider enforcing a relaunch deadline through Chrome enterprise policy.
Rebuild or refresh any VDI, kiosk or template images that carry an old browser.
Ask suppliers of Chromium-based software (Electron apps, embedded browsers) how quickly they ship Chrome security fixes.
Treat browser security updates as urgent by default. The gap between a fix and a working exploit is shrinking — see the expert view below.

No indicators of compromise (IOCs) have been published, because no attacks using this chain have been reported.

The expert view

The chain, conceptually. Stage one was a V8 bug in the Maglev optimizing compiler: during deoptimization (when the engine abandons fast compiled code), it reused a number object that it assumed nobody else could change. That gave read/write access within V8's pointer-compression "cage". Stage two abused a time-of-check/time-of-use (TOCTOU) mismatch in the Blink animated-WebP decoder, combining cached frame sizes with data that had changed after an ArrayBuffer was transferred — enough for one chosen write outside the V8 sandbox. Stage three targeted Crashpad on Windows: when reading memory from a supposedly frozen renderer, a failed read was treated as stable and retried past the destination buffer, turning into code execution in an unsandboxed process. Chrome's release notes credit Brendan Dolan-Gavitt of XBOW for CVE-2026-78952 (Crashpad, out-of-bounds write, fixed in the August 25 release) and CVE-2026-85045 (described by Google as a "race condition in V8", fixed in 152.0.7977.82 on September 3). The public CVE record for CVE-2026-85045 points to the same Chromium issue XBOW lists for its V8 stage. We could not find a public CVE identifier for the WebP stage. Note that XBOW's press release labels CVE-2026-85045 as the WebP bug; Google's release notes and the CVE record say V8, and we follow those.

What is new. AI-assisted bug finding is not new — this site has covered Google, Microsoft and Anthropic numbers on it for weeks. What is new is a publicly documented, fully weaponized sandbox-escaping chain against the most hardened mainstream browser, built with a commercially available model in under a week, and validated by Google with its top reward. XBOW's first chain this year took about two months; this one took six days. That trajectory matters more than any single number.

What is not new. Humans still steered. XBOW's own write-up says researchers "chose targets, supplied context, challenged results, redirected searches." The bugs are classic memory-safety and invariant failures. The authors suggest LLMs may be especially good at spotting violated assumptions — "this object never changes", "this process is frozen" — which is a useful hint for anyone doing code review or fuzzing harness design.

Why it matters for defenders. Economics. Roughly $40,000 and six days is well within the budget of criminal groups and state teams, not just top-tier exploit brokers. XBOW's conclusion is blunt: the bar for a Chrome chain is "significantly" lower, and "Defend accordingly." In practice, that means shrinking the window between a browser fix and its deployment from weeks to days, and treating sandbox layers as defence-in-depth rather than a guarantee. It also has an awkward side for bug bounty programs: XBOW notes one of its stages turned out to duplicate a bug Google already knew about — a sign that many parties, human and AI, are now finding the same flaws.

What is still unknown. XBOW's post does not describe what usage controls applied to the model, and OpenAI's public comment (quoted in XBOW's press release) does not address it. It is also unclear how much of the six days depended on XBOW's prior Chrome experience and tooling, so the result is not a measure of what an unskilled attacker could do. Finally, the "one billion users exposed" figure is XBOW's own estimate for Chrome on Windows, not a Google number.

AI agents built a $250,000 Chrome exploit chain in six days — what it means for patching

What happened, in plain English

Are you affected? What to do now

The expert view

Official sources

Langflow MCP flaw draws 1,400+ exploit attempts — and the first fix, 1.9.0, was incomplete

AI-found Linux kernel flaw "Vghost" gives local users root — and can let a VM reach its host

AI-found flaw in Rejetto HFS file server now under attack — update to 3.2.1

What happened, in plain English

Are you affected? What to do now

The expert view

Official sources

Langflow MCP flaw draws 1,400+ exploit attempts — and the first fix, 1.9.0, was incomplete

AI-found Linux kernel flaw "Vghost" gives local users root — and can let a VM reach its host

AI-found flaw in Rejetto HFS file server now under attack — update to 3.2.1

Get the daily brief