GPT-5.6 Sol Helped Chain 3 Chrome Bugs in 6 Days on $40K of API Calls. Google Paid $250K

• Book: Ship It — the pragmatic startup tech stack
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

A crafted web page, opened in Chrome Beta on Windows, pops up Calculator. That is the demo XBOW attached to the full exploit chain it published on October 13: three bugs, from that page to code execution outside Chrome's sandbox. Google paid $250,000 for it, which XBOW calls "the first under its 2026 new rules".

The cost is the number people will repeat. XBOW's research write-up says the team ran OpenAI's GPT-5.6 Sol through Codex, and that "reconstructing usage from the archived Codex logs puts the six-day campaign at roughly $40,000 in API charges" (XBOW). The announcement credits "OpenAI's GPT-5.6 Sol and its predecessors" across the wider project. The write-up's estimate for the same job before LLMs: "a team of four around 6-9 months."

XBOW says "All three bugs in our chain are fixed". Its news release puts the exposure at "an estimated one billion people running Chrome on Windows globally", and says "the vulnerabilities were never used against Chrome users".

Three bugs, three walls

Chrome's sandbox design treats code in a sandboxed process as possibly hostile, so web content runs inside a sandbox, and V8 adds its own sandbox around its heap. A full chain has to get through every wall. Brendan Dolan-Gavitt's write-up lists the three stages:

GBHackers' summary lists the fixes as XBOW describes them: stop reusing mutable HeapNumbers, keep WebP output buffers inside bitmap bounds, and cap Crashpad retries at the original request length. The write-up cites Chromium issues 547819997, 548509153 and 545820931. XBOW's news release lists CVE-2026-85045 for the WebP bug and CVE-2026-78952 for the Crashpad bug. It gives no CVE for the V8 bug, and none of XBOW's three posts names the Chrome versions that carry the fixes.

Three stages, three walls: V8's cage, the renderer sandbox, then the crash handler outside both.

Who did the work

In XBOW's account, the agents "searched Chrome's source code, tested ideas, built proofs of concept, and wrote the earliest drafts of the exploit." The people "set the strategy, chose where to look," then "checked the agents' work, and redirected the agents." The blog names four researchers: Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee and Willem Pinckaers.

The setup is the part worth copying. The team did not ask one agent for an exploit end to end. It ran parallel campaigns with narrower goals: broad vulnerability search, V8 memory corruption, a V8 sandbox escape, a renderer sandbox escape, and integration (write-up). Each stage had a clean interface and a backup route.

The backup routes got used. The first version of the chain used a Gin bug for its V8 sandbox escape, and that bug duplicated an existing report, issue 542670566. The team swapped in the WebP escape after "a very stressful few hours." An earlier chain had already died when its final stage collided with a bug Google had found internally months before.

Dolan-Gavitt draws two lessons. "These kind of invariant violations may be where LLMs shine," he writes, and "you will have more success if you give your agents high-quality examples to follow." He also writes, "we did apply a fair bit of our own human expertise and judgment." So I wouldn't read the $40,000 as what the same chain would cost anyone else.

Five narrow campaigns run in parallel, with people choosing targets and joining the stages.

$40,000 against months of work

Six days and about $40,000 in API charges, set against XBOW's own estimate of 6–9 months for a team of four. For scale, CyberInsider notes that the exploit broker Crowdfense advertises up to $1.5 million for desktop Chrome zero-day chains. That figure is an advertised ceiling; nobody is reported to have paid it here.

The announcement, which XBOW's CEO Oege de Moor wrote, makes a prediction: "we believe that within a year, each of the three bugs could be found by agents working on their own." That comes from a company that sells AI offensive security, so weigh it that way.

It is not the only one this week. On October 14, curl 8.23.0 shipped fixes for 24 CVEs, and AISLE says its AI-driven audit found 18 of them (my earlier post breaks down the advisory credits). My reading: the gap between a bug existing and someone finding it is shrinking, and so is the price of finding it. Your patch window shrinks with it.

What to change this week

Relaunch the browser. Chrome downloads updates in the background, and Google's help page says "the update applies the next time you restart Chrome." XBOW's advice: "when the Update button appears, restart it every time."

Find the Chromium you ship. Electron "embeds Chromium and Node.js to bring JavaScript to the desktop." Playwright's docs say "Each version of Playwright needs specific versions of browser binaries to operate." A desktop app, a headless-Chrome scraper or a PDF renderer in a container image gets a browser fix when you bump the package and redeploy, not when Google ships. XBOW's posts don't say which embedders or versions were affected, and stage 3 is Windows crash-handler code, so check your embedder's release notes rather than assuming.

In an Electron app, the process docs expose both versions:

// In your Electron main process
console.log('Chromium', process.versions.chrome);
console.log('Electron', process.versions.electron);

To get pull requests for those packages every day, Dependabot supports an allow list:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-name: "electron"
      - dependency-name: "playwright"
      - dependency-name: "puppeteer"

allow works as a whitelist: this entry checks only those three packages, and every other npm dependency in / stops getting update PRs from it. Use it as-is only in a repo with no other npm entry for that directory. If you already have one, don't add allow to it; set its interval to "daily" instead.

Point agents at your own code first. XBOW's closing advice: "assume your applications are exploitable and test your own software before someone else does." If six days and about $40,000 in API charges, plus an expert team, can reach Chrome, your service's parsers and file handlers are a smaller job.

What this doesn't show

People steered every stage, and the six days sat on top of earlier research and failed submissions, as GBHackers points out. The $40,000 is XBOW's own reconstruction from its Codex logs; nobody has audited it. The billion-person figure is XBOW's exposure estimate: people running Chrome on Windows. The demo ran on signed Chrome Beta. None of XBOW's three posts quotes Google; CyberInsider reports that Google approved the payment on August 31, according to its public issue record. I haven't run any of this myself.

If a small team with agents can do this to a browser in a week, what's the first thing in your own stack you'd point them at? Tell me in the comments.

If this was useful

A fix only reaches your users when your own pipeline ships it. If you bundle a browser in an Electron app or a headless-Chrome service, the patch cadence is yours. Ship It covers the stretch between localhost and production for a small team: hosting, deploys, CI/CD, payments, auth and monitoring.

I also build Hermes IDE, a free, source-available app that runs Codex, Claude Code and other CLI agents side by side, each in its own terminal and worktree, on macOS, Windows and Linux (GitHub).