XBOW's six-day Chrome exploit explained: what $40k of GPT-5.6 Sol did

On 13 October, security firm XBOW published a write-up explaining how it built a working exploit chain against Google Chrome on Windows in six days, with most of the grunt work done by AI agents running OpenAI's publicly available GPT-5.6 Sol. Google reproduced the chain, patched all three underlying bugs, and paid $250,000, the first full-chain reward under the Chrome bounty rules it revised this year. The interesting part is not that a model touched a browser exploit. It is the before-and-after: XBOW's own pre-LLM estimate for this job was six to nine months for a team of four.

The plain-English version

Think of Chrome as a bank vault built as a set of nested rooms. A web page runs in the innermost room. If a criminal finds a flaw in that room's lock, they still cannot reach your files, your passwords or your computer, because there are more locked doors between them and the outside world. Breaking every lock in sequence is what security people call a "full chain", and it is one of the hardest things in the field. Google values it so highly that it pays $250,000 for a responsibly disclosed one, and grey-market brokers reportedly pay far more.

XBOW is a company that builds AI systems for finding security holes. In early 2026 it set itself the challenge of producing a Chrome full chain by August. Its first attempt took about two months and was rejected because Google already knew about one of the bugs. So the team started over. Between Sunday 2 August and Friday 7 August, during the Black Hat and DEF CON conferences in Las Vegas, four researchers worked alongside AI agents running GPT-5.6 Sol, the same model anyone can rent through OpenAI's API. By Friday they had three fresh bugs that, chained together, took a visitor to a web page all the way to running a program on their Windows PC. The demonstration launched the Windows calculator, the traditional "proof of life" in this field, hence the title of XBOW's post, "Zero to Calc in Six Days".

Here is the analogy that matters. For decades, the scarce ingredient in this kind of work was expert time: a handful of people in the world who could read millions of lines of browser code and spot where a lock could be picked. XBOW's claim is that those experts can now hand the reading, guessing and testing to agents and keep only the judgement: what to look at, whether a result is real, and which pieces fit together. The experts did not go away. Brendan Dolan-Gavitt, who wrote the technical post, says the team "did apply a fair bit of our own human expertise and judgment", as The Register quotes him. But the time they needed collapsed.

Two things to hold on to. First, the bugs are fixed: The Register reports you need Chrome 152.0.7977.82 or later on Windows, and the fix only takes effect after you relaunch the browser. This was research reported privately to Google, and there are no reports of anyone being attacked with it. Second, the cost figure of about $40,000 is for API tokens over six days only, and XBOW itself says it should not be read as "anyone can do this for $40k". The honest summary is that the bar for one of the hardest jobs in offensive security dropped a lot, and it dropped using a model that is already public.

How it actually works

The problem: several locked doors

Modern Chrome is built on the assumption that bugs will exist, so it isolates the damage. A web page's JavaScript runs inside V8, the JavaScript engine, which confines itself to a fenced-off region of memory. The process around it, the renderer, is itself sandboxed by the operating system so that it cannot read files or launch programs. To do real harm from a web page an attacker needs to cross each of those boundaries in turn, and in practice that means one distinct bug per boundary. XBOW's chain, as described in its write-up and summarised by CyberInsider, used three:

Stage 3 is the one that turns a contained problem into a real one. Crashpad runs outside the renderer sandbox so it can inspect a crashed tab. A memory-safety flaw there, triggered from a compromised renderer, hands the attacker code execution in a process that is not sandboxed at all.

The old way

Before large language models, a Chrome full chain was a flagship result for a top-tier team. Dolan-Gavitt's pre-LLM estimate is six to nine months for four people. XBOW's chief executive Oege de Moor relays an unnamed "three letter intelligence-agency veteran" who said his team "used to spend six months trying to identify this kind of vulnerability and get total access", per The Register. The months go into reading enormous codebases, forming hypotheses about where assumptions break, writing test cases to confirm them, and then the slow engineering of turning a confirmed bug into something reliable.

The new way: five narrow campaigns, not one super-agent

The design choice that XBOW highlights is what they did not do. They did not hand one agent the instruction "produce a Chrome exploit". Instead the work was split into five parallel campaigns, each with a narrow goal:

1. A broad vulnerability search across the codebase.
2. Finding memory corruption in V8.
3. Finding a way out of V8's memory region.
4. Finding a way out of the renderer sandbox.
5. Integration, joining the stages into one chain.

Within each campaign, agents running GPT-5.6 Sol searched source code, tested hypotheses, built proofs of concept and drafted exploit stages. Humans chose targets, supplied context, challenged results, redirected searches, and decided which components to join. Agents also drew on existing loader techniques that XBOW's in-house Native Team had written earlier, so some of the hardest reusable engineering was already on the shelf.

On Hacker News, Dolan-Gavitt, posting under his long-standing handle moyix, added colour: over the six days the team found roughly 11 vulnerabilities and submitted three as a chain, and this specific chain was "done by one person plus agents" building on the earlier team effort (HN thread).

Why the modular design mattered

XBOW built each stage as an independent part with a backup, so that if one bug turned out to be already known it could be swapped out. That paid off within hours. The first version of this chain used a different bug for stage 2, which turned out to duplicate an existing Chromium issue. The team replaced it with the WebP decoder bug in what the post calls a "very stressful few hours". This is the practical answer to bug collisions, which had already killed their first two-month chain.

The deep dive

What "six days" and "$40,000" actually measure

Both headline numbers deserve careful handling, and XBOW is reasonably careful with them itself.

Time. The six days are the final campaign only. De Moor's blog post says the Chrome goal was set at a company all-hands in Malta in early 2026 with an August deadline. The first chain took about two months and was disqualified because its final stage collided with a bug Google had found internally months earlier. On Hacker News, moyix said the team was not staffed on the effort until around May. The six-day sprint reused techniques from the two-month chain. A fair reading is: roughly three months of staffed work produced one disqualified chain and one rewarded chain, with the second taking a week.

Money. The $40,000 is an estimate of API charges reconstructed from archived Codex logs, which indicates the agents ran through OpenAI's Codex tooling at least in part. It excludes four researchers' salaries, the earlier chain, infrastructure and XBOW's accumulated tooling. Asked on Hacker News whether this was real API spend or subscription-equivalent, moyix answered that they used the API, not subscriptions. Against a $250,000 reward, the token cost alone leaves a wide margin, which is the point XBOW wants investors and customers to notice.

The ratio XBOW itself proposes is the one worth quoting:

All three rows are XBOW's own figures. There is no independent timing study.

The bounty mechanics

Google overhauled its Chrome and Android reward programmes in spring 2026 under the banner "Evolving the Android & Chrome VRPs for the AI Era". According to Help Net Security's summary, full-chain Chrome browser-process exploits on current operating systems and hardware now earn up to $250,000, with a further bonus of up to $250,128 for exploiting an allocation protected by MiraclePtr, Google's use-after-free mitigation. Google also discontinued extra rewards for renderer code execution and arbitrary read/write on their own, shifting money toward complete chains. The Hacker News reports Google awards at most four full-chain rewards a year.

Neither XBOW nor its coverage mentions the MiraclePtr bonus, so the award appears to be the base $250,000. CyberInsider reports that Google's public issue tracker shows an engineer reproduced the chain and the rewards panel approved the $250,000 on 31 August. De Moor wrote on X that this is only the second time in Chrome's history Google has paid that amount for a full chain, and XBOW's write-up calls it the first under the rules introduced in April 2026.

For scale, SecurityWeek reports that Chrome 153, released 8 September, fixed 230 vulnerabilities and paid about $23,000 across 35 externally reported bugs, with the reporter of the in-the-wild zero-day receiving $2,500. One full chain is worth more than ten times a whole release's routine payouts.

Where this sits against other AI vulnerability work

The claim that language models can find real bugs is not new. Google's Big Sleep agent, built by DeepMind and Project Zero, reported 20 open-source vulnerabilities in August 2025. Anthropic's Project Glasswing, using the restricted Claude Mythos Preview, reported more than 10,000 high- or critical-severity findings in its first month, per CyberScoop. Those are Anthropic's own counts.

XBOW's result differs on three axes:

• The model is public. Glasswing's headline results used a gated model. XBOW used GPT-5.6 Sol, available to any API customer. De Moor's post argues this makes "should we restrict access" the wrong question, and Greg Brockman, OpenAI's president, amplified the same line.
• The target is the hardest mainstream one. Open-source libraries and server daemons are softer than Chrome, which has layered sandboxes, a dedicated security team, and weekly security updates on top of four-week major releases, so build-specific offsets go stale quickly.
• The output is a rewarded, vendor-reproduced chain, not a count of findings. Glasswing's critics focused on the patching gap: Anthropic's own disclosure dashboard showed only 97 of 1,596 disclosed findings confirmed patched as of 22 May, a figure the Cloud Security Alliance called a "disclosure velocity crisis". Here, the three bugs were reproduced, fixed and paid for by Google.

Engineering constraints XBOW discloses

The write-up is candid about fragility. The chain is Windows-specific and depends on Windows memory-layout behaviour, in particular that Windows randomises module addresses once per boot rather than per process, which let the exploit map chrome.exe at the same address in the renderer and the crash handler. Offsets are build-specific, so the exploit fingerprints Chrome builds by image timestamp and size, and the authors note that Chrome's rapid release schedule forces constant retargeting. One Windows thread-creation flag the stage-3 bug relied on is described by the authors as a feature whose purpose "remains a mystery". None of this diminishes the result, but it does mean a real attacker would face maintenance costs on top of discovery costs.

A Hacker News commenter also noted a practical mitigation: disabling the JavaScript just-in-time compiler, which Microsoft Edge offers as a setting, blocks stage 1 of this particular chain. Chrome's own "disable V8 optimisations" setting may only partly help, and the commenter was unsure about other Chromium forks. XBOW did not test Firefox or non-Chrome Chromium browsers.

What the agents could not do

XBOW's post does not report how many agent runs failed, how many false leads were chased, or token counts. It gives no per-stage breakdown of discovery time. The authors' own conclusions include "be prepared to be disappointed" and the advice to spend effort on developing one's own understanding of the target. De Moor predicts that within a year each of the three bugs could be found by agents working independently. That prediction is untested; CyberInsider calls it unproven.

Why it matters

For everyday users. Nothing to do beyond updating. The Register's guidance is Chrome 152.0.7977.82 or later, and relaunching. But the deeper point is that browser-level attacks, historically reserved for state actors and the top of the criminal market because of their cost, just became cheaper to produce. Exploit broker Crowdfense advertises up to $1.5 million for desktop Chrome chains, per CyberInsider, six times Google's reward. If the production cost falls toward a week of expert time, the economics of that market change.

For developers and builders. De Moor's prescription is blunt: assume your application is exploitable and test it before someone else does. The more actionable lesson is architectural. XBOW's win came from narrow, parallel campaigns with clean interfaces between stages and backups for every component, not from a bigger prompt. That pattern, decomposition plus human arbitration, is the same one showing up in other high-stakes agent work.

For companies. Chrome's defence in depth did its job: three bugs were needed, and all three were fixed before XBOW published. Products without that layering will fare worse. Bounty programmes also look more valuable, not less. Google's $250,000 bought a reproduced chain and three patches, far cheaper than discovering the same chain in the wild.

For the field. This feeds directly into the policy debate running this same week. The EU's AI Office has sent its first formal information requests to OpenAI and Anthropic over summer lab incidents, and OpenAI and Anthropic told UK MPs on 13 October that some safety rules should be binding. XBOW's result cuts across that debate: the dangerous capability here was in a public, unrestricted model steered by experts, not a frontier model escaping a lab. Regulating the model does not address a chain built with Codex and an API key.

Second-order effects. Expect vendors to raise full-chain rewards, expect more "AI-assisted" disclosures with cost figures attached, and expect pressure on Mozilla, Apple and Microsoft to show comparable results. Also expect the gap between finding and fixing, already the bottleneck in Glasswing, to widen if discovery keeps getting cheaper and patching does not.

What to be skeptical of

Every number is XBOW's. The six-to-nine-month baseline, the two-month first chain, the six days, the $40,000, and the "one billion users" figure all come from XBOW, a company that sells AI offensive-security products and benefits from the narrative. The one-billion figure is XBOW's estimate of how many users run affected configurations, not a count of anyone actually exposed. No outside party timed the work or audited the logs.

"Six days" is a sprint, not a project. The team had been working toward this since early 2026, had a disqualified chain's worth of techniques to reuse, and was not staffed on it until around May, per moyix on Hacker News. The honest unit is expert-months plus agent-days, not six days.

Four elite humans. Dolan-Gavitt is a well-known vulnerability researcher and former NYU professor; de Moor names the other three as Andrés Luksenberg, Baul Lee and Willem Pinckaers. The write-up says humans chose targets, challenged results and decided what to join. Without that judgement, agents may generate plausible-looking but wrong leads, and XBOW does not report the false-positive rate.

No Google statement. The Register notes Google provided no separate comment beyond fixing the bugs and paying. CVE identifiers appear only in secondary coverage; XBOW's post cites Chromium issue numbers instead.

OpenAI has an interest. Brockman's post positions GPT-5.6 Sol as a defender's tool and, per coverage of it, argues that restricting access is not the answer. That is a commercial position as much as a safety one.

Narrow applicability. Windows only, build-specific, not tested on other browsers. The HN thread's observation that disabling JIT blocks stage 1 is a reminder that specific chains are brittle even when the capability trend is real.

What to watch next

• XBOW's orchestration talk at Unprompted, end of October. The write-up promises the chronology and agent orchestration details there. That is where per-stage timing and failure counts may appear.
• OffensiveCon Tokyo. Andrés Luksenberg is scheduled to present the first, disqualified chain, which would give a second data point on the two-month figure.
• Google's next full-chain awards. Google caps full-chain rewards at four per year, per The Hacker News. Whether the remaining slots go to AI-assisted submissions will show if this is a trend or a one-off.
• Replication by others. Any team publishing a Chrome, Firefox or Safari chain with a public model and a cost figure would convert XBOW's claim into a field result.
• Policy follow-through. The EU AI Office's information requests and the UK committee's push for binding rules both frame risk as lab incidents. Watch whether either addresses capability in public models. Our earlier pieces on OpenAI's rogue-agent warning and Nadella's 'emergency brake' cover the incident-driven side of that debate.
• De Moor's one-year prediction. He says agents will find bugs of this class independently within a year. Check back in October 2027.

How this was made: researched and written by an AI model (Claude) from the primary sources listed above, then checked claim-by-claim against those sources in a separate AI fact-check pass. Spotted an error? Email [email protected] and we correct it publicly. Our process.