On 27 October Anthropic's Frontier Red Team said an unreleased Claude research model had written a working remote root exploit for Linux servers. No login, no user action: send packets to the right listener, and a shell command runs as root. The underlying bug is tracked as CVE-2026-98432, and it has been in the kernel since Linux 4.4.
The fix is upstream. The problem is that, as of 29 October, Ubuntu and Red Hat had not shipped it, and the vendors cannot agree how serious it is. That combination is where most companies get stuck, so this piece is about what to do in the gap.
Key numbers
- 9.8 CVSS from the Linux kernel CVE team, 5.9 from Red Hat's public page
- Since Linux 4.4, so nearly every maintained distribution kernel
- 48 minutes to leak a kernel pointer in Anthropic's test, 5 more to run a root command
- Not in CISA's KEV catalogue, and no public exploit code
What the bug is
When a Linux server completes a TCP handshake over IPv4, the kernel hands the IP options stored with the pending connection to the new socket without copying them. Another CPU core can still be reading those options, for example to answer a resent SYN, while the first core frees them. The result is a use-after-free in the handshake code.
The upstream fix by Eric Dumazet, crediting Anthropic researcher Xinyang Ge, makes the kernel wait until every reader is done before freeing the options. It also closes a second path through TCP request socket migration (the net.ipv4.tcp_migrate_req setting or a BPF reuseport program). IPv6 is not affected by the main race, because its version of the function copies the options.
Anthropic's exploit wins the race repeatedly to make the kernel send back extra memory until a reply contains a kernel pointer, which defeats KASLR. It then uses the same bug to overwrite a callback pointer and run a payload as root. A lost race only fails that one handshake and does not crash the server, so an attacker can simply keep trying.
Two caveats matter. Anthropic's exploit targets servers with a multipath TCP (MPTCP) listener, while the CVE record and the kernel fix do not mention MPTCP at all. And no outside team has reproduced the chain yet. Treat the exact attack path as Anthropic's claim, and the bug itself as real either way.
Why the scores disagree
The kernel CVE team scores it 9.8, assuming an unauthenticated attacker who sends a SYN with IPv4 Record Route or Timestamp options and resends it to hit the race. Red Hat's public page rated it Moderate, 5.9, citing how hard the race is to win and calling denial of service "the practical worst case". SUSE and Oracle say 8.1, Amazon 7.0, and Ubuntu uses 9.8 with High priority.
A working root shell in a lab does not sit well with "denial of service is the worst case". The lesson is not about who is right. It is that a vendor's severity rating is an input, not a decision. If your patch policy says "patch critical within 7 days, moderate within 90", this bug lands in a different queue depending on which page your scanner reads.
Patch status
The fix ships in stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Distribution status as reported by Cyber Kendra on 29 October:
| Distribution | Status |
|---|---|
| Debian 12 and 13 | Fixed |
| Oracle Linux 7 to 10 (UEK) | Fixed |
| openSUSE Leap 16.0, SUSE Linux Micro 6.2 | Fixed |
| Amazon Linux 2023, kernel 6.12 and 6.18 | Fixed |
| SLES 15 SP4 to SP7, SLES 16.0 | In progress |
| Amazon Linux 2, Amazon Linux 2023 default kernel | Pending |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Vulnerable, fix in progress |
| Ubuntu 16.04 to 20.04 | Vulnerable |
| RHEL 8, 9, 10 and OpenShift 4 | Fix deferred |
| RHEL 7 | Not affected |
This moves daily. Check your distribution's own tracker before you act on the table.
What to do this week
1. Find the servers that matter first
Not every Linux machine carries the same risk. Start with servers that accept TCP connections from the internet over IPv4: web front ends, load balancers, VPN and mail gateways, anything in a DMZ. Then check which of them run an MPTCP listener, since that is the path Anthropic exploited. Internal-only servers come next. Your asset inventory and attack surface management tools should be able to answer "which internet-facing hosts run which kernel" in minutes. If they cannot, that is the finding.
2. Patch where a fix exists, and reboot
On Debian, Oracle Linux, openSUSE and the fixed Amazon Linux kernels, install the update now. A kernel fix does nothing until the machine restarts on the new kernel, so check the running version after the reboot, not just the installed package. If you use live patching, confirm with your vendor that this CVE is covered before you skip the reboot.
3. Where there is no fix yet, reduce the exposure
For Ubuntu and RHEL, while you wait:
- Turn off what you do not use. If a server does not need multipath TCP, disable it (
net.mptcp.enabled=0). This removes the path Anthropic exploited. It is not proven to close every path to the bug, so treat it as risk reduction, not a fix. - Close the second path. Make sure
net.ipv4.tcp_migrate_reqis off unless you rely on it. - Filter IP options at the edge. The scoring scenario needs a SYN carrying IPv4 Record Route or Timestamp options. Ordinary traffic almost never uses them, and many firewalls can drop packets with IP options. Test it on one service first.
- Shrink the listener list. Anything that does not need to be reachable from the internet should not be. Put administrative services behind a VPN or zero trust access.
- Watch the handshakes. A race-based exploit means many attempts. A sudden rise in failed handshakes or resets on a listening port is worth an alert in your SIEM.
4. Write down the decision
If a server stays unpatched for weeks because the vendor deferred the fix, that is a risk someone should accept by name. Record the host, the compensating controls, the owner and the date you will look again.
The bigger point
Anthropic says the model found the bug, chained it and wrote the exploit after a single prompt from a researcher. The same post covers 62 Chrome CVEs and working chains for Safari, Android and Windows, all reported to the vendors and fixed. Whatever you think of the claims, the direction is clear: the time from "bug exists" to "working exploit" is getting shorter, and the same tools are available to defenders.
That changes the arithmetic of patch management. A process built on "nobody will exploit a hard race condition in time" is betting on attacker effort that is getting cheaper every month. The parts you control are how fast you know what you run, how fast you can reboot it, and what you do on the days when there is no patch yet.
Sources: Cyber Kendra on the CVE record, vendor scores and distribution status; Cyber Security News and Cyber Kendra on Anthropic's research post of 27 October 2026.
