Skip to content
HACKTECH
AI securityReported Published 3 sources

XBOW says AI agents on a public OpenAI model helped build a Chrome full chain in six days

On 13 October 2026 security firm XBOW said its researchers, directing AI agents running OpenAI's publicly available GPT-5.6 Sol model, built a three-bug Chrome exploit chain that could take over a Windows machine when a user loaded a web page. XBOW says the awarded chain was built between 2 and 7 August 2026 for about $40,000 in compute, and that Google paid a $250,000 reward, which XBOW describes as the first full-chain award under Google's 2026 rules. Google confirmed and fixed all three bugs, and XBOW says they were never used against Chrome users. The Hacker News notes that the six-day sprint followed months of earlier work, including a first full chain that took two months.

  • AI vulnerability discovery
  • Chrome
  • exploit chains
  • XBOW
  • bug bounty
  • patch management

What the sources report

  • The Hacker News lists the chain as a V8 bug (CVE-2026-85045, fixed in Chrome 152.0.7977.82 on 3 September), an animated-WebP decoder bug with no confirmed public identifier, and a Crashpad bug (CVE-2026-78952, fixed in 152.0.7977.65 on 25 August).
  • Google's Chrome 152 stable channel notes of 25 August 2026, which list 327 security fixes, credit CVE-2026-78952, a High-severity out-of-bounds write in Crashpad, to an XBOW researcher.
  • XBOW says it deliberately picked a model available to anyone rather than a specialised security model or one with restricted access.
  • According to XBOW, AI agents searched Chrome's source code, tested ideas, built proofs of concept and wrote the earliest exploit drafts, while human researchers set strategy, chose where to look, checked the agents' work and built the chain as three independent parts with backups, which let them swap out a bug Google already knew about.
  • An XBOW researcher wrote that before LLMs a Chrome full chain would take a team of four around six to nine months; the company's first submission took two months and the awarded one six days.
  • Chrome fixes take effect only after the browser restarts, so users should relaunch and confirm version 152.0.7977.82 or later, according to The Hacker News.

What it means for your organisation

XBOW's account puts a working Chrome full chain at six days and about $40,000 of compute using a publicly available model, against months of specialist effort before. As exploit development gets cheaper, the gap between a patch shipping and a usable exploit narrows, so patch latency, including browsers left unrestarted after an update downloads, needs to be measured and capped. The same public model is available to defenders, to search their own code and prove findings before release.

What we check

  • Measure browser patch latency across the fleet, including the time between an update downloading and a restart applying it, and enforce relaunch deadlines through browser management policy.
  • Check that endpoint detection flags a browser process spawning unexpected child processes or writing outside its normal directories.
  • Check whether patch SLAs for internet-facing and user-facing software still assume months between a fix shipping and a usable exploit.
  • Run red-team scenarios that start from a malicious web page and test isolation of administrators and other high-value users.
  • Check whether application testing includes AI-assisted code review, with each finding confirmed by a working proof of concept before it is reported.

Sources

Services that cover these checks

  • Red team & purple team

    Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.

    Duration: 3 to 6 weeks

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • AI & LLM application testing

    Adversarial testing of features built on large language models: chat assistants, retrieval-augmented search, agents with tool access, and generated output that reaches users or other systems. We test whether the model can be steered into leaking data, taking actions it should not, or passing untrusted output into the rest of your stack.

    Duration: 4 to 10 working days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works