XBOW Broke Chrome in Six Days With a Public AI Model

 

By TechPulse USA

It took six days, about $40,000 in AI compute, and a web page nobody had to click anything on. That is the whole scandal, and the whole story: a small security team working with a publicly available AI model built a complete attack chain for Google Chrome, the browser guarding roughly a billion Windows desktops, and Google paid them $250,000 for the privilege of being shown how.

This was not a hack in the Hollywood sense. Nobody broke into a server room or guessed a password. The team at XBOW, an autonomous offensive-security company, chained three separate, previously unknown Chrome bugs together so that simply loading a malicious web page could run code outside the browser's sandbox on a Windows machine. Google has since confirmed all three bugs, fixed them, and paid the bounty. Nothing here is still live for an attacker to copy. What is still live is the question the six days ask of everyone else: if this now costs $40,000 and a week, what exactly is your security budget buying?

The disclosure landed on October 13, 2026, in two XBOW posts: a company announcement and a long technical write-up by researcher Brendan Dolan-Gavitt titled "Zero to Calc in Six Days." The name is a joke with a sharp edge. In exploit research, popping open the Windows Calculator from a browser is the traditional proof that you can run any program you like. XBOW's proof-of-concept did exactly that, from a signed Chrome Beta build, with a web page doing all the work.

Photo: Google Chrome running on Windows 11. This is an illustrative screenshot from 2022, not the exploit or XBOW's demonstration. Credit: Megamanfan3, via Wikimedia Commons.

A visit that was enough

To understand why this matters, forget the image of a hacker hammering at a login screen. Chrome is built like a set of nested rooms. A web page runs in the innermost room, the renderer, and even if something goes wrong there, two sandboxes stand between the page and the rest of your computer. The first is the V8 sandbox, which walls off the JavaScript engine's memory. The second is the operating-system process sandbox, which walls off the renderer itself.

A "full chain" is what happens when someone picks every lock in sequence. One bug alone might let an attacker meddle with memory inside the JavaScript engine. That is bad, but it is not a takeover. Two more bugs, each crossing one more boundary, turn it into one. XBOW's chain did precisely that: a bug in V8's compiler, a bug in the animated WebP image decoder, and a bug in Crashpad, Chrome's crash handler. At the end of the chain, code was running outside the sandbox on Windows, with no download and no click required.

XBOW is blunt about what that access would have meant in hostile hands: installing malware, ransomware or spyware, stealing credentials or files, or gaining a foothold to move across a network. Before the fixes, the company estimates, the flaws sat in the path of about one billion people running Chrome on Windows. That billion is XBOW's estimate, not Google's, and it deserves to be read that way. It is a measure of exposure, not a count of victims. XBOW says the bugs were never used against real Chrome users, and there is no evidence to the contrary.

Three locks, picked in order

The six-day sprint ran from Sunday, August 2 to Friday, August 7, 2026, right in the middle of the Black Hat and DEF CON conferences in Las Vegas. There is something almost comically on-the-nose about that: while thousands of security professionals were gathered in one city talking about defence, a researcher and a set of AI agents were quietly taking apart the world's most popular browser a few hotels away.

But the sprint was not the whole project, and any telling that pretends otherwise is selling you a shorter story than the truth. XBOW set itself this challenge at a staff meeting in Malta back in January 2026. Its first full Chrome chain took about two months to build, and it died when Google said it already knew about one of the bugs. The six days in Las Vegas were the second attempt, built on months of groundwork, reusable techniques, and a team that already knew what failure felt like. That context does not make the result less impressive. It makes it more believable, and therefore more worrying.

One identifier needs a footnote, not a headline. XBOW's announcement labels the animated-WebP stage of the chain CVE-2026-85045, while Google's release notes and The Hacker News assign that number to the V8 bug. The Crashpad bug is consistently tracked as CVE-2026-78952. We are not going to pretend the paperwork is tidier than it is: the chain itself is not in doubt, but readers chasing CVE numbers should know the two sources disagree about which stage owns one of them. The WebP bug, meanwhile, has no publicly confirmed identifier of its own in the coverage we checked.

The first lock: a number that refused to stay still

Stage one lived in Maglev, the mid-tier optimising compiler inside V8, Chrome's JavaScript engine. When optimised code has to fall back to slower code, V8 reconstructs ordinary JavaScript objects on the fly, a process called deoptimisation. The vulnerable path created a single old-space HeapNumber, a boxed number object, for a virtual value, and then treated that object as a literal, something the compiler was allowed to reuse.

The problem is that this particular number was mutable. Other parts of the compiler assumed HeapNumbers created this way were immutable constants. So distinct JavaScript objects could end up sharing one mutable number, and changing one object's field changed the value the optimised code used, without invalidating the earlier safety reasoning. XBOW's write-up calls it, with admirable understatement, a disagreement between two observations of the nominally same constant.

The exploit turned that disagreement against Array.prototype.at(). One compiler observation approved an in-bounds access; another observation supplied the actual load offset. From there, three optimised load functions were enough to disclose nearby V8 pointers, forge a fake array, and rewrite the metadata of a real Uint8Array, stretching ordinary indexed access across V8's entire 4 GiB pointer-compression cage. At that point the attacker had reliable read and write access to memory from JavaScript, but still inside the V8 sandbox. The first lock was picked. Two remained.

The second lock: two pictures walk into one frame

Stage two is the cleverest part of the chain, and the strangest. Rather than attacking the V8 sandbox head-on, XBOW's team went looking for something the sandbox deliberately allows but that downstream code wrongly trusts. They found it in the way Chrome handles animated WebP images.

The trick starts with a transferred ArrayBuffer, the chunk of memory JavaScript hands to the ImageDecoder. Under ordinary JavaScript semantics, transferring a buffer detaches the old views of it, and Blink, Chrome's rendering engine, can then treat the bytes as its exclusive input. But the V8 sandbox's threat model says something different: once an attacker controls memory inside the cage, detached does not mean untouchable. Using the stage-one write, the exploit quietly removed a live Uint8Array view from its buffer's detach-notification chain, so the view survived the transfer. Blink believed it owned the bytes exclusively. The attacker could still change them.

Then came the swap itself. The proof of concept placed two same-length, independently valid animated WebP files in the same backing store. The decoder cached the first file's frame geometry, a 64-by-64 canvas with a frame starting at x = 16. The surviving view then replaced the bytes with the second file, whose payload decoded a full 64-by-64 frame. The decoder read the second file's pixels but described the output buffer using the first file's cached rectangle. Both pictures were valid on their own. The unsafe state existed only because Chrome combined one file's measurements with another file's bytes, a classic time-of-check versus time-of-use flaw, and the write spilled just past the end of the pixel allocation.

In the production exploit, the geometry was tuned far more precisely: a two-pixel frame starting at x = 124 on a 126-pixel canvas, arranged so the overflowing pixel write replaced a live decoder's native fields with pointers to records the attackers had staged. When decoding finished, a genuine Chrome routine copied one chosen 64-bit value to one chosen native address. That single write was the entire bridge out of the V8 sandbox. From there, a neat piece of island-hopping, thirteen fragments of loader code stitched together through WebAssembly calls, built a small program inside the renderer and set up stage three.

The third lock: the crash handler that would not stay frozen

Stage three is where the chain stops being a browser trick and becomes a machine takeover. Crashpad is the helper that takes a snapshot of Chrome when it crashes, and it runs outside the renderer sandbox, which is exactly why it is such a prize. When Crashpad receives a snapshot request, it suspends the renderer and reads its memory, on the assumption that a suspended process cannot change.

That assumption had a hole in it, and XBOW drove a thread through it. Windows allows a thread created with a special flag to keep running even when its process is suspended. The exploit created exactly such a thread before requesting a snapshot, then used it to flip the attacked memory pages between inaccessible and readable while Crashpad was doing its work. Crashpad's retry logic for a failed read assumed the failure told it something about the geometry of the memory it was reading. With the page protections changing underneath it, that inference was wrong, and the retry copied more data than the destination buffer could hold, overflowing into a neighbouring live object.

From there, the payload rewired a live Crashpad writer object so that, when Crashpad later flushed its snapshot, it followed a chain of substituted function pointers into Chrome's own fallback crash handler, which launched a program with the command "cmd /k calc.exe". Calculator opened. The demonstration was complete: JavaScript in an ordinary tab had become code execution outside the renderer sandbox, on the host machine.

Google's fix, described in XBOW's write-up, is a small clamp with a large moral: the retry is now limited by both the source page boundary and the caller's original request, so even if the source changes between the failed read and the retry, Crashpad can no longer write beyond the destination. The vulnerable assumption is gone, not just the vulnerable line.

The humans in the loop, and the swap that saved the chain

So who actually did this, the model or the people? XBOW's own account is unusually honest about the split, and it refuses the easy headline in both directions. The AI agents, running OpenAI's publicly available GPT-5.6 Sol model, searched Chrome's source code, tested the team's hypotheses, built proofs of concept, and wrote first drafts of the exploit stages. The researchers chose the targets, supplied context, challenged the agents' results, redirected searches, and decided which components to join together.

"We did apply a fair bit of our own human expertise and judgment," Dolan-Gavitt wrote in the technical post, as The Register quoted him. That sentence deserves to be read twice, because it punctures two fantasies at once: the fantasy that a chatbot broke Chrome by itself, and the fantasy that the humans were merely supervising. The work was split into parallel campaigns with narrow goals, broad vulnerability search, V8 memory corruption, a V8 sandbox escape, a renderer sandbox escape, and integration, and each stage was given a clean interface so it could be swapped without rebuilding the rest.

That modular design saved the whole project. The first version of the awarded chain used a different vulnerability for its V8 sandbox escape, and Google told XBOW it already knew about that bug. In the older telling of this story, that would have been the end. Instead, after what the write-up calls a very stressful few hours, the team replaced the middle stage with the animated WebP bug, and Google confirmed the rescued chain popped Calculator. The broader project team named by The Register was Dolan-Gavitt, Andres Luksenberg, Baul Lee and Willem Pinckaers, working with the agents; the awarded six-day chain itself was built by Dolan-Gavitt with the agents, according to XBOW's announcement.

The economics are the part that should make every security budget-holder sit up. XBOW reconstructed the six-day campaign's API charges from its archived Codex logs at roughly $40,000. Google paid $250,000, the first full-chain Chrome reward under the reward-program rules introduced in April 2026, and the first such award to an autonomous security platform, according to XBOW. "It only took an estimated $40,000 of compute and six days for a single researcher to produce a chain that previously would have taken months," said Oege de Moor, founder and CEO of XBOW, in the company's announcement. "Attackers are working with this speed and ease, and defenders need a similar pace to find the exploitable paths among their many findings."

Dolan-Gavitt put the before-and-after more starkly in the technical post: "Pre-LLMs a Chrome full chain would take a team of four around 6-9 months to be produced, our first submission took 2 months. The awarded one? six days." And his closing warning is worth quoting in full, because it is the whole story in two sentences: "Six days and $40k is not a lot of time or money when the payoff is a Chrome chain! Now, this does not mean that anyone can get a Chrome chain given that amount of time and money (as discussed, we did apply a fair bit of our own human expertise and judgment), but it does mean that the bar is significantly lower. Defend accordingly."

OpenAI, for its part, framed the result as a win for defence. "We want to help more defenders find and fix critical vulnerabilities faster," said Clint Gibler, Head of Cyber Research at OpenAI, in XBOW's announcement. "A single XBOW researcher used our models to uncover a chain of vulnerabilities that Google has now fixed." That is true, and it is also, obviously, in OpenAI's interest to say. The model in question is publicly available, which cuts both ways: defenders can rent the same capability, and so can everyone else.

What this actually changes, and what to do about Chrome

Here is the reporter-judgment part, stated plainly. The colossally uncomfortable truth of this story is not that AI can find browser bugs. It is that the gap between finding a bug and fixing one is now the whole game, and it is widening in the wrong direction. Discovery just got roughly fifty times faster, by XBOW's own before-and-after arithmetic, while patching still depends on the same slow machinery: a vendor shipping a fix, an update rolling out, and a user actually restarting their browser. Anyone who thinks this story is about a clever model has missed it. It is about a timetable. Attackers now work in days; the rest of the industry still largely works in quarters.

That is also why the usual dismissals fail. It is true that the six days rested on months of prior work, four elite researchers, and a first chain that failed. It is true that the billion-user figure is XBOW's estimate, not a census. None of that rescues the old comfort, because none of it changes the direction of travel. The first chain took two months. The second took six days. The trend line does not care about your caveats.

There are also honest limits to what this chain proves. It was demonstrated on Windows, against specific Chrome builds, and it needed the whole chain to work; break any one link and the attack falls apart. XBOW itself notes that bug collisions are now a major risk, since everyone, including Google, is pointing models at the same codebases. And the flood of AI-generated vulnerability reports is already straining the system on the other side: Google has had to recalibrate bounties and close programs to low-quality submissions. Faster discovery without faster triage just moves the bottleneck, it does not remove it.

For readers, the practical part is short. All three bugs are fixed. The Crashpad bug, CVE-2026-78952, was fixed in Chrome 152.0.7977.65 on August 25, and the V8 fix landed in 152.0.7977.82 on September 3, according to The Hacker News' account of Google's release notes. We checked those version numbers against the release-note coverage before writing this article, and the advice is the same whichever build you are on: relaunch Chrome and confirm you are on 152.0.7977.82 or later, because Chrome only applies an update after a restart. If you have left the browser open for weeks, the patch may be downloaded and waiting, doing nothing.

For the industry, the homework is longer. XBOW says it will use the award money to fund work securing NGOs with its technology, which is a decent use of a bounty, but the larger lesson is structural. Vendors need to assume that motivated attackers can now afford to hunt their most hardened software, and that the hunt takes days, not seasons. That means finding bugs first, not just patching them faster, and it means treating every "immutable" assumption in a codebase, a number, a transferred buffer, a frozen process, as a suspect. In this chain, all three bugs were, at bottom, the same mistake in three costumes: something everyone believed could not change, changing. The models did not invent that pattern. They just got very good at spotting it, very fast.

The browser you are reading this in is, in all likelihood, already fixed. The world that produced the exploit is not going back to six months and a team of four. It is not going back at all.

Related reading on TechPulse USA: how METR's red team broke OpenAI's agent monitor shows the same pressure from the other side of the lab, while ChatGPT's move into Chrome explains why the browser itself has become the most valuable real estate in AI. And if you want a reminder of what happens when AI agents are pointed at softer targets, the CyberCartel bank heist is the cautionary tale.

Sources: XBOW Labs, "Zero to Calc in Six Days: Inside XBOW's Chrome Full Chain" (October 13, 2026); XBOW announcement via Business Wire (October 13, 2026); The Hacker News (October 14, 2026); The Register (October 14, 2026). The billion-user figure, the $40,000 compute estimate and the six-day timeline are XBOW's own figures, as reported by those outlets.

TechPulse USA covers the technology shaping America and the world, from AI breakthroughs to the security flaws they expose. Got a tip or a correction? Tell us and we will update this article.

Daniel Rao covers AI, autonomous agents and the business of technology for TechPulse USA.