Yaamlabs
Vulnerabilities

AI agents built a Chrome full chain in six days

Xbow chained three Chrome bugs into a Windows sandbox escape using GPT-5.6 Sol and $40,000 of tokens. The builds to check, and how to force a relaunch.

By Yaali. October 15, 2026, 7 min read, Vulnerabilities, Patching.

Cover illustration of a browser window holding nested glass boxes cracked open by small robotic arms, with a glowing thread running out through the cracks, with the Yaamlabs logo and the text: AI agents broke out of Chrome in six days, $40,000 in model tokens for a $250,000 bounty

On October 13, AI penetration testing startup Xbow published a working Chrome exploit chain for Windows: a web page that, in an unpatched browser, gets out of both of Chrome's sandboxes and runs a program on the machine. Brendan Dolan-Gavitt, Andrés Luksenberg, Baul Lee and Willem Pinckaers built it in six days (August 2 to 7) during Black Hat and DEF CON. Agents running OpenAI's GPT-5.6 Sol searched the source and wrote the first exploit drafts for about $40,000 in API charges, while the humans chose targets and decided how to join the pieces. Google paid $250,000, its top reward for a Chrome full chain and the first under the rules it introduced in April 2026.

Google fixed all three bugs, and its release notes do not flag any of them as exploited in the wild. Your exposure depends on whether every Chrome, Edge or Brave window has been relaunched since the fixes landed in August and September, because Xbow has now published the root causes and exploit techniques. Xbow estimates about one billion users were exposed.

Xbow's Chrome chain in three stages: a V8 Maglev bug gives read and write inside the pointer-compression cage, an animated WebP bug escapes the V8 sandbox, and a Crashpad overflow escapes the Windows process sandbox, with issue numbers, CVEs and fixed builds

How the chain works

Chrome runs each site's JavaScript in a renderer process that the operating system locks down, so even full control of that process should not reach files or other programs. Inside the renderer, V8 (the JavaScript engine) adds two software walls. Pointer compression keeps the JavaScript heap inside a 4 GiB region called the cage, and the V8 sandbox is meant to stop an attacker who corrupts memory in the cage from writing anywhere else in the process. A full chain has to beat each wall in turn.

Stage 1, V8 Maglev (Chromium issue 547819997, CVE-2026-85045, high). Maglev is V8's mid-tier optimizing compiler. When optimized code bails out to slower code, a step called deoptimization, V8 has to rebuild objects that the optimized code never actually allocated. The vulnerable path created a single mutable box for a floating-point number (a HeapNumber) and copied that one box into several distinct JavaScript objects, so writing to one changed the others. V8 treats such boxes as constants, and Xbow used that mismatch to alter an offset inside optimized code, which gave read and write anywhere in the cage. Google's release notes call it a race condition in V8.

Stage 2, animated WebP (V8 sandbox escape). WebCodecs' ImageDecoder takes ownership of an ArrayBuffer of image bytes, and Blink (Chrome's rendering engine) assumed those bytes could no longer change. The V8 sandbox does not enforce that against an attacker already writing inside the cage: Xbow unhooked a live Uint8Array view so it could keep writing to the "detached" buffer. With two WebP files of the same length, the demuxer cached frame geometry from the first while the decoder read the second, and the decoder wrote past the end of its bitmap. Heap placement turned that into one chosen 64-bit write outside the sandbox. Xbow tracks it as Chromium issue 548509153. The Register cites 536913431, which Chrome's notes list as a different Xbow-reported Blink overflow (CVE-2026-79216), so no CVE for the WebP bug is confirmed yet.

Stage 3, Crashpad (Chromium issue 545820931, CVE-2026-78952, high). Crashpad, Chrome's crash reporter, runs outside the renderer sandbox and reads a crashed renderer's memory to build a dump. On Windows, when a read returned only part of the data, Crashpad retried up to the end of the memory page without capping the size at what had been asked for, on the assumption that a suspended renderer cannot change its own memory. Xbow created a thread with a flag that keeps it running while the process is suspended and toggled page protections during the retry. A 0xb8-byte request became a 0x168-byte copy that overflowed its slot, and the corrupted dump writer was steered into calling CreateProcessW to open Calculator.

What attackers can do with it now

Xbow built the chain as research and reported it through Google's reward program. The risk now comes from the publication. Dolan-Gavitt's write-up names the issue numbers, the fix commits and the exact invariants each bug broke, and he says plainly that "the bar is significantly lower" for building a Chrome full chain. Xbow puts the pre-LLM effort for the same result at a team of four working six to nine months, and expects that within a year agents working alone could find each of the three bugs.

Google shipped stable fixes 12 days after the Crashpad report and 17 days after the Maglev one, and Xbow's write-up arrived 40 days after the Maglev fix. For an attacker using the same public models, a root-cause report plus a fix commit is a much shorter path to an exploit than starting from nothing. It only pays off against browsers still running old code.

Timeline from the chain being built on August 2 to 7, through the bug reports on August 13 and 17 and Chrome fixes on August 25 and September 3, to Xbow's publication on October 13, with the Chrome builds to check

What to do

  1. Get to a current build. Chrome stable is 155.0.8059.79/.80 on Windows and Mac and 155.0.8059.79 on Linux, released October 13. Extended Stable is 152.0.7977.167 for Windows and Mac. Google's notes confirm the Crashpad fix in 152.0.7977.64/.65 (August 25) and the Maglev fix in 152.0.7977.82/.83 (September 3). The Register gives 152.0.7977.82 as the build carrying all three fixes, but the WebP fix does not appear in Chrome's release notes yet, so aim for the current build rather than that floor.
  2. Make the update actually run. Chrome downloads updates in the background and applies them only on relaunch. On one machine, open chrome://settings/help: a Relaunch button means the fix is downloaded but not running. Across a fleet, set the RelaunchNotification policy to 2 (Required) and RelaunchNotificationPeriod to a deadline in milliseconds; the default is 604800000 (one week), and 86400000 gives users 24 hours. RelaunchWindow moves the forced restart into a maintenance window, and RelaunchFastIfOutdated (Chrome 137 and later) cuts the period to two hours once the running version is more than a set number of days out of date. Chrome restores open tabs after the relaunch. On Windows the policies live under HKLM\SOFTWARE\Policies\Google\Chrome.
  3. Cover the other Chromium browsers. Microsoft Edge supports the same four policy names under HKLM\SOFTWARE\Policies\Microsoft\Edge. Edge numbers its builds differently from Chrome, so check edge://settings/help against Microsoft's Edge security release notes. Brave shows its underlying Chromium version at brave://version.
  4. Find the slow ones. Desktop apps built on Electron, such as VS Code, Slack and Discord, ship their own copy of Chromium and update on the vendor's schedule. Electron lists the Chromium version in each of its releases, so ask the vendors of your Electron apps, in-house ones included, which release they ship and whether it carries these fixes.
  5. Hunt for the Crashpad stage. On Windows the Crashpad handler runs as chrome.exe with --type=crashpad-handler on its command line, and it has no reason to start a shell. In Sysmon process creation events (Event ID 1), search for ParentCommandLine containing crashpad-handler; Xbow's demo launched cmd /k calc.exe that way. Any hit deserves a full investigation of that host.

Patch to exploit is getting shorter

Browser vendors are quick; most of the lag is on the customer side. Without policy, Chrome only changes its menu to say a relaunch is needed and never forces one, and many people never close the browser at all. Agents helped build this chain from scratch in six days, so the relaunch deadline belongs in the same patch policy as the operating system, measured against the version actually running. That includes the Chromium inside Electron apps, which updates only when each app vendor ships a new release.

Our safeguarding and hardening work sets browser update and relaunch policy across Chrome, Edge and other Chromium browsers, and our security operations team builds detections like the Crashpad parent-process hunt above. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.


Sources: Xbow: XBOW built a Chrome full-chain exploit, Xbow Labs: Zero to Calc in Six Days, The Register, Chrome Releases: Chrome 152 stable, August 25, Chrome Releases: 152.0.7977.82, September 3, Chrome Releases: 155.0.8059.79, October 13, Chrome Releases: Extended Stable 152.0.7977.167, Chrome Enterprise policy list, Microsoft Edge RelaunchNotification policy.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.