Six Days, $40K, One Full Chrome Exploit Chain: XBOW Proves the Cost of Attack Is Collapsing

A full exploit chain that starts on an ordinary web page, breaks through both of Chrome's sandboxes on Windows, and pops Calculator used to be six to nine months of work for a four-person elite team. Between August 2 and August 7, 2026, AI security company XBOW built one in six days, spending roughly $40,000 in API charges, with agents driven by the publicly available GPT-5.6 Sol. Google reproduced the chain, fixed all three vulnerabilities, and paid a $250,000 Chrome full-chain reward under the Vulnerability Reward Program rules that took effect in April 2026 — the first payout under the new rules.

On October 13, XBOW Labs published a long technical write-up laying out the root causes, exploitation techniques, and engineering details of the entire chain. This is not a marketing piece about "AI finding bugs." It is a calm engineering retrospective: agents did the vast majority of the searching and coding, but human strategic judgment determined how far it could go. And it answers exactly one question — when the cost of top-tier offensive capability collapses from "a nation-state team for half a year" to "six days plus $40,000," which of the defender's old assumptions still hold?

The facts: what actually happened in those six days

The timeline is the skeleton of this story. In January 2026, XBOW set the goal at an all-hands meeting in Malta: build a browser full chain before Black Hat. Their first Chrome full chain took about two months to complete and submit. The award-winning one was built in a six-day sprint, Sunday August 2 through Friday August 7, in Las Vegas during Black Hat and DEF CON week.

On division of labor, XBOW did not ask one agent to write an exploit end to end. Instead, the work was split into five parallel campaigns with narrower goals: broad vulnerability search, V8 memory corruption, a V8 sandbox escape, a renderer sandbox escape, and integration. Agents running OpenAI's public gpt-5.6-sol model searched source code, tested hypotheses, built proofs of concept, and drafted exploit stages; human researchers chose targets, supplied context, challenged the agents' results, decided which stages to join, and prepared backup routes for each stage with clean interfaces between them, so one stage could be replaced without rebuilding the whole chain. Reconstructing usage from the archived Codex logs puts the six-day campaign at roughly $40,000 in API charges.

The result was a three-stage full chain: a V8 Maglev compiler bug, an animated-WebP decoder bug, and a Crashpad crash-handler bug. It started with JavaScript in an ordinary Chrome tab and ended with native code execution outside the sandbox — Calculator popping up in the demo. Google's rewards panel approved the $250,000 payout on August 31; the three bugs were fixed in Chrome 152.0.7977.65 (August 25) and 152.0.7977.82 (September 3). XBOW estimates this class of flaw sat in the path of roughly one billion Chrome users on Windows before the fixes — and confirms the bugs were never used against real users.

Dissecting the chain: three "immutable" assumptions, broken three times

Chrome locks web page code inside two cages: V8 first confines JavaScript-engine memory corruption inside an in-process "pointer-compression cage" (most JS heap objects packed into a reserved 4 GiB region), wrapped by an OS-level renderer process sandbox. This chain jailbreaks through each layer with one bug apiece, and XBOW researcher Brendan Dolan-Gavitt flagged a beautiful coincidence in the retrospective: at their core, all three bugs were about mutating something assumed to be immutable.

Stage 1: V8 Maglev reused a mutable boxed number during deoptimization. Maglev is V8's mid-tier optimizing compiler. When optimized code's assumptions stop holding at runtime, V8 must "deoptimize," materializing virtual objects that only existed in the compiler's imagination into real JS objects. The bug: Maglev created a mutable old-space HeapNumber for a virtual double field and stored the object itself in the deoptimization literal array, while the generic materializer copied the object's identity — not just its numeric value — into each reconstructed owner. Nested activations could therefore produce distinct JS objects whose double fields shared one mutable HeapNumber, violating the compiler's internal invariant that HeapNumberRef is only created for immutable HeapNumbers. The exploit aimed this at Array.prototype.at(): one compiler observation saw a safe index and approved an in-bounds access, while another observation of the nominally same constant supplied the actual load offset, so changing one object's double field changed the offset used by optimized code without invalidating the earlier bounds reasoning. Three optimized load functions were enough to disclose nearby V8 pointers and forge an array, which bootstrapped rewriting a real Uint8Array's metadata and extended ordinary indexed access across the entire 4 GiB cage. The public root-cause report is Chromium issue 547819997.

Stage 2: animated WebP — cached geometry met tampered bytes. This was the V8 sandbox escape, but XBOW deliberately avoided attacking the sandbox itself and instead hunted for things the sandbox's threat model "allows" but that looked problematic: the V8 sandbox does not promise that a transferred ArrayBuffer stays semantically immutable against an in-cage attacker, while Blink assumed it could trust exactly that. The exploit first used the stage-1 in-cage write to remove a live Uint8Array view from its JSArrayBuffer's detach-notification chain; when ImageDecoder transferred the buffer, V8 detached only the views it still knew about, and optimized writes through the omitted view stayed usable. Blink believed it owned the bytes exclusively; the attacker could still change them. Then came a textbook TOCTOU: the PoC placed two same-length, independently valid animated WebPs in one backing store — WebP A describing a 64×64 canvas with a 48-pixel-wide first frame starting at x=16, whose frame rectangle and payload location the decoder cached — then the surviving view swapped the bytes for WebP B, whose payload decoded a full 64×64 frame. The decoder described the output buffer with A's cached geometry but fed it B's pixels, writing past the native SkBitmap allocation. The production exploit tuned the geometry for PartitionAlloc and used the overflow to plant two staged WebPDecBuffer descriptors into the decoder's fields, letting the genuine WebPCopyDecBufferPixels() routine perform "one chosen 64-bit native write" — the entire interface between this stage and the next. The public report is Chromium issue 548509153.

The handoff: island hopping. One write is not arbitrary code execution, and protected code pointers were off limits. The exploit rewrote the writable base used to locate V8's process-wide Wasm Code Pointer table and supplied a correctly typed replacement entry, adapting XBOW's Native Team's "island hopping" technique: 13 64-bit immediates hidden in Liftoff-generated Wasm code served as instruction "islands," linked by short jumps into a roughly 70-byte loader that allocated writable memory, copied the Crashpad payload, flipped the mapping executable, and called it.

Stage 3: Crashpad — the "frozen" renderer was never frozen. Chrome's Crashpad handler runs outside the renderer sandbox: on a snapshot request it suspends the renderer, then reads data structures from its address space. The flaw sat in the ERROR_PARTIAL_COPY recovery path of ProcessMemoryWin::ReadUpTo() — after a failed read, it retried reading to the end of the page on the theory that the request had crossed a readable/inaccessible page boundary. That reasoning rested on a temporal assumption: a suspended process's address space cannot change. But Windows lets a thread created with THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZE keep running across NtSuspendProcess() (the exploit used flags 0x42). So while Crashpad treated the renderer as frozen, a freeze-exempt thread flipped attacker-controlled source pages between PAGE_NOACCESS and PAGE_READWRITE: a small first read failed because the whole page was momentarily inaccessible, Crashpad misread that as a page crossing, the thread flipped the page readable, and the retry read all the way to the page end — copying more than the caller asked for and smashing the adjacent heap slot holding a SnapshotMinidumpMemoryWriter. Careful allocation ordering made the corrupted writer a live one; Crashpad later entered its vtable into WriteObject(), then through a substituted CopyingOutputStreamAdaptor vtable copied controlled bytes to a writable address in chrome.exe, finally calling FallbackCrashHandlerLauncher::LaunchAndWaitForHandler() with cmd /k calc.exe. Windows randomizes module addresses per boot rather than per process, which let the exploit derive the handler's addresses from its own process. The public report is Chromium issue 545820931.

The tensest moment: after a bug collision, swapping a whole stage in hours

The chain nearly died before submission. The first version's middle stage used a vulnerability in the Gin component — which turned out to be a bug Google already knew about (Chromium issue 542670566), voiding the whole stage. What saved it was the engineering discipline set on day one: independent stages, clean interfaces, a backup for everything. In "a very stressful few hours," the team ripped out the Gin stage and dropped in the animated-WebP one. The chain held; Google confirmed the calc pop.

This episode deserves its own spotlight because it reveals a new normal for LLM-era bug hunting: collisions are becoming the dominant risk. Now that everyone is pointing LLMs at codebases like Chrome — Google included — a VRP reporter bringing nothing beyond the base model is, in Dolan-Gavitt's blunt words, very likely to collide. His own first full chain died when its final stage collided with a bug Google had found internally months earlier. In other words, models have flattened the ability to find known-pattern bugs; the scarce resources are now twofold: a distinctive understanding of the target (knowing where to look for invariants nobody else has questioned), and the engineering ability to assemble a chain (modular, swappable, with backups). XBOW won this round on the second one.

Six days plus $40,000 vs. six to nine months: the cost collapse is the real story

The three numbers hit hardest side by side. XBOW's own retrospective estimate: pre-LLM, a Chrome full chain took a team of four around 6–9 months; their own first chain (already LLM- and agent-assisted) took about two months; the awarded chain took six days and roughly $40,000 in API charges. CEO Oege de Moor quoted a "three-letter intelligence agency" veteran: his team used to spend six months finding this kind of vulnerability and getting total access. "We did it in six days."

The cross-market comparison is even more telling. Security press noted that exploit broker Crowdfense advertises up to $1.5 million for desktop Chrome zero-day chains — the black market's ceiling price. Google just paid $250,000 under its new rules, and in the same week quadrupled the base bounty for memory-safety bugs to $2,000 (after cutting payouts in April). White-hat prices are rising, the black-market ceiling sits where it is, and the cost of producing a chain has fallen to the tens-of-thousands range. The triangle says: the "cost of discovery" is decoupling from the "price of trade," and the discovery side is depreciating far faster than the price side.

Another story from the same week is the perfect corroboration: curl 8.23.0 shipped fixes for 24 CVEs, and AI-audit firm AISLE claims its AI-driven audit found 18 of them. Different targets, different teams, same direction — the time and price between a bug existing and a bug being found are both shrinking. Your patch window shrinks with them.

The human–machine split: what the agents did, what the humans did

XBOW's retrospective honestly cools the "AI did everything" narrative. Agents on gpt-5.6-sol — deliberately a public model, not a restricted cyber model — did the vast majority of the legwork: reading Chrome's source, testing hypotheses, writing PoCs, drafting early exploit code, across five campaigns running in parallel. Humans did everything requiring judgment: choosing targets, supplying context, pulling agents back when they drifted, deciding which stages to join, and designing the swappable module interfaces and backup routes.

Dolan-Gavitt's own line: "we did apply a fair bit of our own human expertise and judgment." He also left a methodology note for whoever comes next: if you want agents to produce, give them high-quality examples to follow. The island-hopping loader and the modular assembly approach in this chain came from exploit techniques originally hand-authored by members of XBOW's Native Team. In other words, agents amplify existing top-tier human expertise; they do not conjure it from nothing. Six days and $40,000 bought the productivity of "one top human researcher leading a tireless crew of junior researchers" — not "one prompt for one Chrome chain."

The distinction matters because it determines how replicable this is. XBOW stresses it too: this does not mean anyone with $40,000 and six days can reproduce a Chrome chain. But it does mean the bar is "significantly lower" — a game once reserved for nation-state teams and elite boutiques is now playable by an experienced security researcher with a cloud API budget.

Three inferences for the defense

First, the patch-window assumption needs rewriting. Defenders used to assume months of buffer between a vulnerability's introduction and its weaponization, patching on a quarterly rhythm. When discovery costs fall to a six-day scale, the only buffer left is engineering speed from disclosure to fix. Chrome actually did well here: the award approved August 31, fixes shipped in 152.0.7977.65/.82. But there is a second layer of latency on the user side — Chrome downloads the patch automatically, yet the fix only takes effect after a browser restart. XBOW's announcement specifically nagged readers: when the Update button appears, restart, every time. For enterprises, the compliance metric should shift from "was the patch pushed" to "was the restart completed."

Second, sandbox trust boundaries need re-auditing — especially "assumed immutable" invariants. The most steal-worthy part of this chain for defenders is XBOW's targeting logic: don't attack the sandbox mechanism head-on; hunt the "allowed but suspicious" obligations in its threat model — downstream code that must defend against an in-cage attacker's concurrent modification, post-transfer buffer semantics, page-protection flips in a "frozen" process. Maglev violated "HeapNumbers are immutable," WebP violated "transferred bytes are mine exclusively," Crashpad violated "a suspended process's address space doesn't change." All three are time/state assumptions failing under a new threat model. And "invariant violations" are exactly what LLMs are best at enumerating: encyclopedic knowledge of OS APIs and open-source code, systematically asking "under what circumstances does this invariant fail." Defense audit checklists deserve a dedicated chapter for "invariant assumptions across trust boundaries."

Third, governance of agent-automated bug hunting is already behind. Google recently closed its OSS VRP to product vulnerability submissions after a flood of AI-generated reports. The reward rules were rewritten in April and base bounties raised again in October — the platform is adjusting mid-flight. But the bigger governance problem is on the offense side: a full chain producible with a public model and tens of thousands of dollars is equally affordable to criminal crews and spyware vendors. XBOW's CEO says restricting access to the most capable models "is the wrong question, because the model we used is already public" — self-serving coming from someone selling AI offensive capability, but logically hard to refute. If you can't throttle supply, you accelerate the demand side: test your own code first.

Verdict section: is the CEO's "one-year prediction" credible?

Oege de Moor closed the award announcement with a prediction: "we believe that within a year, each of the three bugs could be found by agents working on their own." It is the single sentence most worth stress-testing. Let's take it apart in three layers.

Layer one: each of the three bugs being "found" by an agent — highly credible. Note what the three root causes share: they are all "explicit invariant violations." The compiler comments say HeapNumberRef is only for immutable HeapNumbers; the transfer semantics say old views are detached; Crashpad's retry logic says the suspended process doesn't change. The discovery pattern for such bugs — read the invariant, enumerate violation scenarios, build a PoC — is exactly the pipeline LLM agents do best: broad knowledge, parallel trial and error, unafraid of reading hundreds of thousands of lines of code. These three bugs were already dug up by agents inside human-drawn boundaries; handing the "drawing the boundaries" step to a stronger next-generation agent within a year is no stretch.

Layer two: "found independently" is not "chained independently" — discount here. Finding three bugs and assembling them into a reliable web-page-to-calc.exe chain are two different engineering disciplines. The former is a search problem; the latter is systems integration: interface design, backup routes, swapping a stage within hours of a collision, Windows build fingerprinting and offset retargeting, CET/CFG-safe call sequences. What saved this chain was human-designed modularity. The prediction cleverly says "each bug found," sidestepping "the whole chain assembled." A year from now, the likelier picture is the division of labor shifting forward — agents finding bugs, humans chaining — not unattended end-to-end weaponization.

Layer three: discount for commercial motive, but the direction is probably right. De Moor sells an AI offensive platform; "within a year" carries marketing. But even stretching the timeline to two or three years, the trend line is clear: XBOW's first chain needed two months in early 2026; by mid-year agents delivered an award-winning chain in six days; AISLE's AI audit claimed 18 CVEs in one curl release. The slope of the capability curve is what it is. The real question isn't "is one year accurate" but: when the "finding" step gets automated, can the defender's organization keep up? Bounty hunters will race agents on speed; enterprises will need agents sweeping their own code first — and de Moor's other line stands: "Defenders have an advantage attackers never will: they can test their own code first."

Our verdict: the prediction's wording is optimistic and its timeline aggressive, but the end state it points to — vulnerability discovery turning from craft into compute-intensive pipeline — is already arriving. Read "within a year" as "soon," and "found on their own" as "humans only doing target selection and assembly," and the prediction basically holds.

Three sentences for people who write code

First, memory safety is no longer "best practice" — it's the survival line. Two of the three chain stages were memory-safety bugs (the Maglev out-of-bounds read/write, the WebP heap overflow); the third was a concurrency-assumption bug. Memory-safe languages, fuzzing, sandboxing critical components — once bonus points, now mandatory answers after the attack-cost collapse.

Second, you use agents to ship code faster; attackers use the same class of agents to find your bugs faster. That is the new symmetric reality for every developer in the vibe-coding era. Every feature your agents help you ship is another reason for the other side's agents to scan your code. Having agents review your own code before release moves from "nice to have" to "required."

Third, update Chrome — go hit restart now. All three bugs are fixed in 152.0.7977.82 and later, and XBOW confirms they were never exploited in the wild. But "fixed upstream" and "fixed on your machine" are two different things: the patch only takes effect after a restart. Check your version number, and leave automatic updates on.

Six days, $40,000, one full chain. These numbers will be remembered not because they broke a technical record, but because — stamped by a $250,000 check written by Google itself — they certified for the first time that "the cost of attack is collapsing." Dolan-Gavitt closed the long write-up with a single piece of advice: "Six days and $40k is not a lot of time or money when the payoff is a Chrome chain. Defend accordingly."