I’ve been running Debian servers in production for years. Every time a kernel CVE comes out, I stop to read the details. Then I decide whether to patch right away or wait. This time the story is more tangled than usual: there’s a Linux kernel vulnerability in TCP IPv4, a CVSS score that vendors can’t agree on, and even a reported root exploit built by an AI model. Let’s start with a question that looks like a side note, but isn’t: what is MPTCP, and why does it matter even if you don’t use it.
What MPTCP is, and why it matters even if you don’t use it
Multipath TCP (MPTCP) is the RFC 8684 standard. It extends classic TCP so a single connection can travel over several network paths at once. A phone can use WiFi and mobile data at the same time, for the same connection. A server with several interfaces can do the same, for redundancy or for combined bandwidth. Apple has used it in production since iOS 7, back in 2013, for Siri: it’s the best-known real-world case. Some mobile carriers, for example in South Korea, use it for WiFi/LTE bonding. Several data centres adopt it for multi-homing across different uplinks. It’s been in the mainline Linux kernel since 5.6.
The point that made me raise an eyebrow is a different one. From version 1.24 onwards, programs written in Go require MPTCP by default for listening sockets. The Go Security Team confirmed this on 29 October. Along with it, they gave an uncomfortable warning: the bug we’re talking about today isn’t MPTCP-specific. A system with no active MPTCP listeners can still be exposed to similar attacks. The vulnerable code sits in the generic IPv4 TCP path, not in an optional module. You can disable MPTCP per program, with the GODEBUG=multipathtcp=0 runtime variable. But the Go Security Team calls this mitigation “fragile”: a single MPTCP listener left exposed is enough to undo it. Nobody has shown that every working exploit actually depends on MPTCP. That’s why the MPTCP code stays an attack surface, even if you never consciously enable it in your stack: it just needs to be compiled into the kernel and reachable.
The MPTCP project itself states, on its own page, that the main current Linux distributions ship the kernel with MPTCP support compiled in by default (CONFIG_MPTCP=y). It explicitly names Debian, Ubuntu, RHEL and Fedora. That’s a statement from the project itself, not an independent distro-by-distro check, but the underlying point still holds: support is switched on at the kernel level, not “opt-in” at the operating system level. Only the per-connection negotiation is left to the application.
CVE-2026-98432, the Linux kernel vulnerability, in brief
The Linux kernel CVE team published CVE-2026-98432 on 15 October 2026. The upstream fix had already landed ten days earlier, on 5 October. It often happens that publication lags behind the commit. The CVSS score of 9.8 (critical) only arrived on 24 October, nine days after the CVE was published.
The problem lies in TCP handshake handling for IPv4, specifically in the tcp_v4_syn_recv_sock() function. When a connection is created, the IP options from the SYN packet are passed from the pending request socket to the new socket. For example Record Route or Timestamp, if the client includes them in a crafted SYN. The problem is that they’re passed by reference, not by copy, and without the listener’s lock. According to the technical analysis of the patch, the structures involved are called inet_opt and ireq_opt. A second CPU can free that buffer with kfree(), called from inet_sock_destruct() or from tcp_v4_reqsk_destructor(). Meanwhile a first CPU is still reading it in ip_options_build(), to build the SYNACK. It’s a classic use-after-free caused by a race condition. The equivalent IPv6 path, tcp_v6_syn_recv_sock(), copies the options instead of passing them by reference: it isn’t vulnerable to the main race. There’s also a second attack route, through request-socket migration: net.ipv4.tcp_migrate_req=1 or an eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. Both are disabled by default.
The bug is remote and needs no authentication or user interaction, according to the kernel team’s assessment. It’s been present since kernel version 4.4. The fix is signed off by Eric Dumazet, reported by Xinyang Ge of Anthropic. It moves the memory release to after an RCU grace period, with kfree_rcu(): that way no CPU can read a buffer that’s already been freed. The fixed stable versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and mainline from 7.3-rc7.
Conflicting CVSS scores: not every vendor agrees
Here’s where the story gets complicated. The kernel CVE team and Ubuntu rate attack complexity as low, and give it 9.8 (critical). Oracle and SUSE instead give 8.1 (important): same CVSS vector, but high attack complexity. Red Hat, oddly, has two assessments that don’t match each other. The public CVE page shows “Moderate, 5.9”. The machine-readable advisory file, updated on 29 October, shows instead “Important, 8.1”, with high impact on confidentiality and integrity. The same day, Red Hat’s internal bug tracker raised the severity from medium to high. Amazon, for its part, assigns 7.0. At the time of writing, the NVD hasn’t yet published a score of its own.
It’s worth saying this plainly. This internal inconsistency at Red Hat isn’t a detail I worked out myself: it’s reported that way by the original article from The Hacker News, my main source for this data. It’s not the first time a vendor has published two different numbers for the same bug, on different channels. But here the jump from “moderate” to “important” on the same day says a lot. Even for the people who write the code, reliably estimating the real exploitability of a kernel race condition is hard.
Patch status: Debian already fixed, others not yet
This is the point that affects me most directly: the hosting servers I manage run Debian stable. And here the facts speak for themselves, no need to add emphasis: Debian has already fixed this Linux kernel vulnerability, on both trixie and bookworm. Debian trixie (stable) was fixed on 16 October 2026, with package linux 6.12.113-1, advisory DSA-6568-1. Debian 12 (bookworm) was fixed in two steps: on 17 and 22 October 2026, with linux 6.1.190-1 (advisory DLA-4841-1) and linux-6.12 6.12.113-1~deb12u1 (advisory DLA-4850-1). In its own tracking table, Debian doesn’t list a separate CVSS score for this CVE. It simply marks the fix status for each release: that’s the information that actually matters, for anyone deciding whether to reboot a server.
Comparing this with the status of other widely used distributions helps put it in perspective. As of 30 October, Red Hat has updated the status for RHEL 8, 9, 10 and OpenShift 4. It used to be “fix deferred” (marked on 29 October), now it’s “affected”. No release date has been given. Ubuntu, across all supported versions (22.04, 24.04, 26.04, 26.10), is still listed as “in progress”, with no date. Ubuntu 16.04, 18.04 and 20.04 are listed as vulnerable, with no fix listed at all. SUSE Linux Enterprise Server, from SP4 through SP7 plus 16.0, is in the same situation. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 and Amazon Linux 2023 are, instead, already fixed. RHEL 7 isn’t affected: the vulnerable code path was never shipped on that release.
I’m not saying this to score points against Ubuntu or RHEL. They remain serious distributions, with solid security processes. I’m saying it because, on this specific bug, in this time window, the facts are these: anyone relying on hosting built on Debian stable already has the fix installed. On other very widely used distributions, the server stays exposed for an indefinite period. It’s a concrete, verifiable advantage, just by looking at the dates. It isn’t an opinion about the Debian project in general.
Anthropic’s exploit (reported, not independently verified)
The most unusual part of this story involves Anthropic, the company that first reported the bug through Xinyang Ge. According to industry reports, one of its internal AI models, not released publicly, built a working root exploit entirely on its own. Starting from nothing but the patch and the report as a prompt. The two-stage attack reportedly works like this. In the first stage, the race makes the kernel’s response leak extra bytes to the attacker. From there the attacker recovers a kernel address, defeating KASLR. In the second stage, the same bug reportedly causes a buffer overflow. It overwrites a callback pointer with the address of a payload the attacker has already placed in kernel memory. When the kernel calls that pointer, the payload runs an arbitrary shell command as root. A lost race would only fail that single connection attempt, without crashing the system: so repeated attempts would be possible. In the test described by Anthropic: 48 minutes to steal the kernel address, another 5 minutes to reach command execution.
Red Hat says a remote attacker reaching an exposed TCP service can generally trigger the race. The root exploit described by Anthropic, though, reportedly targeted specifically servers with an active multipath TCP listener. Anthropic’s post doesn’t clarify whether a server without MPTCP is exploitable in the same way. Neither the CVE record nor the upstream fix mention MPTCP anywhere. It’s trade press, not a primary source, reporting this link: so I’m writing it with the scepticism it deserves, not as a hundred-percent established fact. Anthropic hasn’t published the exploit code, the exact kernel version used, or the target server’s configuration. Another company, Innora, has published a root-cause analysis, with a QEMU reproduction environment. It stated it won’t release a weaponised exploit in the short term. At the moment there’s no evidence of real-world exploitation by vendors or CERTs. The bug isn’t in the CISA KEV catalogue, according to the copy maintained by Luxembourg’s CIRCL, updated as of 28 October.
What to do on your servers right now
No vendor has published an officially sanctioned workaround for this Linux kernel vulnerability. Red Hat states explicitly that none of the measures circulating so far meet its standard for ease of deployment and stability. The primary mitigation remains applying the fixed kernel and rebooting, once the patch is available for your distribution. On Debian it already is. On RHEL and Ubuntu, not yet, at the time of writing.
As defence in depth, not as a definitive fix, a few things are worth doing. Check that net.ipv4.tcp_migrate_req is set to 0. Check that no BPF_SK_REUSEPORT_SELECT_OR_MIGRATE eBPF programs are loaded. Consider filtering incoming IPv4 packets that carry Record Route or Timestamp options. Monitor for any crashes mentioning ip_options_build, ip_build_and_send_pkt or skb_under_panic. Take stock of any exposed MPTCP listeners, and avoid leaving them reachable without a reason. If you also manage defences against more common application-level attacks, how I protected my servers while waiting for the PHP2Shell patch takes the same approach: mitigate what you can while waiting for the definitive fix, without promising protections that don’t exist.
For anyone asking me whether to patch now: if you run Debian stable, the fixed kernel is already in the security repositories. The update is straightforward, and the exposure window is already closed. If you run other distributions, there’s no patch to install yet today. It’s worth following your vendor’s advisories closely over the coming days: the situation is changing quickly.
Sources: The Hacker News, the Debian Security Tracker and the fix commit. Debian, Red Hat, Ubuntu and the other names mentioned are trademarks of their respective owners.
Leave a Reply