Anthropic says an unreleased model built five attack chains; Chrome's notes label 28 CVEs as its, the post says 62

Sixty two Chrome CVEs in the post, twenty eight labelled as Anthropic in the notes it links

Anthropic's Frontier Red Team post of 27 October 2026 says an unreleased internal model was used to find critical flaws and write attacks, in five "attack chains". For Chrome it says: "62 CVEs have been assigned and patched as of Chrome 156". This briefing counted the credit lines in the 13 Chrome stable desktop release notes from 1 September to 27 October 2026, including the 20 October note the post links, read from 09:14 UTC on 28 October. Across six of those releases, 28 CVE lines credit Anthropic or Claude: 5 rated critical and 23 high (derived by counting). That is 28 of 62, or 45 per cent (derived).

What that does not establish: that the post is wrong. The release notes do not label a bug as a sandbox escape, so the post's 13 sandbox escapes and 21 renderer compromises cannot be checked here. The 62 may include CVEs credited under other wording, in notes this briefing did not read (extended stable, early stable, Android and iOS), or in a later count. The notes also carry 45 more lines credited to a single reporter name with no Anthropic or Claude label; they are not counted, because the notes do not link them to Anthropic, and even with them the total is 73, not 62. What the count does show is that the figure the post leads with cannot be rebuilt from the public notes it points to.

The other four items are thinner still on the public record. The Windows flaw, CVE-2026-33096, was published on 14 April 2026, 196 days before the post (derived). The Linux flaw, CVE-2026-98432, is described by its own CVE record as a bug in ordinary IPv4 TCP, and the record never uses the word multipath. No Android or Pixel bulletin read names the lock screen item at all. And the Safari chain does not match any Apple entry read. The headline on The Hacker News for the same story, as it appeared in a feed on 28 October, calls all of it exploits for Chrome, Safari, Windows and Linux; that page sits behind a challenge and was not read.

Method, in one paragraph. The post itself was read from a saved text copy of the page. That copy carries no date line, so the date of 27 October 2026 comes from the research listing page it came from. Each vendor and CVE record was fetched directly after reading the host's robots.txt, with an identifying user agent and light volume. Two hosts that would have carried the Linux patch text, git.kernel.org and lore.kernel.org, disallow all automated access in robots.txt and were not requested. Microsoft's Security Update Guide page for the Windows CVE loads only with JavaScript and could not be read; the same record was read from CVE.org and NVD instead. Anthropic sells access to its models and runs a Cyber Verification Program, and the post's closing advice points to both, so it has a commercial interest in the capability it reports.

Five items, five impact classes: only two are code execution on a user's machine

The headline word is "exploits". The post's own word is "attack chains", and its own list shows they are not alike. One is a single flaw that crashes a server and is not code execution. One is a data theft chain that, in the post's words, "never relies on arbitrary code execution". Chrome and Linux are code execution, and Android is a lock screen bypass that needs a stolen phone in hand. The table sets out what the post says each one shows, in its own terms, and what it does not show.

Zoom

The unreleased model: what the post says about it, and what it leaves open

The post never names the model. It says only that "over the past few months" Anthropic used "an unreleased, internal research model", and it names three released models (Claude Opus 5.5, Claude Sonnet 5.5 and Claude Mythos 5.1) only as what the Cyber Verification Program gives access to. Nothing here guesses at a name. The post does not give parameters, who has access, cost, the number of attempts, the number of reports sent in total, or how many findings were false.

Every one of the five chains opens with the same phrase: "After initial prompting". That phrase carries the human share of the work and does not define it. For Windows the post says more: it "provided the model with a copy of the Windows executable" and asked it to reverse engineer the software with existing tools such as Ghidra, write an annotated C program that reproduces the features, compare it with the binary, and then study the code. A separate step, asking it to identify potentially higher risk issues, is where the denial of service surfaced (paraphrase). The post also describes a platform running "large numbers of scanning agents in parallel", with a verification and risk rating pipeline. So the model did not wake up and find these alone: people designed the harness, chose the targets and the prompts, and verified the results. The post says models now do this "with little human involvement", and does not say how little.

Earlier briefings on this site read other Anthropic security claims in the same way: its Cyber Verification Program test and its self replication test. For the wider pattern of AI found flaws arriving faster than patches, see the briefing on the October vulnerability surge. They are not repeated here.

Chrome: 28 labelled CVEs in six releases, fixed 4 to 27 days after the credited report dates

The post links to the Chrome 156 stable desktop note of 20 October 2026. That note lists 353 security fixes, and 5 of its CVE lines carry a credit that reads "(Anthropic), assisted by Claude" (1 critical, 4 high). The same note carries 10 more lines credited to the same reporter name with no label. Going back to 1 September, the table shows where the labelled lines fall. The first appears on 2 October and the last on 27 October, which is the day of the post, in a Chrome 156 point release.

Three readings follow, all derived. First, the severities fit the post: every labelled line is critical or high. Second, the labelled lines name 21 components. Two are V8, both use after free. None is FedCM or CacheStorage, the two components the post names for the third and fourth steps of the chain. The notes do list a FedCM use after free (CVE-2026-103630, high, 2 October) credited to a bare first name, and a CacheStorage race condition (CVE-2026-106300, medium, 6 October) credited to Google. Whether either belongs to the chain is not stated by the notes or by the post, and the post names no CVE ids for the chain. Third, the reported dates in the credit lines run from 24 September to 12 October. Counting from each credited report date to the date of the release note that lists it, the gap is 4 to 27 days, with a median of 12. The fix may have reached the source code earlier than the note, so these are upper bounds on the time to fix.

What a defender needs from this: the labelled lines are fixed in Chrome 154.0.8037.97 and later builds listed above, and the last of them in 156.0.8078.73 (Windows and Mac .73 or .74, Linux .73). That later builds contain earlier fixes is an inference from the numbering, not a statement in the notes. The notes say the update "will roll out over the coming days/weeks".

Safari: the linked Apple page credits one entry, and none of the entries read matches the chain

The post says Apple acknowledged the report "the same day we submitted it" and that a fix "is available", and links Apple's security page 127594. That page is for iOS 26.5.2 and iPadOS 26.5.2, released 29 June 2026, with Apple's page published 27 July 2026. It carries one entry credited "with Claude, Anthropic": a WebKit use after free whose stated impact is memory corruption. It does not describe a same origin policy bypass or a read of history and cookies from disk under that credit. Other WebKit entries on the page describe cross origin data exposure and a sandbox issue, but credit other reporters.

The Safari 27.2 note of 26 October 2026, the day before the post, carries three WebKit entries credited "with Anthropic Research": a use after free ending in a process termination, a type confusion with arbitrary code execution, and a use after free in Canvas with arbitrary code execution. None describes the data only chain the post describes either. Both pages credit named researchers, who are not named here. So the record shows Anthropic credited by Apple on at least four WebKit entries, and does not show which, if any, is the Safari chain. Derived: the iOS release was 120 days before the post, and Apple's page publication 92 days before it. The report date is not stated, so no comparison with the 90 plus 45 day policy is possible.

Android: "addressed by Google" is the post's sentence, and no bulletin read names the item

The post says the lock screen bypass "has been addressed by Google" and gives no CVE, no date and no patch level. The Android Security Bulletins for July, August, September and October 2026 and the Pixel Update Bulletins for August, September and October 2026 were searched in full for those names. None names Anthropic or Claude, and none mentions USB host mode, device to device transfer or lock screen data access. The October Pixel bulletin, published 6 October, says patch levels of 5 October 2026 or later address its issues. That does not tie any entry to this item.

Two things follow. The post says part of the work was reverse engineering of Google Play services binaries, and Play services updates are not described in the bulletins read, so a bulletin may not be where this fix would appear. That is an inference. And the post says the work used one Pixel 9, so whether other makers' phones are affected is not stated. A defender cannot confirm this fix from the public record read here; the question to put to Google is in the checklist.

Windows: a denial of service whose CVE was published on 14 April, listed as HTTP.sys

The post says Claude identified a memory safety out of bounds read in the Windows kernel's implementation of QUIC (paraphrase), reachable by sending "a few packets of data" to a listening server so that it crashes and restarts, and links CVE-2026-33096. The CVE.org record, assigned by Microsoft, is titled "HTTP.sys Denial of Service Vulnerability" and describes an out of bounds read in Windows HTTP.sys that lets an unauthorised attacker deny service over a network (paraphrase; the exact text is in Technical details). Neither the record nor NVD's copy uses the words QUIC or HTTP/3, credits anyone, or mentions Anthropic.

Dates from the record: the ID was reserved on 17 March 2026, published on 14 April 2026 (a Tuesday, derived), and last updated on 15 October 2026. The post came 196 days after publication and 224 days after reservation (both derived). Reservation is not the report date, so "the model found it by then" is an inference at best. It does mean the flaw has been public as a Microsoft CVE for about six and a half months, which is hard to square with "over the past few months" and with the idea that it is new.

Microsoft rated it 7.5 high, with a vector that sets exploit code maturity to unproven at publication. CISA's assessment in NVD, timestamped 15 April, reads exploitation none, automatable yes, technical impact partial. The record lists fixed builds for Windows 11 versions 23H2, 24H2, 25H2 and 26H1 and Windows Server 2022, 2022 23H2 and 2025, and lists none for Windows 10 or older servers, without saying why. They are in the Technical details section. The monthly update that carries the fix is not named in either record, and Microsoft's own page was unreadable, so no update number is given here. The "several million" listening servers is Anthropic's estimate, with no method given; no scan of exposed hosts was read.

Linux: the CVE record describes IPv4 TCP, not multipath TCP, and was published 12 days before the post

The post describes a race condition use after free in the kernel networking stack, against a server with a "multipath TCP listener". In its first stage the attacker uses the race to make the kernel read a length field the attacker controls and send extra bytes back, to learn where the kernel sits in memory (paraphrase). In its second stage the same use after free is used to overwrite a callback pointer. A "lost race only fails the handshake without crashing the whole system", so an attacker "can retry indefinitely". In the proof of concept that took "48 minutes to leak a kernel pointer and another five minutes" to run a shell command, which is 53 minutes in all (derived).

The record the post links, CVE-2026-98432, was assigned by the Linux kernel CNA, reserved on 25 September 2026 and published on 15 October 2026. Its title is "ipv4: free inet_opt and ireq_opt after an RCU grace period". The text describes a use after free of IPv4 options in the TCP handshake, when a retransmitted SYN races the teardown of a connection, and says IPv6 is not affected by the first issue. The words multipath and MPTCP appear nowhere in the CVE.org record, the NVD copy or Tenable's copy. The CNA's own scoring text, rated 9.8 critical, says an unauthenticated peer can supply IPv4 option bytes in a SYN and that reclaiming the freed object "can therefore disclose adjacent kernel heap contents directly to the peer". That reads like the post's first stage (inference), and it does not need multipath.

There are two readings, and the record cannot choose between them. Either the CVE is the item in the post and multipath TCP is a route to the same code that the CVE text does not mention, or the post's description and the CVE do not match exactly. On the first reading, any IPv4 TCP listener on an affected kernel is in scope, which is far wider than servers with multipath TCP, and turning multipath off would not be a fix. The kernel documentation describes the switch (the enabled setting under /proc/sys/net/mptcp), but does not call it a mitigation for this CVE. Patch, do not rely on it. The record lists fixes in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3, and an affected range starting at version 4.4. Whether those are "all maintained stable kernel branches", as the post says, was not checked. NVD lists the record as "Received", meaning not yet analysed, on 28 October.

Dates against the post's 90 plus 45 day policy

The post says vendors get "90 days to patch and a further 45 days before we discuss details beyond what is already included in a public advisory". That is 135 days (derived). Anthropic gives no report date for any item. The table counts from the earliest dated public record instead, and every count is derived.

Zoom

Two readings. For Windows, the post came well beyond 135 days, which fits the policy. For Chrome and Linux, the dated records put the post inside the 135 day span, 15 to 33 days after the Chrome reports and 32 days after the Linux reservation. The policy's 45 day wait applies to details beyond a public advisory, and the Chrome notes say bug details may be restricted until most users have the fix, while the post gives step by step detail. Whether Google and the kernel maintainers agreed to earlier discussion is not stated; vendors can agree shorter terms. A reader should not assume a breach of the policy from these counts, and should not assume the opposite either.

Stated and not stated

Four friendly names that stand in for evidence

"Unreleased model" is a label with nothing behind it: no name, no size, no access, no cost. A reader cannot compare it with any model they can use, so "what a model can do" stays a claim about a black box. "Assisted by Claude" is a credit string. It records that a tool was used and does not say how much of the finding was the tool's. The notes also carry the same reporter name without it, which shows the string is applied unevenly.

"Zero click" is true of the attack described, but only for hosts that reach the vulnerable code. If the CVE is the bug in the post, that is any IPv4 TCP listener on an affected kernel, and the post's "multipath TCP listener" narrows it in a way the record does not. "Patched" and "addressed" are a vendor's word. A patch is a version number on a machine, and for Android and Safari the public record read here gives no number that matches the item described.

"Cyber Verification Program" verifies an organisation. It does not verify a session or a use. The post recommends it, with its own models, in the same paragraph as its advice to scan your own code. That advice is sound, and it is also the advice a model seller would give.

Technical details

This section holds the artifacts the primaries print: the step lists as the post gives them, the CVE records and fixed builds, and the version checks. No exploit code and no proof of concept is published by the post, and none is written here. Names of credited reporters are left out of every block and marked where they were.

The post's step lists, paraphrased by this site, with the post's own words in quotation marks. These are the steps as Anthropic describes them, not independently confirmed.

1 Chrome (4 steps).

1. A flaw in V8, the JavaScript engine, lets a page "corrupt V8's heap memory".
2. A second flaw leaves V8's memory region sandbox and defeats ASLR; a ROP chain takes control of the renderer.
3. A race condition in CacheStorage lets the renderer read memory outside its sandbox and learn the browser process layout.
4. A use after free in FedCM, the federated sign in feature, executes code outside the sandbox.

2 Safari (4 steps).

1. A use after free in JavaScriptCore in certain TypedArray operations overwrites TypedArray metadata.
2. Variables in the Gigacage region used "to index into other regions" give read and write outside it.
3. A flaw in the WebContent sandbox's IPC reads stored history, cookies and session databases from disk.
4. The use after free overwrites a variable to disable the same origin policy.

3 Android (four protections, three flaws chained).

1. A USB host "with a specific setting" bypasses the block on data transfer over USB on a locked phone.
2. The authorisation check of the device to device transfer protocol is skipped to start pairing.
3. The six digit code verification of the key agreement is skipped, as if the user had tapped Allow.
4. A fallback that sends raw bytes over USB is not covered by the hardcoded check, and is used to request file contents.

4 Windows (1 flaw). An out of bounds read in the Windows kernel's QUIC implementation, reached remotely with a few packets, crashes and restarts the machine.

5 Linux (2 stages).

1. A race makes the kernel read an attacker controlled length field and send extra bytes back, leaking a kernel pointer and defeating KASLR.
2. The same use after free overflows a buffer and overwrites a callback pointer with the address of a payload staged in kernel memory, ending in a shell command as root.

[N/A][571618833] Critical CVE-2026-113271: Use after free in Accessibility. Reported by [name omitted] (Anthropic), assisted by Claude on 2026-10-08
[N/A][565838017] High CVE-2026-113020: Improper input validation in Date. Reported by [name omitted] (Anthropic), assisted by Claude on 2026-09-24
[N/A][566136673] High CVE-2026-113318: Memory corruption in ServiceWorker. Reported by [name omitted] (Anthropic), assisted by Claude on 2026-09-25
[N/A][567612004] High CVE-2026-113093: Memory corruption in DisplayLocking. Reported by [name omitted] (Anthropic), assisted by Claude on 2026-09-29
[N/A][572237007] High CVE-2026-113212: Memory corruption in PDF. Reported by [name omitted] (Anthropic), assisted by Claude on 2026-10-10

The two builds that cover every labelled line, as the release notes print them. Check your own build in the browser menu (the steps are in the last block below).

Chrome 156.0.8078.47 (Linux) 156.0.8078.47/.48 Windows/Mac contains a number of fixes and improvements
The Stable channel has been updated to 156.0.8078.73/.74 for Windows and Mac and 156.0.8078.73 to Linux

The Windows record: what Microsoft assigned and the builds below which a system is affected. A build at or above the listed one carries the fix. Read the build of a machine with the commands in the last block below.

Title: HTTP.sys Denial of Service Vulnerability
Description: Out-of-bounds read in Windows HTTP.sys allows an unauthorized attacker to deny service over a network.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:C  (7.5 HIGH, Microsoft)

Affected from, fixed at (record: lessThan):
Windows 11 version 23H2 (x64 and ARM64)   10.0.22631.0   10.0.22631.6936
Windows 11 version 24H2                   10.0.26100.0   10.0.26100.8246
Windows 11 version 25H2                   10.0.26200.0   10.0.26200.8246
Windows 11 version 26H1                   10.0.28000.0   10.0.28000.1836
Windows Server 2022                       10.0.20348.0   10.0.20348.5020
Windows Server 2022, 23H2 (Server Core)   10.0.25398.0   10.0.25398.2274
Windows Server 2025 (and Server Core)     10.0.26100.0   10.0.26100.32690

The Linux record: the title, the score and the fixed versions. The affected range begins at 4.4. A distribution numbers its own kernels, so a distribution kernel may carry the fix under a different version; that is an inference to confirm with the distribution's advisory, which was not read.

Title: ipv4: free inet_opt and ireq_opt after an RCU grace period
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  (9.8 CRITICAL, assigned by the CNA)
Fixed (unaffected from): 5.10.272  5.15.223  6.1.190  6.6.159  6.12.113  6.18.56  7.2.10  7.3
Affected since: 4.4

/proc/sys/net/mptcp/* Variables

enabled - BOOLEAN
Control whether MPTCP sockets can be created.
MPTCP sockets can be created if the value is 1. This is a
per-namespace sysctl.
Default: 1 (enabled)

WebKit
Impact: Processing maliciously crafted web content may lead to memory corruption
Description: A use-after-free issue was addressed with improved memory management.
WebKit Bugzilla: 313577
CVE-2026-43715: [two names omitted] with Claude, Anthropic

Version checks, each as the vendor's own page prints it. None is a detection rule: the primaries publish no indicators, hashes, domains or packet captures for any of the five items, and none are given here.

Chrome:   On your computer, open Chrome. At the top right, click More. Click Help About Google Chrome.
          The current version number is the series of numbers beneath the "Google Chrome" heading.
iPhone:   Tap General. Tap Software Update. The currently installed version of iOS is shown.
Mac:      System Settings, then General in the sidebar, then Software Update.
Pixel:    You can find your Pixel phone's Android version number and security update level in your Settings app.
          Bulletin text: security patch levels of 2026-10-05 or later address all issues in this bulletin
Windows:  ver                              (Command prompt)
          $PSVersionTable.BuildVersion     (PowerShell)
Linux:    uname -r                         (print the kernel release)

What to do, in the order worth doing

The question

If a lab can say it chained a browser, a phone, a kernel and a Windows server in one season, can you show, for each of your own update channels, the build number on the machine that proves the fix is there, and the person who would tell you if the vendor's record did not match the vendor's post?

Key facts