A web page launching Windows Calculator outside Chrome’s sandbox is the visible endpoint of XBOW’s newly disclosed exploit chain. The security company says three vulnerabilities, combined with help from OpenAI’s GPT-5.6 Sol, let its researchers move from JavaScript in a browser tab to code execution outside the browser’s security boundaries.
The successful chain came together over six days, August 2–7, 2026, with roughly $40,000 in API charges, according to XBOW. The company says Google reproduced and confirmed the exploit, awarded the first $250,000 Chrome full-chain reward under rules introduced in April 2026, and fixed all three vulnerabilities before the October 13 disclosure.
Four experienced researchers worked on the broader project, and an earlier submission preceded the six-day campaign. Humans made consequential decisions throughout. This is a concrete account of accelerated, AI-assisted exploit development, with important limits on what the timeline and cost figures represent.
Three Bugs Crossed Two Chrome Security Boundaries
A Chrome vulnerability does not automatically give an attacker control over Windows. XBOW’s technical report distinguishes two containment layers that the exploit had to cross.
V8, Chrome’s JavaScript engine, uses an in-process sandbox to contain JavaScript-engine memory corruption. Chrome also places its renderer process inside a separate operating-system sandbox. Breaking the first boundary does not remove the second.
The published chain combined three different failures to get through both.
A V8 Compiler Bug Gave Access Inside the First Sandbox
The first vulnerability affected Maglev, V8’s mid-tier optimizing compiler. It involved deoptimization, the process of reconstructing ordinary JavaScript objects when optimized code can no longer rely on its earlier assumptions.
According to XBOW, the vulnerable code reused a boxed number where separate, mutable instances were required. Different objects could then share a value the compiler treated as an immutable constant. An attacker could change that value while optimized code continued relying on assumptions made before the change.
The exploit gave JavaScript read-and-write access throughout V8’s four-gigabyte pointer-compression region, often called its cage. That was a substantial foothold, though it remained inside the first containment layer.
XBOW reports that the fix changed how those boxed numbers are reconstructed, ensuring that each relevant materialization gets a fresh instance instead of sharing the mutable object.
An Animated-WebP Decoder Bug Crossed the V8 Boundary
The second vulnerability arose from a mismatch between what Blink, Chrome’s rendering engine, assumed about image data and what an attacker controlling memory inside V8 could still change.
Ordinarily, transferring an ArrayBuffer to an image decoder detaches the original JavaScript access paths. Blink could therefore treat the transferred bytes as exclusively owned input. Those ordinary JavaScript guarantees are insufficient once an attacker has corrupted memory inside V8’s cage: XBOW says the exploit preserved a way to modify image bytes that Blink believed were no longer mutable.
The animated-WebP decoder combined previously cached image geometry with changed input data, producing a chosen write to native memory outside the V8 cage.
XBOW did not describe breaking the V8 sandbox’s intended guarantees directly. The flaw was in downstream code that relied on a stronger guarantee than the sandbox provided.
A Crashpad Flaw Reached the Unsandboxed Crash Handler
The final stage targeted Crashpad, Chrome’s crash-reporting system. XBOW describes a memory-safety flaw involving an assumption that a failed memory read from a supposedly frozen renderer represented a stable observation. The chain turned that failure into code execution in the unsandboxed crash handler.
The demonstration shows Calculator launching from a web page in signed Chrome Beta. Calculator serves as visible proof of code execution, not as the damaging payload. Execution had reached a process outside the renderer sandbox.
The demonstration establishes a working exploit path in the researchers’ environment. It provides no evidence that attackers used the chain against Chrome users or that every Chrome and Windows configuration was equally exploitable.
Four Researchers Set the Strategy and Reviewed the Agents
XBOW’s company announcement names four researchers involved in the project: Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee, and Willem Pinckaers.
Humans chose targets, supplied context, challenged results, reviewed the agents’ work, redirected searches, and decided which components to combine, XBOW says. Agents using OpenAI’s GPT-5.6 Sol searched source code, tested hypotheses, built proofs of concept, and developed exploit stages.
The researchers divided the work into parallel campaigns with narrower objectives, including vulnerability discovery, sandbox escapes, and integration. They did not ask one agent to produce a complete exploit.
One consequential human decision was to build stages with clean interfaces and maintain alternative routes. A component in an initial chain turned out to be a duplicate: Google already knew about the bug. With replacements available, the team could substitute a different vulnerability without rebuilding everything.
The six-day headline also needs qualification. XBOW’s technical account says an earlier submission took two months. Its announcement describes Dolan-Gavitt and the agents assembling the replacement chain during the August 2–7 window, drawing on that earlier experience.
Four researchers participated in the broader effort; the final rebuild centered on one researcher working with agents. “Six days” describes the successful campaign, not the total elapsed work, accumulated expertise, or preparation behind it.
The $40,000 Figure Is an API Bill, Not a Full Project Cost
XBOW says it reconstructed roughly $40,000 in API charges from archived Codex logs for the six-day campaign. The disclosure attaches a concrete resource estimate to a working exploit, beyond reporting a benchmark score.
That figure excludes any accounting of the total expense of researcher labor, earlier attempts, or the broader project. Comparing $40,000 with a $250,000 reward does not produce a reliable profit calculation or a general price for developing a Chrome exploit.
Another team might not reproduce the result with the same spending. Expert target selection, parallel exploration, review, and replacement components were all part of the process.
The time comparison needs similar care. XBOW contrasts the successful campaign with its estimate that comparable pre-LLM work could take a four-person team six to nine months. That is the company’s characterization, not a controlled experiment measuring the same researchers on the same task with and without AI.
