Ubuntu and Red Hat Enterprise Linux still have no fixed kernel for CVE-2026-98432, a use-after-free in the IPv4 TCP handshake that Anthropic says its model turned into a remote root exploit. Debian shipped the fix on October 16. Oracle shipped the same day. AlmaLinux put patched kernels in testing on October 30 rather than wait for Red Hat. If you run Ubuntu or RHEL on anything with a public port, you're filtering packets around a bug the rest of the Linux world patched two weeks ago.
The upstream fix is two lines. It was applied on October 5.
A 2016 bug in the SYN path
The bug has been in the kernel since Linux 4.4, which shipped in January 2016. When a SYN arrives carrying IPv4 options (Record Route or Timestamp, the kind of thing nobody has needed since the 90s), the listener stores those options on the connection request. When the handshake completes, the kernel hands the options to the child socket without copying them. If a retransmitted SYN on another CPU builds a SYNACK from those same options while the child socket is being torn down, the destructor frees the memory with a plain kfree() and the SYNACK path reads it after the free.
Eric Dumazet's patch changes two kfree() calls to kfree_rcu(), one in af_inet.c and one in tcp_ipv4.c. That makes the free wait until other CPUs are done reading. The fix landed in stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. IPv6 is not affected because that code path copies the options.
The kernel CVE team published the advisory on October 15 and credited Anthropic researcher Xinyang Ge. A CVSS score of 9.8 was added on October 24. Red Hat scored it 5.9 on its own CVE page, raised that to 8.1 on October 29, then called it Critical in a security bulletin on October 30. The bug did not change during that week. What changed was a blog post.
What Anthropic says its model did
On October 27 Anthropic published a post saying an unreleased internal research model wrote a working exploit for this bug after initial prompting. The target was a Linux server with a Multipath TCP listener. Stage one wins the race so the kernel copies extra bytes into a SYNACK, which leaks a kernel address and defeats KASLR. Anthropic reports 48 minutes for that. Stage two uses the same bug to overflow a buffer and overwrite a callback pointer, redirecting it to a payload already staged in kernel memory. That ran a command as root about five minutes later.
A lost race fails only that one handshake. The server does not crash. So the attacker keeps sending SYNs until it wins.
Anthropic did not publish the exploit, the kernel version, or the configuration it tested. Nobody has reproduced it in public as of October 30. The CVE record and the kernel patch never mention MPTCP; that connection exists only in Anthropic's write-up, and the post doesn't say whether a server without an MPTCP listener can be taken the same way. Red Hat's position is that any exposed TCP service can trigger the race. There are no reports of exploitation in the wild and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.
I don't need the exploit to be verified to take the bug seriously. A remote use-after-free in the handshake path of every Linux server on the internet, with a fix of four lines available since October 5, should have been patched by every distribution before anyone needed to write a blog post about it. The exploit claim is what moved the severity scores. It should not have been what moved the patches.
The MPTCP angle has one practical edge. Go 1.24 and later enable MPTCP on listening sockets by default when the kernel supports it, so a lot of Go services have an MPTCP listener without anyone deciding they should. RHEL and AlmaLinux ship with MPTCP off, so Go services there fall back to plain TCP. The Go Security Team says setting GODEBUG=multipathtcp=0 disables it at runtime and calls that a fragile mitigation, because the underlying bug isn't specific to MPTCP. Check your hosts with ss -H -lMn for MPTCP listeners and sysctl net.mptcp.enabled for the kernel default.
Who shipped and who is still pending
Here is the state as of October 31:
- Debian 13 trixie: fixed October 16 with linux 6.12.113-1 (DSA-6568-1). Debian 12 bookworm: fixed October 17 and October 22 across its two kernel packages.
- Oracle Linux UEK: fixed October 16, ELSA-2026-500397 through 500399.
- Amazon Linux 2 and 2023: patched kernels available in every stream from 4.14 through 6.18, per the AWS bulletin updated October 31. A reboot is required.
- SUSE: fixed for Leap 16.0 and SUSE Linux Micro 6.2. SLES 15 SP7 is still in progress.
- AlmaLinux 8, 9 and 10: patched kernels in the testing repo since October 30, backported from the stable kernels. The ALESCo committee approved shipping ahead of CentOS Stream and RHEL.
- Ubuntu: the CVE tracker shows 22.04, 24.04, 26.04 and 26.10 as work in progress with build numbers assigned but nothing released. 16.04, 18.04 and 20.04 are listed as vulnerable with no version at all.
- RHEL 8, 9 and 10 and OpenShift: affected, no errata, no date. Red Hat says it is expediting fixes. On October 29 its CVE page said fixes were deferred to a future update.
RHEL 7 and CentOS 7 are not affected. That is the one place running an old kernel pays off this month.
AlmaLinux shipping before Red Hat is the detail I keep coming back to. A rebuild project with a volunteer governance committee looked at a patch of two lines sitting in the stable trees since early October, decided its users should not wait for the upstream vendor, and built the kernels. Red Hat, which has had the same stable patch available for the same 26 days, spent the window adjusting a severity score.
Ubuntu is the bigger exposure by host count. Ubuntu runs most of the cloud VMs I see and has nothing released for any LTS. 16.04, 18.04 and 20.04 are on Expanded Security Maintenance, and all three are marked needed with no package in progress.
What to run on the boxes you can't patch
Red Hat published an nftables rule that drops incoming IPv4 TCP packets with IP options, which is the ingredient the race needs:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}Save it as cve-2026-98432.nft, validate it with nft -c -f cve-2026-98432.nft, load it with nft -f cve-2026-98432.nft, and delete the table after you reboot onto a fixed kernel. The rule matches IP header length, so normal TCP options (SACK, window scaling, timestamps in the TCP header) pass untouched. Red Hat says it cannot fully prevent the bug and that it may break workloads that send IP options. I have not seen a workload that does in years. The rule does not survive a reboot unless you persist it. AWS publishes the same filter as an iptables u32 match for hosts without nftables.
Two more checks. Confirm net.ipv4.tcp_migrate_req is 0, since the request migration path is the second way to reach the free. And if you don't need MPTCP, set net.mptcp.enabled=0 and restart anything holding an MPTCP listener. None of these is a fix. All of them cost less than a root shell.
If you're on AWS and someone else runs the host, the bulletin lays out the dates. EKS managed nodes need the October 31 AMI. Fargate tasks launched after 13:00 UTC on November 1 get the patched platform. RDS and Aurora hosts get the OS patch on November 3, with mitigations deployed worldwide in the meantime. Lambda is not affected because functions have no public IPv4 TCP listener. Akamai's Linode advisory, open since October 30, says it is deploying mitigations and tells customers to apply OS updates from their upstream provider. For Ubuntu and RHEL customers, that update does not exist yet.
My bet is that Ubuntu's pending kernels land within the week and Red Hat's errata follow a few days after. The first public reproduction of the exploit will show up before either reaches every box, because the race is retryable and the patch tells you exactly where to look. And the next distro security post mortem worth reading will be about why a stable kernel fix took 26 days to reach enterprise customers.
