Security company XBOW has disclosed how its researchers used AI agents running OpenAI’s publicly available GPT-5.6 Sol model to build a three-bug Google Chrome exploit chain in six days. The chain started with JavaScript in an ordinary browser tab and ended with code running outside Chrome’s sandboxes on Windows.
Google confirmed the flaws, fixed them and paid XBOW $250,000, the first maximum full-chain reward under the Chrome Vulnerability Reward Program rules introduced in 2026. XBOW says the exploit was built between August 2 and August 7 and was not used against Chrome users. Two of the bugs received public CVE identifiers and were fixed in Chrome 152 updates released in August and September; the known chain is closed in version 152.0.7977.82 and later.
The six-day figure is striking, but it does not describe an autonomous model independently deciding how to compromise Chrome. XBOW’s account shows a tightly managed research operation: agents searched source code, tested hypotheses, produced proofs of concept and drafted exploit stages, while experienced researchers chose components, supplied techniques, checked results and decided how to connect the bugs.
Three bugs crossed two security boundaries
Modern Chrome does not rely on a single wall between a website and the operating system. JavaScript runs inside the V8 engine, which has its own in-process sandbox, while the renderer process sits inside a second operating-system sandbox. A useful exploit therefore needs more than one vulnerability: it must gain control in the renderer, cross V8’s containment boundary and then escape the renderer process.
XBOW’s technical report describes three stages:
- V8 Maglev compiler: a deoptimization bug let distinct JavaScript objects share a mutable boxed number that the compiler treated as immutable. By changing the number after one compiler check, the exploit could create an out-of-bounds access and extend a
Uint8Arrayacross V8’s four-gigabyte pointer-compression region. - Animated WebP decoding: the exploit kept a usable view of an
ArrayBufferafter Chrome believed the transferred buffer had become exclusive to its image decoder. It swapped one valid animated WebP for another at a carefully chosen moment, causing Blink to combine cached geometry from the first image with pixel data from the second. The resulting heap overflow was shaped into one chosen 64-bit write outside the V8 cage. - Crashpad on Windows: Chrome’s unsandboxed crash handler assumed that suspending the renderer made its memory stable. Windows permits a thread created with
THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZEto keep running, however. The exploit used such a thread to change page protections between two Crashpad reads, turning a retry into a heap overwrite and ultimately launching a process outside the renderer sandbox.
The first stage is tracked as Chromium issue 547819997 and CVE-2026-85045. Google fixed it in Chrome 152.0.7977.82. The Crashpad stage, CVE-2026-78952, was fixed in Chrome 152.0.7977.65. XBOW’s public write-up links the WebP root-cause report and landed Chromium changes but does not identify a public CVE for that middle stage.
Why the WebP stage mattered
The middle bug illustrates why browser exploit chains are difficult to find by reviewing components in isolation. Each WebP file used by the proof of concept was valid. The unsafe condition appeared only when Chrome cached the frame rectangle from one file, accepted changed bytes from another and passed an output buffer description to libwebp before checking whether the decoded dimensions still matched.
In XBOW’s simplified reproducer, the cached image described a 48-pixel-wide frame starting 16 pixels into a 64-pixel canvas. The replacement payload decoded a full 64-pixel-wide frame. Chrome advanced the output pointer to the cached starting position but still advertised enough space for the wider replacement, allowing the decoder to write past the bitmap allocation.
The production chain arranged the overflow so the pixel allocation sat beside a live WebPIDecoder object in the same allocator bucket. Overwriting the decoder’s fields let a normal WebP copy routine move one selected value to one selected native address. That single write was enough to redirect a WebAssembly code pointer and run a small loader inside the renderer.
Crashpad’s frozen-process assumption failed
The final stage did not exploit a traditional missing permission check. It broke a timing assumption.
Crashpad suspends a renderer before reading its memory to construct a crash snapshot. If a Windows memory read returned ERROR_PARTIAL_COPY, the vulnerable code retried from the same address to the end of the memory page. That was safe only if the renderer really stayed frozen: a failed read was treated as proof that the original request had crossed from a readable page into an inaccessible one.
XBOW’s renderer payload created a freeze-exempt thread, made a source page inaccessible for the first read and then made it readable before the retry. Crashpad consequently copied 0x168 bytes into a destination slot sized for 0xC0 bytes, overwriting the next heap object. The fix clamps the retry to both the page boundary and the caller’s original requested length. A second check rejects any read result larger than the remaining destination space.
This is more than implementation trivia. The three bugs shared a pattern: code trusted something to remain immutable or stable when an attacker could still change it. The Maglev compiler trusted a boxed number, Blink trusted transferred image bytes, and Crashpad trusted a suspended process. AI source review may be especially useful at surfacing these cross-layer invariant failures because it can search large codebases and connect obscure operating-system behavior to application assumptions.
What the AI did, and what the headline leaves out
XBOW estimated about $40,000 in API charges for the six-day campaign. Its agents ran parallel searches covering broad vulnerability discovery, V8 memory corruption, V8 sandbox escape, renderer sandbox escape and final integration. They also drew on high-quality examples and exploit techniques previously developed by XBOW’s human researchers.
Human judgment remained central. Brendan Dolan-Gavitt led the awarded build with AI agents, while Andres Luksenberg, Baul Lee and Willem Pinckaers were part of the wider project. The team had started pursuing a Chrome full chain months earlier, and its first attempt took roughly two months. When Google reported that one stage of a later chain duplicated a known bug, the researchers could replace it quickly because they had designed independent stages and backup routes.
That context does not erase the acceleration. A modular, working chain that crosses two mature sandboxes in six days for a compute bill well below the bounty is an important change in vulnerability economics. It also does not prove that any user with $40,000 can reproduce the result. The campaign depended on specialist exploit knowledge, orchestration, prior work, careful validation and access to enough compute to run many searches in parallel.
Chrome users should verify the restart, not just the download
There is no indication that this chain was exploited in the wild, and all three known bugs are fixed. The immediate task is straightforward:
- Open Chrome’s three-dot menu and select Help > About Google Chrome.
- Let the browser finish downloading any available update.
- Select Relaunch. Downloading an update is not enough; the patched browser code loads only after Chrome restarts.
- Confirm the version is 152.0.7977.82 or later. A normally supported Chrome installation in October 2026 should be substantially newer.
Organizations should also check managed-browser relaunch policies. Chrome can stage an update while long-lived sessions continue using the vulnerable build. Enterprise controls can set relaunch notifications and deadlines so a downloaded security fix does not wait indefinitely for users to close the browser.
For software teams, the stronger lesson is to test assumptions at component boundaries. Memory-safe checks inside one library do not necessarily protect a workflow that combines mutable shared buffers, cached metadata and privileged helper processes. Threat modeling should include what an attacker can change between validation and use, even when an API says a buffer was transferred or a process was suspended.
The disclosure changes the clock for defenders
XBOW’s result is a defensive disclosure: Google received the bugs, shipped fixes and paid the researchers before technical details became public. The same economics can still shorten the time available between a new code change, vulnerability discovery and weaponization.
That puts more weight on rapid browser restarts, defense in depth and continuous testing of high-value code. It also raises the value of modular red-team work. XBOW’s team did not ask one agent for an end-to-end attack and hope for a correct answer. It divided the problem, demanded concrete proofs of concept and preserved replaceable interfaces between stages. That structure, as much as the underlying model, explains why the team could discard a duplicate bug and still finish a working chain.
