A critical flaw in the Linux kernel's networking code can let an attacker run commands as root on a server without logging in, and the patch has not yet reached every major distribution. The bug is tracked as CVE-2026-98432, and Anthropic's security researchers used an unreleased Claude model to build a working remote exploit for it, as Anthropic describes in its report and BleepingComputer reported on 30 October.
BleepingComputer describes CVE-2026-98432 as a use-after-free vulnerability in the kernel's IPv4 TCP code, caused by a race condition in how the kernel handles incoming connection requests. The Linux kernel CVE team gave it a severity score of 9.8 out of 10, according to the outlet, and it affects kernels going back to version 4.4.
The Linux kernel advisory, as quoted by BleepingComputer, explains the mechanism: tcp_v4_syn_recv_sock() hands a request's IP options to the new child socket "without copying it", while another CPU can be processing a retransmitted SYN for the same request at the same moment.
The headline case involves Multipath TCP (MPTCP), a feature that lets one connection use several network paths at once, such as Wi-Fi and cellular together. BleepingComputer notes the flaw also affects ordinary TCP connections, but remote code execution has not been publicly demonstrated on servers without an MPTCP listener.
Two very different severity ratings
BleepingComputer reports that Red Hat classifies it as a potential denial-of-service issue that could crash the kernel, and scores it 5.9 because exploiting the race is more complex than sending one malicious packet.
In a post dated 27 October, Anthropic says an "unreleased, internal research model" wrote an exploit that lets a remote attacker run arbitrary commands as root on Linux servers with a multipath TCP listener, "without any credentials or user interaction". The exploit first uses the race to leak a kernel pointer, defeating kernel address space layout randomisation (KASLR), then overwrites a callback pointer so the kernel runs a payload already staged in memory.
The detail that matters most is in one sentence of Anthropic's post: a lost race "only fails the handshake without crashing the whole system", so an attacker can keep retrying. In Anthropic's proof of concept, leaking the kernel pointer took 48 minutes and reaching command execution took about five more: about 53 minutes in total. Anthropic says the bug was patched upstream and backported to all maintained stable kernel branches.
Where the patches are
Upstream being fixed is not the same as your server being fixed. As of 30 October, BleepingComputer reports:
- Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 remain vulnerable, with kernel fixes in progress, according to Canonical's tracker.
- Red Hat: RHEL 8, 9 and 10 are affected, with fixes planned; RHEL 7 is not affected.
- Rocky Linux: 8, 9 and 10 are affected, per support provider CIQ.
- Debian: fixed in kernel 6.1.190-1 for Debian 12 and 6.12.113-1 for Debian 13.
- Others: Oracle Linux, Amazon Linux and SUSE have released fixes for some affected kernels.
BleepingComputer says there are no confirmed reports of the flaw being exploited in the wild.
What administrators can do now
BleepingComputer advises installing updated kernel packages as each distribution ships them, and restricting access to trusted networks or IP addresses where patches are not yet available. According to the outlet, CIQ also recommends temporarily blocking IPv4 TCP packets that carry IP options, and has published example nftables rules. One trap: CIQ cautions that disabling MPTCP alone is not enough, because the bug can still be triggered through ordinary TCP traffic.
It is also worth checking whether you run MPTCP at all without knowing it. BleepingComputer reports that "beginning in Go 1.24, the programming language enables MPTCP by default for TCP listeners on Linux as long as the kernel supports the feature", so some Go-based services may enable MPTCP listeners without administrators knowing.
Cole's take: The two severity scores aren't really a disagreement about the bug. They reflect two different assumptions about how hard a race condition is to win. A race that fails quietly and can be retried for as long as it takes doesn't stay hard for long. If you run Linux servers, I'd treat this as the higher number until your distribution's update is installed.
Reporting notes