// FIELD NOTES · THRESHOLD 2/5 · all entries

The Receipt

XBOW's bounty was already public. Today they explained how they built it, and the technical account is far more interesting than the award announcement.

2026-10-20· 8 min read· [analysis]

Last week, we wrote about large models already directing smaller agents. There was something circular about Anthropic's self-replication paper: the only worm that worked depended on a frontier model operating from outside the device.

XBOW's bounty was already public. They had received $250,000 for the first full Chrome exploit chain rewarded under April's VRP rules. Today they explained how they built it, and the technical account is far more interesting than the award announcement.

They chained three vulnerabilities: one in Maglev, V8's compiler, another to escape the V8 sandbox, and a third to escape the renderer sandbox. They started with JavaScript in a browser tab and ended up executing code outside both sandboxes. Anyone who remembers suspicious email attachments from twenty years ago will recognize the demo: a calculator opens where it shouldn't.

Google reproduced the entire chain through its own adjudication process. Issues were filed, fixes were written, and the crash was verified in Google's environment before payment. That validation gives the result weight beyond what the agent or the team says about its work.

The campaign took six days and roughly $40,000 in API spend. Before LLMs, the same team estimated that a chain like this would have taken four people six to nine months.

The chain

The first bug was in Maglev, V8's mid-tier compiler. During deoptimization and object reconstruction, it treated a mutable, heap-allocated number as an immutable literal. That allowed two observations by the compiler to disagree about the same value. XBOW used that disagreement to subvert the bounds check in Array.prototype.at() and gain read and write access throughout V8's 4 GiB cage.

To get out of the cage, they looked at the assumptions Blink made about the data it received. When a buffer is transferred to the rendering engine, Blink assumes nobody else can still modify it. XBOW kept a view alive past the transfer and used it to write to the buffer behind Blink's back, even after the decoder had validated the frame geometry.

The WebP decoder could then end up using the geometry of one frame with the pixels of another. The resulting overflow gave them a native 64-bit write, with a chosen value, outside the cage. That was enough to keep going.

The third vulnerability was in Crashpad, Chromium's crash reporting system. It's my favorite of the three. When a memory read returned a partial-copy error, the fallback retried through the end of the page without respecting the requested size. That behavior rested on an assumption: the process was suspended, so its memory couldn't change during the read.

The exploit created a thread with a flag that allowed it to bypass the process freeze. From that thread, it alternated the page protections between the first read attempt and the retry. They got a 168-byte overwrite in a live object and, through vtables and callbacks, reached the crash handler's launcher. There, they executed cmd /k calc.exe.

At each stage, they could change something another component treated as immutable. Maglev relied on a value remaining constant; Blink relied on exclusive access to a buffer. Crashpad assumed a suspended process's memory would stay still. None of those conditions was enforced the way the code needed it to be.

Chrome is one of the most heavily audited pieces of software in the world, and those assumptions still survived review. That interests me because it points to something specific LLMs are proving useful at: finding the gap between what code assumes and what can actually happen. It's a way of looking at your own code that will remain useful long after this story stops making the rounds.

How they worked

XBOW's account of the process helps explain what "autonomous" means here. They split the work into parallel campaigns with narrow objectives: vulnerability discovery, V8 memory corruption, a V8 sandbox escape, a renderer escape, and chain integration. They defined interfaces between stages and prepared alternative routes.

That structure helped when their first V8 sandbox escape, based on Gin, turned out to be a duplicate of an internal Google issue. The chain they had already completed was no longer eligible for the bounty. In a conventional project, a collision like that can cost a month's work. They were able to replace that stage with the WebP escape and carry on with the rest.

The four researchers were involved throughout the campaign. They chose targets, supplied context, challenged the agent's results, redirected searches, and decided which pieces to connect. XBOW says this in the post itself, and it's worth keeping in mind when reading the headline.

When I see "six days," I think about how much the cost of the mechanical work has fallen. Understanding the target, choosing an entry point, and deciding which results to trust still depended on people. They were able to save months of fuzzing and reading through code line by line. The team still has to know what it's looking at.

A $40,000 API bill is still substantial, even if it's an order of magnitude below the cost of assigning four specialists to that chain for six to nine months.

Where the advantage lies

One detail in the loader shows how human expertise fits into this. To get from a single write to executable code, they used island hopping: thirteen islands in Liftoff immediates. XBOW's native security team had already developed the technique. The agent could work with that material because someone had already solved that part of the problem. The quality of the human examples still has a lot to do with what these systems can achieve.

The collision with Google's issue deserves attention, too. If several teams point the same frontier models at the same open-source code, they're going to run into each other more often. Completing a chain wasn't enough: someone had already reached one of its stages. That's why I put the competitive advantage in a team's own map of the target. Access to models is shared; accumulated knowledge of where to look and what's worth pursuing is what sets a team apart.

I think XBOW was primarily interested in the position this work could earn them. The $250,000 comes with a verdict from Google, but the value of demonstrating a chain like this goes much further. They're learning to master offensive work with semi-autonomous agents while much of the market is still debating whether it works. Getting there first, proving it, and building that expertise gives you a position that's hard to establish later, once the market has taken shape.

What to check on the defensive side

The post closes with "defend accordingly." The three fixes give a fairly concrete idea of where to start.

Look for the parts of your code that depend on something no longer being able to change. A transferred buffer may still have another view with write access. A published value may still have a path through which it can be modified. Even a paused process may not be as still as the code reading its memory expects. In this chain, the missing guarantees were added only after the exploit.

Apply the same standard when evaluating a vendor's findings. Ask for them to be reproduced under your own adjudication, with a negative control that doesn't trigger. A well-written report doesn't settle that question. Until the result can be reproduced on demand, you still have a hypothesis to verify.

It's also worth respecting the limits of what XBOW showed. They used a frontier model with restricted access, their own harness, and four researchers whose judgment was needed at every stage. Reproducing that capability takes considerably more than paying for API access. This was also a responsible disclosure process, validated and rewarded; the case doesn't demonstrate exploitation in the wild. The work shows which offensive tasks could be automated and how much human expertise it took to make that work.

The first note in this series ended with a slow, noisy worm that could be stopped if someone was watching. In that note, we covered the case from Anthropic's paper: a small model assembling a Chrome N-day chain for $20.40, with twenty minutes of human supervision. Today we have XBOW building a zero-day chain for $40,000 and receiving $250,000 after Google validated it. Both results became public in the same week. Reading them together helps put the different scales of this work in perspective.

As a defender, I want to know what I can verify for myself before accepting a finding. We built NAXXAN's gate around that requirement: every finding we deliver has been reproduced twice, with a negative control that did not trigger. The supporting evidence carries a verifiable fingerprint. You can check it at naxxan.ai/verify.

This is note 2 of 5 in THRESHOLD, covering the eight weeks when the floodgates opened. The next one looks at a safeguard that gives way to a very old excuse, and what that means for where authorization needs to live. There's more to tell, including more than will fit in these five notes.