Short

XBOW used GPT-5.6 Sol to build a Chrome full chain exploit in six days

XBOW used OpenAI's public GPT-5.6 Sol model to chain three Chrome bugs into a full exploit in six days for about 40,000 dollars. Google paid a 250,000 dollar bounty.

For years, a working full chain exploit against Google Chrome was one of the rarest and most expensive things in computer security. It took elite teams many months, and the finished product was worth a fortune to governments and spyware vendors. On Tuesday, October 13, 2026, the security startup XBOW showed how much that has changed. Its researchers used OpenAI's publicly available GPT-5.6 Sol model to help build a complete Chrome exploit chain for Windows in just six days, for roughly $40,000 in AI compute. Google paid them a $250,000 bug bounty for it.

The bugs are already fixed, and nobody has reported attacks against real users. But the story is not really about one exploit. It is about how fast the cost of serious hacking is falling now that AI agents can do much of the digging, and what that means for everybody who uses a browser.

Here is what XBOW built, how humans and AI split the work, what the numbers really say and what you should do today.

Editorial illustration of a browser shaped like a vault with three glass walls and three red cracks, while a robot and a researcher in a red hoodie work together on a laptop next to a calendar

The three things you need to know

  • The hack. XBOW chained three separate Chrome vulnerabilities into one attack. Starting from JavaScript on an ordinary web page, the chain ended with code running outside Chrome's sandbox on a Windows computer. XBOW estimates that about one billion Chrome users on Windows were exposed before the fixes shipped.
  • The speed. AI agents running OpenAI's GPT-5.6 Sol searched Chrome's source code, tested ideas, built proofs of concept and wrote early versions of the exploit stages. XBOW's researchers chose targets, checked the results and decided which pieces to join. The awarded chain was built between August 2 and August 7, 2026. According to XBOW, a chain like this took a team of four around six to nine months before large language models.
  • The price. Reconstructed from the agents' logs, the six day campaign cost about $40,000 in API charges. Google paid $250,000, the first award at that level for a Chrome full chain under the reward rules it introduced in April 2026. All three bugs are patched.

What a full chain exploit is

Chrome is not protected by a single wall. It is built in layers, and each layer assumes the one in front of it might fail. JavaScript runs inside the V8 engine, and V8 keeps most of its data inside its own memory cage, often called the V8 sandbox. Even if an attacker corrupts memory there, they are still locked inside. Around that sits the renderer process, which itself runs inside an operating system sandbox with very limited rights. An attacker who takes over the renderer still cannot simply read your files or install software.

That is why one bug in Chrome is usually not enough to take over a computer. A single flaw might let a malicious page misbehave inside one layer, but the doors to the rest of the machine stay locked. A full chain is a set of bugs that, used together, opens every door: from a web page, through the JavaScript engine, out of the renderer and onto the operating system itself. In XBOW's demonstration video, a web page in a signed Chrome Beta build launches the Windows Calculator, the traditional proof that an attacker could have run any program they wanted.

How the three stages worked

XBOW published two posts on October 13. A company blog post by founder and CEO Oege de Moor explains the project, and a technical write-up by researcher Brendan Dolan-Gavitt explains the bugs. In short, the chain had three stages.

Stage one: the JavaScript engine. The first bug was in Maglev, the mid-tier optimizing compiler inside V8. When optimized code has to fall back to slower code, V8 rebuilds JavaScript objects on the fly. In the vulnerable version, Maglev could reuse one mutable number box for several objects, even though the compiler treated it as an unchangeable constant. The exploit used that disagreement to trick an array bounds check and ended up with read and write access to the whole V8 memory cage.

Stage two: escaping the V8 sandbox. The second bug sat in Chrome's decoder for animated WebP images. The exploit placed two different, individually valid WebP files in the same memory buffer. Chrome checked the dimensions of the first image, but then decoded the pixels of the second one using the cached measurements of the first. That mismatch produced a heap overflow, which the researchers shaped into one chosen write outside the V8 cage. One write was enough to redirect a WebAssembly call and start running native code inside the renderer.

Stage three: escaping the renderer. The last bug was in Crashpad, the crash reporting helper that runs beside Chrome on Windows and, crucially, outside the sandbox. When Crashpad takes a snapshot of a renderer, it pauses that process and reads its memory. The exploit used a special kind of Windows thread that keeps running even when a process is frozen, flipped memory page permissions at exactly the wrong moment and made Crashpad copy more data than its buffer could hold. That overflow gave the attacker code execution in the unsandboxed crash handler. This bug is tracked as CVE-2026-78952, rated High, and Google fixed it in Chrome 152.0.7977.65 on August 25.

Dolan-Gavitt pointed out an interesting pattern. All three bugs were about something changing that the code assumed could never change: a number that was supposed to be constant, an image buffer that was supposed to be locked and the memory of a process that was supposed to be frozen. He suspects that this kind of broken assumption is exactly where language models shine, because they know a huge amount about operating system interfaces and open source code and can imagine the odd situations where an invariant fails.

Who did what: humans and AI

It would be wrong to read this as "an AI hacked Chrome by itself". XBOW is clear that this was a partnership. The project started as a challenge at a company all hands meeting in Malta at the start of 2026: build on XBOW's earlier work on AI security researchers for web applications and take on the hardest target the team could think of, a full Chrome chain, before the Black Hat conference in August.

Four researchers, Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee and Willem Pinckaers, took it on, with what de Moor calls a fifth colleague: GPT-5.6 Sol and its predecessors. XBOW says it deliberately chose a model that anybody can use, not a special security model with restricted access.

The work was split into parallel campaigns with narrow goals: a broad search for vulnerabilities, V8 memory corruption, a V8 sandbox escape, a renderer sandbox escape and finally integration. The agents searched the source code, tested hypotheses, built proofs of concept and developed exploit stages. The humans set the strategy, chose where to look, supplied context, challenged the agents' results and redirected them when they went down the wrong path.

One human decision turned out to be essential. The team built the exploit as three independent modules, each with a backup. That paid off. Their first version of the chain used a different V8 sandbox escape, and Google told them it already knew about that bug. Because the stages had clean interfaces, the team swapped in the animated WebP stage within a few stressful hours instead of starting over. An even earlier chain had died the same way, colliding with a bug that Google had found internally months before.

Bar chart comparing the time to build a Chrome full chain: 180 to 270 days before large language models, about 60 days for XBOW's first submission and 6 days for the awarded chain built with GPT 5.6 Sol

The numbers, in context

The most striking numbers are about time and money. In his technical post, Dolan-Gavitt writes that before large language models, a Chrome full chain would take a team of four around six to nine months. XBOW's first submission took two months. The awarded chain took six days, from Sunday, August 2, to Friday, August 7, built while the team was in Las Vegas for Black Hat and DEF CON. De Moor adds that a veteran of a three letter intelligence agency told him his team used to spend about six months on this kind of work.

The compute bill was about $40,000 in API charges for the six days, according to XBOW's reconstruction from its archived Codex logs. Google's reward was $250,000, which XBOW and press reports describe as the first full chain award of that size under the Chrome Vulnerability Reward Program rules introduced in April 2026. Forbes and The Register both covered the story, and The Register advises Chrome users to run version 152.0.7977.82 or later.

Two caveats matter. First, the $40,000 covers the awarded six day campaign, not all the months of earlier work, failed chains and expertise that made it possible. Second, XBOW is a company that sells AI security testing, so it has an interest in showing how powerful its approach is. Dolan-Gavitt himself warns that this does not mean anyone with $40,000 can produce a Chrome chain, because the team applied a lot of human expertise and judgment. His conclusion is more modest and more worrying: the bar is significantly lower than it used to be.

Why it matters

Exploit chains for major browsers have always been expensive, and that cost has been part of what kept most people safe. If a chain costs months of elite work, it gets used sparingly, against a few high value targets, and then it is burned once someone notices. If the same result can be reached in days with a public model and a small team, the economics shift for criminals and spyware vendors too, not only for bug bounty hunters.

There is another side, and XBOW stresses it. The tools that found these bugs are equally available to defenders, and defenders have an advantage attackers never have: they can test their own code first. Google itself is pointing large language models at Chrome, which is exactly why XBOW kept colliding with bugs Google already knew about. The race is now about who finds the flaws first, and AI is making both sides much faster.

The project also feeds a live policy debate. Many people argue that the most capable models should be locked down because they can help with cyber attacks. XBOW's answer is that the model it used is already public, so restricting access is "the wrong question". De Moor believes that within a year each of the three bugs could be found by agents working on their own, and the company is now building an autonomous product for testing compiled software such as desktop apps, servers and embedded devices.

Editorial illustration of a person in a red hoodie restarting a browser update next to a shield, with a scale in the background balancing a small stack of coins against a much larger stack

What you should do now

The practical advice is boring but important. All three bugs are fixed, and Chrome installs updates automatically. However, a fix only takes effect after the browser restarts. If Chrome shows an Update or Relaunch button, use it, and do not leave the same browser window open for weeks. You can check your version under Settings, About Chrome.

For companies, XBOW's advice goes further: assume your own applications are exploitable, test them before somebody else does and plan for the attacks that will still get through. When the cost of finding bugs falls for both sides, the only sensible response is to find more of your own, sooner.

Dany's take

I find this story impressive and a little scary at the same time. Six days and $40,000 for something that used to take half a year is a huge jump, and it was done with a model anyone can rent. At the same time, I like that this ended the right way: the bugs went to Google through the official bounty program, they were fixed before the details came out and the write-up is public, so other defenders can learn from it. My personal takeaway is simple. Restart your browser when it asks, keep auto updates on and expect many more stories like this one in the next months, from both the good side and the bad side.

What to watch next

  • XBOW's talk on the chronology and orchestration of the campaign at the Unprompted conference at the end of October, and Andres Luksenberg's talk on the first, collided chain at OffensiveCon Tokyo.
  • Whether other teams claim full chain rewards for Chrome, Safari or Firefox with publicly available models.
  • Whether Google changes its reward rules again as AI assisted submissions grow and collisions become more common.
  • Whether XBOW's prediction comes true that agents will find bugs like these on their own within a year.

Sources: XBOW: XBOW Built a Chrome Full-Chain Exploit Affecting a Billion Users in Six Days, XBOW Labs: Zero to Calc in Six Days, Inside XBOW's Chrome Full Chain, XBOW Labs advisory CVE-2026-78952, Forbes: An OpenAI Model Found Three Previously Unknown Security Flaws In Google Chrome, The Register: Security researchers spent 6 days doing their Chromework, built 1B user exploit.

Source: xbow.com

Newsletter

The AI news that matters, in your inbox.