deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

Six days, three bugs: XBOW's AI-built chain takes Google's first $250,000 Chrome reward

XBOW chained a V8 Maglev bug, an animated WebP decoder flaw and a Crashpad memory bug to escape Chrome's renderer sandbox, winning Google's first $250,000 full-chain reward. AI agents built it in six days.

Six days, three bugs: XBOW's AI-built chain takes Google's first $250,000 Chrome reward

Google has paid out its first $250,000 full-chain reward under the Chrome Vulnerability Reward Program rules introduced in April 2026, and the winning entry is a three-bug exploit chain that security firm XBOW assembled in six days, largely with AI agents doing the legwork. According to XBOW's technical write-up, which reached the front page of Hacker News, the chain begins with ordinary JavaScript in a tab and ends with code running outside the renderer sandbox — demonstrated by a page in a signed Chrome Beta build launching the Calculator app.

Chrome defends a tab with two boundaries: V8's in-process sandbox, which keeps JavaScript heap corruption inside a reserved 4 GiB region where pointers are stored as offsets, and the operating-system sandbox around the renderer process. XBOW's chain defeated both, one bug per hop.

A shared, mutable number inside V8

The first bug sits in Maglev, V8's mid-tier optimizing compiler, and turns on deoptimization. Optimized code runs on assumptions about the values it handles; when one stops holding, V8 rebuilds ordinary JavaScript objects, including fields that until then existed only as compiler-internal values. A field holding a double must be materialized as a HeapNumber, and that is where things went wrong.

XBOW found that the vulnerable Maglev path allocated a single old-space HeapNumber for such a value and placed the object itself into the deoptimization literal array — the pool of constants the compiler treats as immutable. The generic materializer then copied that exact object, not just its numeric value, into every reconstructed owner. With nested activations, V8 could hand distinct JavaScript objects double fields that secretly shared one mutable HeapNumber, contradicting an invariant stated elsewhere in V8's source: HeapNumber references exist only for immutable values.

The exploit aimed that disagreement at Array.prototype.at(). One compiler observation of the "same" constant approved an in-bounds access, while a second supplied the actual load offset. Because the shared box was mutable, changing one object's field shifted the offset without invalidating the earlier bounds reasoning. Three optimized load functions were enough to disclose nearby V8 pointers, recover the layout of a packed-double array, and bootstrap a forged array; rewriting the metadata of a genuine Uint8Array through that forgery then stretched indexed access across the entire 4 GiB cage. To keep addresses stable, the exploit parked references in V8's large-object space and let garbage collection keep them current.

V8's fix removes the literal-object special case. Virtual HeapNumbers now travel the ordinary captured-object materialization path, and Maglev explicitly bars their deduplication, so every deoptimization materializes a fresh box.

Two more bugs, two more boundaries

The second bug, in the animated WebP decoder, mixed cached geometry with image bytes that had changed after that geometry was computed, granting one attacker-chosen native write outside the cage. Notably, XBOW did not attack the V8 sandbox's own machinery; it exploited a property the sandbox deliberately leaves unenforced — one that the Blink rendering engine incorrectly treated as guaranteed.

The third bug lived in Crashpad, Chrome's crash-reporting handler. Crashpad assumed the memory of a frozen renderer could not shift beneath it, so when a read from that renderer failed, it still relied on the observation. An overflow there handed the exploit code execution in the unsandboxed crash handler — and with it, unsandboxed code on the host.

Six days and roughly $40,000 of compute

XBOW ran the campaign from Sunday, August 2 through Friday, August 7, splitting the effort into parallel tracks — broad vulnerability search, V8 memory corruption, V8 sandbox escape, renderer sandbox escape, and integration — rather than asking one agent for an end-to-end exploit. Agents running OpenAI's gpt-5.6-sol model searched source code, tested hypotheses, and built proofs of concept and exploit stages, while XBOW researchers picked targets, supplied context, challenged results, and decided which components to join. Each stage exposed a clean interface and had backup routes, so one component could be swapped without rebuilding the rest. Reconstructed from archived Codex logs, the campaign cost roughly $40,000 in API charges — against a $250,000 reward.

For scale, XBOW says a Chrome full chain took a team of four about six to nine months before AI assistance, and its own first submission took two months. The firm plans to detail the chronology at an event called Unprompted in late October.

Why it matters

  • The first payout under the new full-chain rules sets a public benchmark for the market price of a complete Chrome exploit.
  • The economics have shifted: six days and roughly $40,000 of compute produced what previously took a small team most of a year.
  • The chain is also a lesson in sandbox assumptions. Both sandboxes held to their designs, but the code around them — Blink trusting an unenforced V8 property, Crashpad trusting a frozen renderer — supplied the crossings.
  • If agents can compress expert exploit development from months to days, patch and disclosure timelines calibrated to human-paced research may no longer be adequate.
  • #chrome
  • #security
  • #v8
  • #bug-bounty
  • #ai-agents

Related posts