Chrome: a $250,000 exploit chain built with AI in six days

A team of researchers at XBOW, a US company that does AI-driven penetration testing, has built a full exploit chain against Google Chrome on Windows: from a malicious web page all the way to code execution on the computer, outside every browser sandbox. They did it in six days, with about $40,000 in compute costs and with GPT-5.6 Sol, a publicly available OpenAI model. Google fixed all three vulnerabilities and paid a $250,000 bounty.

In early October ARX News covered the pause of Google’s OSS VRP, swamped by invalid automated reports. This case shows the other side of the same trend: AI, steered by experienced people, also delivers top-tier results.

What happened

The sources agree on the core facts: three Chrome zero-days, a public OpenAI model, six days of work, $40,000 in costs, a $250,000 bounty. According to The Register, the work was done during the Black Hat and DEF CON conferences and the bounty is Google’s top reward for a Chrome full chain; CSO Online adds that it is the first one paid under the programme’s 2026 rules. XBOW estimates that the chain could have affected about one billion Windows users.

According to CSO Online, the researchers picked a general-purpose model rather than a specialised tool precisely to show what a public model can achieve. The Register reports the split of work described by Brendan Dolan-Gavitt, one of the four researchers, in XBOW’s technical write-up:

• the AI agents searched Chrome’s source code, tested the team’s hypotheses and developed the proofs of concept and the individual exploit stages;
• the people chose where to look, provided context, challenged the agents’ results and decided which components to chain. “We did apply a fair bit of our own human expertise and judgment,” Dolan-Gavitt wrote.

The attack chain

Chrome isolates code on two levels: the V8 sandbox keeps the effects of JavaScript engine memory bugs inside the renderer process, and the operating system sandbox in turn restricts the renderer. Escaping the first does not automatically give native code execution; escaping the second means reaching the system. According to the write-up as reported by The Register, the chain crosses both barriers in three steps:

1. Maglev, V8’s mid-tier optimising compiler: a mutable boxed number reused during deoptimisation gives read and write access across V8’s pointer-compression cage;
2. animated WebP decoding: a bug used to escape the V8 sandbox, not by attacking the sandbox itself but a property that the sandbox deliberately does not enforce and that Blink, the rendering engine, wrongly assumed it could trust;
3. Crashpad, the component that collects crash data: an overflow used to cross the process sandbox and run unrestricted code on the system.

CSO Online describes the end result as launching a Windows application from a malicious web page. The sources do not give CVE numbers for the three vulnerabilities and do not mention real-world exploitation: this is research reported to Google.

In MITRE ATT&CK terms, such a chain used in an attack would map to compromise while browsing (T1189, Drive-by Compromise) followed by client-side code execution through the browser (T1203).

What changes for defenders

The point is not this chain, which is already fixed, but the time and cost. XBOW’s CEO, Oege de Moor, says a former intelligence agency member told him similar work used to take six months; here six days were enough. Dolan-Gavitt concludes that for attackers using large language models “the bar is significantly lower” and urges defenders to act accordingly.

For European and Italian companies this means a narrower window between the release of a fix and the appearance of working exploits. The browser is the most exposed software on every workstation, including in healthcare facilities and shared environments. For NIS2 entities, update management is part of the required risk-management measures: if browser patching is measured in weeks, it needs to be reviewed.

What to do now

1. Check the Chrome version: according to The Register you need 152.0.7977.82 or later. Check the inventory of every Windows workstation, not only the centrally managed ones.
2. Enforce a browser relaunch: Chrome updates itself, but the fix only takes effect once the browser is restarted. Use management policies to prompt for and then force a relaunch within a set time.
3. Check other Chromium-based browsers: the sources do not say whether or when other vendors have integrated the fixes. Follow their advisories.
4. Do not disable the sandbox (for example with --no-sandbox in kiosks, automation or embedded applications): it is exactly the barrier that forces attackers to build a chain.
5. Monitor processes started by the browser: an application launched unusually by a Chrome process is a signal to investigate with your antivirus/EDR solution.
6. Shorten browser patch times and treat them like operating system patches: with AI, the time between fix and exploit can shrink.

How ARXDOME helps

ARX Shield shows open vulnerabilities by machine and by package, with their age and the ones already exploited highlighted: it helps find workstations with an outdated browser. ARX Sentry collects the software and process inventory of computers and servers and flags suspicious executions, useful for spotting unusual processes started by the browser.

Last updated: 16 October 2026