If your Linux servers run Ubuntu, you cannot install a fix for CVE-2026-98432 today, and Anthropic says an unreleased Claude model has already written a remote root exploit for it. Ubuntu's tracker, last updated October 30 and checked November 2, lists 22.04, 24.04, 26.04 and 26.10 as vulnerable with fixes in progress. Red Hat shipped kernels for RHEL 8, 9 and 10 on November 1. Set your patch order from two facts: whether your vendor has a kernel, and whether the host exposes a multipath TCP listener. The CVSS score will not help you, because vendors have published anything from 5.9 to 9.8.
The flaw is a race in IPv4 TCP connection setup that makes the kernel read memory it has already freed, and it dates to Linux 4.4. No attacks had been reported as of October 29, and CISA's known-exploited catalog returned no result for it on November 2.
Which Linux Distributions Have a Fixed Kernel?
Debian, Oracle's UEK, Amazon Linux and now RHEL have fixed kernels, while Ubuntu and several specialized Red Hat products do not. Anthropic's post says the flaw "was patched upstream and backported to all maintained stable kernel branches." That is accurate, and it does nothing for a host running a distribution kernel until the distribution ships a build.
| Platform | Status | Install |
|---|---|---|
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Vulnerable, work in progress | Nothing yet. Target builds include 5.15.0-203.213 and 6.8.0-149.149 |
| Ubuntu 16.04, 18.04, 20.04 | Vulnerable, no target build listed | Nothing yet |
| RHEL 8 | Fixed Nov. 1, advisory rated Critical | kernel-4.18.0-553.182.1.el8_10 |
| RHEL 9 | Fixed Nov. 1, advisory rated Important | kernel-5.14.0-687.64.1.el9_8 |
| RHEL 10 | Fixed Nov. 1, advisory rated Important | kernel-6.12.0-211.72.1.el10_2 |
| RHEL 9 kernel-rt, RHEL for NVIDIA 26, OpenShift 4 and 5 CoreOS | Affected, no release listed | Nothing yet |
| Debian 12 and 13 | Fixed | 6.1.190-1 and 6.12.113-1 |
| Amazon Linux 2 and 2023 | Fixed by Oct. 30 | See the advisory for your kernel package |
| SUSE | Mixed: SLES 16.0 released, SLES 15 SP7 in progress | Check your product row |
Status was read from each vendor's page on November 2, 2026. Re-read before you act on it, since these pages moved several times last week.
GPU fleets deserve a separate look. Ubuntu's linux-nvidia package on 24.04 shows as plain "Vulnerable," with no work-in-progress build named, while the 22.04 package names one. Red Hat's NVIDIA kernel is on its still-affected list too. If you bought those images to keep driver support simple, your fix may arrive later than the general-purpose kernel on the rest of your estate.
Rebuilds are uneven. AlmaLinux 8, 9 and 10 had the fix in production repositories on November 2. CIQ checked Rocky Linux 8.10, 9.8 and 10.2 on November 2 and found no fixed kernel. TuxCare listed Oracle's Red Hat compatible kernel as affected with nothing released as of October 30, and Red Hat's errata do not install on those systems. Check your rebuild's own advisory feed.
Do Not Compare Kernel Version Numbers
Vendor backports make uname -r an unreliable test, so verify against the vendor's advisory. The upstream fix landed 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. RHEL 8's fixed kernel is numbered 4.18, which is below every one of them.
The Amazon case shows how this misleads people. The EKS AMI release v20261031 lists kernel 6.1.189-236.400.amzn2023 for Kubernetes 1.31 and 1.32, one number below upstream's 6.1.190. One published guide reads those AMIs as still exposed. Amazon's own ALAS2023-2026-3365 names exactly that package as the fix. A scanner or a script keyed to upstream numbers would send your team to patch the wrong nodes.
Managed Kubernetes is the least clear part of this. Every container on a node shares that node's kernel, so this is a node image problem. On AWS, the release above is the answer for AL2023 nodes. Google's GKE bulletin page showed GCP-2026-071, dated October 23 and updated October 27, as its newest entry on November 2, and that one covers a different CVE. We found no AKS statement naming this CVE. Microsoft's docs say Linux node images update weekly and can take up to two weeks to reach all regions, and a node image built on Ubuntu cannot carry a kernel Ubuntu has not released. Treat GKE and AKS status as unknown and ask your provider.
Why Multipath TCP Decides What You Patch First
The only demonstrated root exploit targets servers with a multipath TCP listener, so those hosts go first. Multipath TCP (MPTCP) is an extension to standard TCP, described in RFC 8684. Anthropic describes an attack in which a remote sender with no credentials or user interaction gets commands run as root on such a server.
You may have these listeners without having chosen them. The Go Security Team warned on October 29 that "As of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux." Nobody would notice, because an MPTCP listener also accepts plain TCP from clients that did not request MPTCP. A Go service inside a pod can open that listener in the node's kernel, and ss -Mlnp shows you which ones are running.
Hosts with no MPTCP listener are in the second tier and still on the list. The record has a real conflict here. Anthropic's exploit targets multipath TCP listeners, while the CVE record and the kernel fix describe IPv4 TCP and never mention MPTCP. Red Hat's bulletin does not mention it either, and says a remote, unauthenticated attacker could exploit the race during TCP connection request processing. The Go team wrote that "It is possible that systems with no MPTCP listeners are vulnerable to similar attacks." TuxCare, which sells kernel patching and so has an interest here, says nobody has publicly shown root on a server without an MPTCP listener and calls those hosts "less exposed, not fixed." CIQ, which sells Rocky Linux support, tested this with MPTCP disabled: a plain TCP listener on every kernel it tried still answered a SYN carrying a Record Route option, and it concludes "Disabling MPTCP is not enough." That test shows the vulnerable path stays reachable and stops short of showing root.
IPv6-only addressing is a partial answer at best. Ubuntu's description says IPv6 escapes the first issue but has a related migration issue still to be addressed separately.
Why the CVSS Scores Disagree
The 9.8 and the 8.1 differ on one input, attack complexity. The kernel CVE team scored the flaw 9.8 on October 24, rating complexity low. SUSE rates it high and lands on 8.1, and Amazon's page shows the same 8.1.
Red Hat has moved furthest. The Hacker News reported 5.9 on its CVE page, which cited no demonstrated confidentiality or integrity impact, and 8.1 in its advisory file on October 29 and 30, with fixes "currently deferred to a future update." Its security data now shows Critical at 9.8, and its bulletin said on October 30 that it was expediting fixes. The November 1 advisories still split, with Critical for RHEL 8 and Important for RHEL 9 and 10.
A high complexity rating assumes the race is hard to win. Anthropic's account cuts against that in one specific way: a failed race only fails that handshake, so the attacker retries. It reports 48 minutes to leak a kernel pointer and about five more to reach command execution. A race you can retry for an hour without crashing the target is slow, and your SLA should still treat it as the 9.8. A policy that sends 8.1 to the 30-day queue would have put this flaw in a different lane depending on which vendor's page your scanner reads.
How Much of Anthropic's Claim Can You Verify?
Very little of the exploit claim can be checked from outside. Anthropic attributes the work to an unreleased, internal research model it does not name, and says Claude wrote the exploit "after initial prompting," with no count of what people did. It did not publish exploit code, the kernel version or the test configuration, and TuxCare found no independent reproduction as of October 30. CloudLinux, which ships its own kernels, went further the same day: "Our kernel team couldn't reproduce that claim," it wrote, adding that the memory error its team triggered with artificial delays is far from code execution. With Anthropic's configuration unpublished, that failed attempt cannot refute the claim either. Anthropic also sells a security product built on its models. The Hacker News made the same point: readers cannot verify how much of each chain the model built alone.
The skeptical reading is reasonable, and Red Hat's public description still leans toward a crash or possible memory corruption. It also changes nothing about this week's work. You would patch a pre-auth kernel flaw in the TCP handshake on its own merits, with or without the AI claim. Nor does the timeline measure attacker speed, since Anthropic had the bug before the public did. The CVE was published October 15 and the post followed 12 days later, which tells you about its disclosure schedule.
What the post does support is the direction of cost. Anthropic describes 62 Chrome CVEs plus findings in Safari, Android and Windows from the same program, and says "Now, it's something models can do with little human involvement." Google and Apple credit Anthropic and Claude in their own release notes for specific fixes, so the bug-finding half has outside confirmation. We covered the same trend in Anthropic's formal proof work, its unreviewed OSS scanner reports and Google's restricted Gemini 4 Carbon.
What To Do About It
Patch every host that has a vendor kernel now, and put a tested mitigation on the rest while you wait.
This Week:
- Have your platform lead run
ss -Mlnpacross every Linux host and node, and rank the results by whether an untrusted network can reach them. Internet-facing hosts with an MPTCP listener go first, then any internet-facing IPv4 TCP service, then internal fleets, including GPU nodes. - Install the kernels that exist, and reboot. The Red Hat errata state a reboot is required, so a host that pulled the package and stayed up is still exposed. Confirm the running kernel against the advisory's package name.
- Where no kernel exists, test Red Hat's nftables rule on one host per role. The bulletin's rule drops inbound IPv4 TCP packets carrying IP options, using
ip protocol tcp ip hdrlength > 5. Red Hat says it reduces exposure, cannot fully prevent the flaw and may disrupt workloads. An independent engineer's test on Rocky and Ubuntu VMs saw a Record Route SYN dropped and plain SSH still connecting, without running the exploit. That post warns against using the rule on CIPSO networks and notes it does not survive a reboot unless you persist it. - Turn off MPTCP where you do not use it, on top of step 3, since AWS says this only reduces risk and does not resolve the issue.
GODEBUG=multipathtcp=0covers Go programs, though the Go team calls per-program disabling "a fragile mitigation", and calls in code toSetMultipathTCPoverride it. Settingnet.mptcp.enabled=0stops new MPTCP sockets but leaves existing listeners open, so restart the services and runss -Mlnpagain.
This Month:
- Record each vendor's lag from CVE publication to a fixed kernel. Debian and Oracle shipped within a day or two of the October 15 publication. RHEL took 17 days, and Ubuntu stands at 18 and counting. Bring that number to your next renewal or standardization discussion, because it is a property of the distribution you chose.
- Get written answers from your Kubernetes providers: ask which node image carries the fix and when it reaches your regions. On AKS,
az aks nodepool get-upgradesshows the latest available image, and--node-image-onlymoves to it without a Kubernetes upgrade. - Check your scanner logic. If it compares against upstream version numbers, the EKS example above will produce false alarms, and the same logic can pass an unfixed build. Key it to vendor advisories and write that into the runbook.
The Bottom Line
The hard part of this flaw sits between a stable-branch commit and the kernel your fleet can install, and AI-assisted bug finding will put more load on that gap. The kernel team recommends the latest stable kernel and does not support cherry-picking individual fixes, while enterprise distributions exist largely to do the backporting for you. That trade has always cost some delay. It cost more than two weeks here. Your AI serving stack has its own patch queue on top of the kernel, as vLLM's October advisories and the Ray flaw in CISA's catalog showed.
Anthropic's stated disclosure policy gives developers 90 days to patch and 45 more before it discusses details. Your own plan needs a mitigation for the days between those clocks and your vendor's release, and you should have it tested before the next one of these lands.
Run ss -Mlnp on your fleet today, and watch Ubuntu's tracker for 6.8.0-149.149 and 5.15.0-203.213 to move from work in progress to released.
Continue Reading
- Anthropic Uses Claude to Prove Code in 123 Open-Source Libraries
- Anthropic's OSS Scanner Sends Vulnerability Reports Without Review
- Anthropic Adds Red Team Access to Cyber Verification Program
- Google Opens Gemini 4 Carbon to a Subset of Cyber Defenders
- vLLM 0.30.0 Can Run Code Through Ghostscript Images
- Cohere Signs Letter of Intent to Acquire AISLE for Cybersecurity