AI Security

Public AI model helped XBOW build a Chrome full chain in six days

XBOW used OpenAI’s public GPT-5.6 Sol to build a sandbox-escaping Chrome exploit in six days. What it means for UK patch timelines.

Stylised AI chip and browser window illustrating an AI-assisted Chrome full-chain exploit

Security firm XBOW has revealed that a small team steering agents built on OpenAI’s off-the-shelf GPT-5.6 Sol model produced a working Chrome full-chain exploit for Windows in under a week. For UK organisations, the real lesson is about patch latency: the window between a fix shipping and a capable adversary weaponising the bug is shrinking fast.

What happened

On 13 October 2026, XBOW published two accounts of a project it began in January: a corporate announcement by founder and chief executive Oege de Moor, and a detailed technical write-up by researcher Brendan Dolan-Gavitt. Together they describe an exploit chain that takes an attacker from JavaScript running in an ordinary Chrome tab to arbitrary code execution on the underlying Windows host, crossing both of Chrome’s sandbox layers. The victim only needs to load a malicious page.

The chain that Google eventually accepted was assembled between Sunday 2 August and Friday 7 August, during the Black Hat and DEF CON week in Las Vegas. XBOW says it deliberately chose a general-purpose model anyone can buy, and estimates from its logs that the API bill for those six days came to about $40,000. Google confirmed the bugs, fixed them and paid a $250,000 full-chain reward. XBOW says none of the flaws was used against real users.

The context matters. According to Dolan-Gavitt, a Chrome full chain would once have occupied a team of four for six to nine months. XBOW’s first attempt this year took about two months.

The technical picture

The chain had three stages, each in a separate part of the browser:

  • V8 compiler bug. A flaw in Maglev, V8’s mid-tier optimising compiler, meant that during deoptimisation separate JavaScript objects could end up sharing one mutable number box that the compiler treated as a constant. That disagreement let the exploit defeat a bounds check and gain read and write access across V8’s 4 GiB pointer-compression cage. The Hacker News reports this as CVE-2026-85045, fixed in Chrome 152.0.7977.82 on 3 September.
  • Animated WebP decoder bug. By quietly keeping a live view onto a buffer that Blink believed it owned exclusively, the exploit swapped one valid animated WebP for another mid-decode. The decoder used geometry cached from the first image with pixel data from the second, overflowing a heap allocation. Carefully arranged, this produced a single chosen write to native memory outside the V8 sandbox. No public CVE identifier for this stage has been confirmed.
  • Crashpad bug. Chrome’s crash handler runs outside the renderer sandbox. A memory-safety flaw in how it read from a supposedly suspended renderer gave the final step: code running in an unsandboxed process. Google’s release notes for Chrome 152, published on 25 August, list this as CVE-2026-78952, an out-of-bounds write in Crashpad credited to Dolan-Gavitt of XBOW.

The division of labour is the interesting part from a security point of view. XBOW split the work into parallel agent campaigns, each with a narrow goal, from general bug hunting through engine corruption and both sandbox escapes to final integration. The agents searched Chromium source, tested hypotheses, wrote proofs of concept and drafted exploit stages. The humans picked targets, supplied context, challenged results and decided which components to bolt together. Crucially, they insisted each stage had a clean interface so that any one part could be replaced without rebuilding the rest.

Flow diagram of XBOW's Chrome exploit chain: malicious page, V8 Maglev bug, WebP decoder sandbox escape, Crashpad bug, then patch and relaunch

Why it matters for UK organisations

This is not a story about a new threat to Chrome users today. The bugs are fixed and there is no evidence of abuse. It is a story about economics. A complete, sandbox-escaping browser chain has historically been the preserve of well-funded state teams and elite commercial exploit vendors. XBOW has shown that a handful of skilled researchers with a public model and a budget comparable to a mid-range penetration test can produce one inside a working week. De Moor’s own view is that within a year agents could plausibly find each of these three bugs without human direction.

The NCSC has been signalling this for months. In its May 2026 warning about an approaching “patch wave”, the centre said AI in skilled hands was able to exploit accumulated technical debt at scale and pace, and urged organisations of every size to prepare for a surge of urgent updates. XBOW’s work, confirmed and paid for by Google, is a concrete example of that shift in a product almost every UK business runs.

The implication is that turning a published patch into a working exploit will also get faster and cheaper. Browsers that download an update but never restart, unmanaged Chromium browsers on contractor laptops and embedded web views in desktop applications all lengthen the time a fixed bug stays exploitable on your estate.

Expert view

In my experience, most organisations measure patching by when an update was released to devices, not by when it was actually running. Chrome is a good illustration. It downloads fixes promptly, but the protection only applies once the browser is relaunched, and I routinely see users with dozens of tabs open for weeks.

I would also caution against reading this as “AI hacks Chrome on its own”. XBOW is explicit that experienced researchers directed the work, and the team’s decision to design swappable stages was a human one. What has changed is the cost of the labour in between. The scarce skill is now judgement, not hours, and well-resourced attackers have plenty of judgement. Organisations that relied on the effort barrier to keep advanced exploitation rare should plan as if that barrier has fallen.

Defenders can use the same tools. For UK software houses and in-house development teams, AI-assisted code review and fuzzing now belong in the secure development lifecycle.

What to do now

  1. Confirm the running Chrome version. Check that managed devices are on Chrome 152.0.7977.82 or later and, more importantly, that the browser has been restarted. Use enterprise policy to enforce relaunch after a set period. This maps directly to the Cyber Essentials security update management control, which expects high and critical fixes within 14 days.
  2. Find every Chromium engine. Inventory Edge, Brave and other Chromium-based browsers, plus Electron apps and embedded web views, and track how quickly each inherits upstream fixes.
  3. Shorten browser patch targets. Treat browsers like internet-facing services. Aim for days, not weeks, and report on time-to-relaunch rather than time-to-download.
  4. Reduce what a browser compromise yields. Remove local admin rights, use application control, and keep privileged administration off everyday browsing machines, as the NCSC recommends with privileged access workstations.
  5. Prepare for the patch wave. Revisit your vulnerability management process against the NCSC guidance, enable automatic updates wherever safe, and prioritise exposed and security-critical systems.

Bottom line

XBOW has turned a long-standing prediction into a demonstrated fact: a public AI model, guided by skilled people, can compress months of elite exploit development into six days. The fix for these particular bugs is already out. The fix for the underlying problem is organisational: shrink the gap between an update existing and an update running, because that gap is now where the risk lives.

Sources

Related Posts