Linux: an MPTCP flaw could hand over root to remote attackers

Bleeping Computer reported on 30 October 2026 a critical Linux kernel flaw, CVE-2026-98432, in the IPv4 TCP networking code. It’s a use-after-free, meaning the kernel keeps using memory it has already given back, and the Linux kernel CVE team rates it 9.8 out of 10. We only have this one source, which relays vendor advisories, so the more sensitive claims below are reported, not confirmed.

Two CPU cores, one race, no winner

The bug reportedly comes from a race condition in how TCP connection requests are handled. When the kernel hands a request’s IP options over to the child socket without copying them, another core can, at the very same moment, process a retransmitted SYN for the same request and read those options again. A similar scenario exists when TCP requests are migrated, if net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in use.

No authentication is required. Anthropic researchers say an unreleased Claude model built an exploit that bypasses KASLR (kernel address space layout randomisation) and runs commands as root on a server with an MPTCP listener, in roughly 53 minutes. Red Hat, for its part, files the flaw under denial of service with a score of 5.9, since exploiting it takes more than firing off a single malicious packet. Anthropic’s demonstration shows it can go well beyond knocking the kernel over.

Who is exposed

Kernels from version 4.4 onwards are reportedly affected, including those shipped by Ubuntu, Red Hat Enterprise Linux and Rocky Linux. RHEL 7 is spared because its kernel doesn’t contain the vulnerable code, and so is macOS, which runs on Apple’s XNU kernel.

The code execution scenario targets servers exposing an MPTCP listener. Multipath TCP lets a single connection travel over several network paths at once, typically Wi-Fi and cellular. The flaw also affects ordinary TCP connections, although no remote code execution has been publicly demonstrated without an MPTCP listener.

Checking whether MPTCP is running behind your back

MPTCP generally isn’t switched on by default in applications, but some turn it on all by themselves. The one to watch is Go: since Go 1.24, the language enables MPTCP by default for TCP listeners on Linux, as long as the kernel supports it.

In practice, list the network services exposed on your servers and pick out the ones built with Go 1.24 or later: those are your prime suspects. Also check whether net.ipv4.tcp_migrate_req is enabled or whether any BPF socket migration programs are loaded. And don’t breathe a sigh of relief too soon: without MPTCP, the demonstrated risk drops, but the flaw is still there.

Fixes, as of 30 October

The fix has landed in the upstream Linux kernel and been backported to the maintained branches. Distributions are following at their own pace, which is to say not all at once:

• Debian: fixed in 6.1.190-1 for Debian 12 (Bookworm) and 6.12.113-1 for Debian 13 (Trixie), as well as in testing and unstable;
• Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 still vulnerable, fixes in progress according to Canonical’s tracker;
• RHEL: versions 8, 9 and 10 affected, fixes planned in upcoming updates;
• Rocky Linux: versions 8, 9 and 10 affected, according to CIQ;
• Oracle Linux, Amazon Linux, SUSE: fixes released for some of the affected kernels.

Install the updated kernel as soon as your distribution ships it. Until then, restrict access to your services to trusted networks or IP addresses. CIQ also recommends temporarily dropping IPv4 TCP packets that carry IP options before they reach the vulnerable code, and has shared temporary firewall protections to do just that.

Installing the patch is the easy bit. Working out which of your services quietly opted into MPTCP without asking anyone may take you rather longer.