An Unreleased Claude Model Chained Five Exploits: Chrome Escapes Its Sandbox in One Visit, Linux Falls With Zero Clicks

What happened

On October 27, 2026, Anthropic's Frontier Red Team published research in which an unreleased, internal research model spent the past few months finding vulnerabilities in Chrome, Safari, Android, Windows, and Linux — and chaining what it found into five working attack chains. The Chrome chain executes code outside the browser sandbox after a single page visit; the Linux chain reaches root remotely, with no login and no user action. According to Anthropic, every flaw went to its vendor first under coordinated disclosure, and details were published only after patches shipped.

The news here is not any single bug's severity but the chaining itself. A lone vulnerability can be found by luck; arranging four or five of them into a complete path from entry point to target used to be work for a small number of specialist teams. Anthropic says a model can now do that work after "initial prompting" and produce a proof of concept anyone can run and verify. How much water that claim holds is a separate question, taken up below. First, the five chains, one by one — because their prerequisites and damage differ completely, and reading them as one blur produces the wrong kind of alarm.

Chrome: four bugs in a row, one visit escapes the sandbox

The Chrome chain is the most detailed of the five. The demo ran on a stock, default-configuration Chrome on macOS: seconds after the page loaded, the Calculator app opened, with no further clicks from the user. The chain has four links, each removing one obstacle.

First, a memory-corruption flaw in V8, Chrome's JavaScript engine, let a malicious page corrupt V8's heap memory. Second, another flaw broke out of V8's memory sandbox and defeated address space layout randomization (ASLR), using a return-oriented programming (ROP) chain to take full control of the renderer process. Third, a race condition in CacheStorage let the compromised renderer read memory outside the sandbox and learn the layout of the more privileged browser process. Fourth, a use-after-free in FedCM, the federated sign-in feature, let the exploit execute arbitrary code outside the sandbox. Four links, and the browser sandbox is fully bypassed.

Anthropic says its reports to Google account for 62 CVEs, all rated critical or high, including 13 sandbox escapes and 21 vulnerabilities that could have compromised the renderer, all patched as of Chrome 156. Two numbers must not be confused: Chrome 156 shipped on October 20 with 353 security fixes in total — the whole release's fix count, from many contributors. Anthropic's 62 is its own reported share.

Safari: an attack that never runs code, and switches off the same-origin policy

The Safari chain is unusual because it never executes attacker code. It is a data-only attack: once it gains read and write access to the browser process's memory, it changes exactly three things — a security flag, an object size, and a URL — and switches off the same-origin policy (SOP). SOP is one of the browser's most basic rules: one website cannot read another website's data. With it off, a malicious page can read the user's Safari history, cookies, and signed-in sessions, and can send authenticated requests to other sites and read the responses. Signed into email, the attacker can read mail; signed into a bank, it can view balances or attempt transfers.

The chain runs in four steps. First, a use-after-free in JavaScriptCore, Safari's JavaScript engine, where certain TypedArray operations wrote through stale pointers to freed memory, corrupting TypedArray metadata. Next, a bypass of WebKit's Gigacage defense: Gigacage isolates TypedArray data in a separate memory region, but the model found variables in that region being used to index into other regions, yielding arbitrary read and write outside the Gigacage. Then a flaw in the WebContent sandbox's IPC mechanism let the exploit read Safari's stored history, cookies, and session databases from disk. Finally, the earlier read/write primitive overwrote a variable in memory and disabled SOP.

Anthropic says Apple acknowledged the report the same day it was submitted and shipped a fix promptly. The Hacker News' check of the public record puts the fix for the chain's central use-after-free in iOS and iPadOS 26.5.2, credited to "Milad Nasr and Nicholas Carlini with Claude, Anthropic." On the Safari chain, at least, the key flaw has a vendor credit that lines up.

Android: a stolen phone, emptied without unlocking it

The Android chain starts from a completely different premise: the attacker already holds the phone. It targets a locked Google Pixel 9, attacked over USB, with the goal of extracting photos and other personal data without unlocking the device.

The phone's defenses fell one by one. A locked phone is designed not to transfer data over USB; the model found a specific USB host setting that bypassed that block. The device-to-device transfer protocol refuses data commands from unauthorized peers; the model found a way to skip the authorization check and start pairing. Pairing is protected by an authenticated key agreement asking the user to verify a six-digit code; the model found a flaw that skipped verification and behaved as if the user had tapped "Allow." Finally, USB transfers carry a hardcoded check forbidding file contents; the model found a fallback mechanism outside that check's coverage and used it to send raw file bytes over USB.

The method is also worth noting: the model combined source analysis of Android's open-source parts, reverse engineering and deobfuscation of Google Play services binaries, and live testing on a physical Pixel 9. Anthropic says Google has fixed the issue, but The Hacker News found no public record for it. So the Android chain's fix status currently rests on Anthropic's word alone — unlike Chrome and Safari, there is no vendor advisory to check it against.

Windows: it can only crash the server — which is trouble enough

The Windows chain does the least damage of the five, but its discovery process says the most about how the model worked. The flaw is an out-of-bounds read in the Windows kernel's QUIC implementation: a few packets sent over the network can crash and restart any server answering HTTP/3 requests with the native Windows stack. Sent repeatedly, the requests keep the server down and all its users locked out. This is denial of service — no code execution, no data theft — but for a public-facing server, sustained downtime is itself the incident. Anthropic estimates several million such servers are listening on the internet.

The discovery was pure binary analysis. Researchers handed the model a copy of the Windows executable and had it reverse-engineer the program's logic with tools like Ghidra, write a fully annotated C program reproducing the relevant features, compare the reproduction against the binary until it matched, and then hunt for vulnerabilities in its own reconstruction. That is where the model surfaced this remotely triggerable flaw. Anthropic says it was reported to Microsoft and assigned CVE-2026-33096.

One public-record mismatch attaches to this chain, and it is held for the discrepancies section below: Anthropic describes kernel QUIC handling, while the public CVE record names HTTP.sys. Keep that discrepancy in mind before judging authorship.

Linux: zero-click root, and failure costs the attacker nothing

The Linux chain carries the worst consequences. Its target is a server running a multipath TCP (MPTCP) listener; a remote attacker with no credentials and no user interaction can run arbitrary commands as root. The exploit has two stages.

Stage one defeats kernel address space layout randomization (KASLR). The underlying flaw is a race condition-induced use-after-free in the kernel networking stack. The attacker exploits the race to make the kernel copy extra bytes, at an attacker-controlled length, and send them back; as soon as one such overread contains a kernel pointer in the reply, the attacker learns the kernel's memory layout. In the demo, this took 48 minutes.

Stage two hijacks control flow. The same bug is reused to overflow a buffer and overwrite a callback pointer with the address of a payload the attacker already staged in kernel memory through an ordinary protocol feature. When the kernel invokes the callback, the payload chains through existing kernel functions and ends with an attacker-chosen shell command running as root. This took five more minutes: 53 minutes from start to a root shell.

The chain has a property defenders should hate: losing the race does not crash the system, it only fails the handshake. An attacker can retry indefinitely until it succeeds. No crash logs, no one-shot luck — time is on the attacker's side. Anthropic ties the chain to CVE-2026-98432, rated CVSS 9.8, patched upstream on October 15, 2026, and backported to all maintained stable kernel branches.

Two public records that do not line up

The part of this research most worth scrutinizing is not the demos but whether the public record corroborates them. The Hacker News checked, and the answer is: partly. Some chains line up; the mismatches sit exactly on the two most serious ones.

Windows first. Anthropic describes an out-of-bounds read in the Windows kernel's QUIC handling, tracked as CVE-2026-33096. The public CVE record instead names HTTP.sys — Windows' built-in web request handler — rates it 7.5, and credits no finder. No open source ties the "QUIC handling" and "HTTP.sys" descriptions together as the same component. So authorship of this chain currently rests on Anthropic's post alone. On the brighter side, U.S. government vulnerability enrichment data marks the flaw as not exploited, and it is absent from CISA's known-exploited catalog — as of late October, no evidence of in-the-wild use.

Linux next. Anthropic's mapping to CVE-2026-98432 matches on severity (9.8) and on the October 15 upstream fix. But the public record describes an IPv4 TCP fix, with no mention of multipath TCP. From the public record alone, you can confirm "a 9.8 kernel TCP flaw was fixed," but not "this flaw is the multipath TCP chain Anthropic demonstrated." The link between them exists only in Anthropic's post.

Chrome sits in between. Google's Chrome 156 release notes do credit "Xinyang Ge of Anthropic, assisted by Claude" — but for specific fixes, not for all 62. Safari lines up best: Apple's credit names researchers "with Claude" for the chain's central flaw. Android has no public record at all.

Laid out as a ledger, the conclusion splits into two layers: the patches are real, and every product in the report did ship fixes; but the authorship claim — "the model found these flaws" — has vendor-credit backing only for Chrome and Safari, component mismatches for Windows and Linux, and no public corroboration for Android. Readers should keep those layers separate: patch facts on one side, capability claims on the other.

What the capability claim proves, and what it does not

Anthropic's core claim is that work once reserved for a few specialist teams — finding several unrelated flaws and combining them into a working exploit — can now be done by a model after "initial prompting" with "little human involvement," producing a proof of concept anyone can run and verify. If that holds, the defender's situation genuinely changes: the cost structure of finding flaws has shifted, so patching speed has to shift with it.

But the post omits the numbers needed to test that claim. The model is unnamed — only "an unreleased, internal research model" — so readers cannot tell how it relates to public Claude versions. Human involvement is not broken down by step: after the initial prompt, did people help choose targets, repair chains, or tune parameters? Nothing says. There are no systematic success rates, costs, or human-hours per chain; only the Linux chain's 48 minutes plus five. Without those figures, outsiders cannot distinguish "the model independently completed the research" from "humans steadied it at key steps."

One misreading should also be avoided: this is not "ask a chatbot one sentence and it hacks Chrome." The demos were produced in a lab, against chosen targets, over months of research, with a parallel scanning platform and a standardized verification pipeline behind them. A public model and a casual prompt are not the same setup. Equating the lab chain with a tool anyone can wield misreads the research.

To be fair, part of the claim is independently checkable. The Chrome and Safari vendor credits do mention Claude's assistance, so the model demonstrably participated in real flaw discovery. What does not follow is equating "participated" with "completed independently." Anthropic's post never separates the two, and readers should not separate them on its behalf.

Three things defenders can take away today

Strip away the capability claim's soft spots and three usable things remain. The first is how the scanning was organized. Anthropic built a platform running large numbers of scanning agents in parallel, measuring each scanner by how many additional vulnerabilities it contributed, and tracking coverage dynamically so the whole codebase gets processed. Strategies ranged from pure coverage (is there a vulnerability in this function?) to goal-based (does this app expose anything that could compromise customer data?) to threat-model-based (does anything bypass its documented threat model?). Every confirmed finding also went through automated variant analysis to catch the same class elsewhere, and all findings passed a standardized verification and risk-rating pipeline, so swapping scanners never lowered the quality bar.

That organization matters because it turns "a model finds flaws" from a one-off demo into a repeatable process. Defenders do not need Anthropic's model to copy the process: run scanners in parallel, judge them by net-new findings, sweep variants of every confirmed issue, and keep verification standards fixed. The process transfers; the model does not have to.

The second is scanning at pull-request time. Anthropic's argument is that fixing the existing backlog solves only half the problem; the other half is cutting the rate at which new vulnerabilities enter the codebase. They built security guidance into development through a publicly released Claude Code plugin, so scanning happens before merge rather than in a post-release audit. For any team, the concrete version is simple: the closer a security check sits to the moment code is written, the cheaper the fix.

The third is the opening Anthropic itself offers defenders: the expanded Cyber Verification Program. Qualifying security professionals get access to models including Claude Opus 5.5, Sonnet 5.5, and Mythos 5.1, with reduced blocking classifiers. The subtext is self-promotional, but the direction is right — defenders' access to powerful models should not lag attackers'.

Patch first, debate second

Before any debate about model capability, one checklist is undisputed. Chrome users should be on 156 or later; Safari users on the fixed iOS and iPadOS release — The Hacker News' cross-check points to 26.5.2; Windows servers answering HTTP/3 should have the April 2026 cumulative update; Linux servers with a multipath TCP listener should be on a kernel carrying the stable-branch backports. Anthropic's disclosure policy gives vendors 90 days to patch plus 45 more before details beyond public advisories are discussed, which means these patches were already out before the article appeared. The remaining risk is not "is there a patch" but "did the patch reach every machine." And because the 45-day window has not fully closed, more technical detail may still follow — the clock on unpatched machines is still running.

The disclosure process itself deserves a word of credit. Every flaw went to its vendor first, and publication waited for patches. That is the key difference between this research and malicious use.

How this differs from the XBOW article

VibeFix already carries an article about AI-found exploits: the XBOW Chrome chain. That piece covers an external agent that spent six days chaining V8 to WebP to Crashpad into a Chrome exploit and earned Google's first $250,000 bounty under a new reward rule. Its protagonist is an external agent in a bounty-hunter setup; its core narrative is the collapsing cost of attack.

This article's protagonist is different: Anthropic's own lab model, five products instead of one Chrome chain, and a narrative centered on an official disclosure pipeline and what defenders should do next. Both articles say "models can chain exploits," but one is an external agent's result under bounty rules and the other is a vendor lab's disclosure after a 90-day plus 45-day process. Treating them as the same story would wrongly suggest a single comparable scoreboard for "model chaining." The models, processes, and verification methods differ, and the scores do not yet line up.

What genuinely overlaps is a single sentence both articles point to: chaining is moving from a craft held by a few specialists to a process that can be run at scale. XBOW shows an external agent can do it; Anthropic shows a lab model can do it across five products at once. For defenders, arguing about which model is stronger misses the point. What matters is whether patch speed can keep up with a "discover, chain, verify" pipeline run at scale. Until patches reach every machine, ranking models is beside the point.