Anthropic published five attack chains yesterday, produced by an unreleased internal research model against Chrome, Safari, Android, Windows and Linux. The Chrome work accounts for 62 CVEs, all rated critical or high, patched as of Chrome 156. Its proof-of-concept opens the macOS Calculator app from a stock browser within seconds of page load, with no clicks after the first. Two more chains carry named identifiers: a Windows remote denial of service (CVE-2026-33096) and a zero-click Linux RCE through a multipath TCP race (CVE-2026-98432). That makes most of the claim checkable against vendor patch notes, which is the real change from Anthropic’s April “thousands of zero-days” number. The post reports only wins: no false-positive rate, no account of what the model missed, no measure of how much human steering each chain took.
One of the five chains ends in a calculator. Anthropic says the Chrome exploit “launches the Calculator app from a stock default-configuration Chrome browser on macOS within seconds of the page loading, without any further user interaction.” That is the oldest demo in memory-corruption research, and it is still the clearest proof that code you wrote is running outside the sandbox.
The post went up on 27 October and describes work by “an unreleased, internal research model to find critical vulnerabilities in some of the world’s most widely used software, such as browsers and operating systems.” Each finding went to the vendor first under a disclosure policy that “gives developers 90 days to patch and a further 45 days before we discuss details.”
The five chains, and what each one reaches
The Chrome chain is the heaviest piece of the work. Anthropic reports that “62 CVEs have been assigned and patched as of Chrome 156, with all of them rated critical or high severity,” and the final hop out of the renderer sandbox came from an unexpected place: “Claude discovered a use-after-free in FedCM, Chrome’s federated sign-in feature, that allowed the exploit to execute arbitrary code outside the sandbox.” Chrome 156 shipped on 2 October, 26 days ago, so anyone on current Chrome is covered.
The Safari chain stays inside the browser and does plenty of damage there. The bug let “any website’s JavaScript completely bypass the same-origin policy,” reaching “a user’s Safari history, cookies, and other sensitive data” and sending authenticated requests to other domains. Apple comes out of this well: “Apple acknowledged our report the same day we submitted it and implemented a fix promptly.”
The other three are shorter in the post but span the stack:
- Android: a lock-screen bypass.
- Windows: a remote denial of service, CVE-2026-33096.
- Linux: zero-click remote code execution through a race condition in multipath TCP, CVE-2026-98432.
Zero-click on a kernel network path is the one to sit with. Everything else in the set needs a user to load a page.
Checkable numbers, after a round of unverifiable ones
Anthropic has made a bigger version of this claim before, and it did not land well. In April it announced Project Glasswing alongside a report on Claude Mythos Preview’s cybersecurity capabilities claiming thousands of zero-days across major operating systems and browsers. Tom’s Hardware ran a blunt critique three days later, pointing out that the headline figure extrapolated from 198 manually reviewed reports, with expert contractors agreeing on the severity rating about 89% of the time, and that much of the underlying set was less damaging than the number implied.
That critique is about the April material, and it holds against the April material. The October post answers it structurally rather than by argument. Five chains, written out step by step, with CVE identifiers and vendor patch confirmations attached. A reader who distrusts Anthropic’s framing can go read Chrome’s release notes instead. “Thousands of zero-days” offered nowhere to go.
The counting problem from that earlier round hasn’t gone anywhere, though, as our post Finding Bugs Got Cheap. Fixing Them Didn’t. set out in early October: huge verified-vulnerability totals on the finding side, a tiny number of confirmed fixes behind them. Sixty-two patched Chrome CVEs is a different kind of number, because every one of them has a vendor on the other end who agreed.
Three absences worth tracking
What the post withholds is as informative as what it shows. There is no false-positive rate. There is no account of bugs the model chased and failed to land, or classes of bug it never found. And the autonomy question stays open: the post refers to initial prompting without quantifying how much human steering each chain needed, so “little to no user interaction” describes the victim’s side of the exploit, and says nothing about the operator’s.
That matters because a vendor-authored account of that vendor’s own offensive capability has no outside replication behind it. The CVE counts survive independent checking. The narrative around them, the degree to which a model drove this rather than assisted skilled humans, rests on Anthropic’s telling. The contrast is with the July Opus 5 release, covered here in Opus 5 Is Allowed to Find Bugs Now, where UK AISI ran a cyber range against the model itself and published its own results.
For anyone running these platforms, the practical read is short: Chrome 156 or later, current Safari, and check whether your Linux fleet has picked up the multipath TCP fix.
Sources: Discovering and exploiting vulnerabilities in critical, real-world software with Claude • Project Glasswing • Claude Mythos Preview’s cybersecurity capabilities
Coverage: Tom’s Hardware on the Mythos claims • Hacker News discussion
Related on this blog: [AUTO] Chrome’s Billion-User Exploit, Built in Six Days • [AUTO] Chrome’s Gemini-Powered Scam Detection Trades Privacy for Coverage • Finding Bugs Got Cheap. Fixing Them Didn’t.