CVE-2026-98432 is a critical use-after-free race in Linux’s IPv4 TCP connection-handshake code. It affects kernels from version 4.4 onward and carries a CVSS 3.1 score of 9.8. The reported remote-root demonstration used a server with a Multipath TCP (MPTCP) listener, but the underlying flaw is in IPv4 TCP handling—not exclusively in MPTCP.
6
44
57
The distinction matters: an MPTCP-related mitigation can block the specific route demonstrated in reporting, but it is not a kernel fix. And while researchers reported a remote-code-execution demonstration, the available evidence does not establish that all internet-facing TCP servers are reliably exploitable or that attackers have successfully exploited the flaw in the wild.
37
55
How the race can cause a use-after-free
During connection setup, Linux saves IPv4 options associated with a pending TCP request. When the handshake progresses, tcp_v4_syn_recv_sock() transfers ownership of those options to the new child socket without copying them. A concurrent CPU may still be processing a retransmitted SYN for the same request and reading the options while the connection is being torn down. If the memory is freed before that reader finishes, the retransmission path can access freed memory while building a SYN-ACK.
44
That is the use-after-free: kernel code continues to use memory after its lifetime has ended. The reported consequences include a possible system crash or memory corruption; security advisories also describe potential remote code execution. Whether the bug can be turned into reliable code execution depends on the circumstances—the reported MPTCP demonstration is evidence of a serious exploit path, not proof that every affected host can be compromised the same way.
52
55
The kernel repair addresses the lifetime problem: the IPv4 options are freed only after an RCU grace period, giving concurrent readers time to finish.
44
What the exploit reports do—and do not—show
Anthropic’s October 27 research report was described in subsequent coverage as showing an AI-generated remote-root exploit against a server exposing an MPTCP listener. Reports also say the exploit and its configuration were not released, which limits independent assessment of the demonstration and its prerequisites.
9
11
Matt Corallo criticized Ubuntu’s response as patched kernels became available from some distributions while Ubuntu’s fixes remained in testing. His comments reflect concern about the delay in routine updates; they are not separate technical evidence of exploitation.
12
Security researcher Marcus Hutchins reported apparent scanning for exposed systems. Scanning suggests interest in finding potential targets, but it does not show that any system was successfully compromised.
31
55 The supplied sources do not independently verify the circulating estimate of roughly 2.1 million MPTCP-reachable servers, so it should not be treated as an established count of vulnerable or exploitable hosts.
Why disabling MPTCP is only an interim mitigation
Go 1.24 and later can enable MPTCP for listeners when the kernel supports it. That can make an application’s networking behavior relevant even if the application was not written specifically to use MPTCP.
37
Lightning Labs’ release information for LND advises Linux operators to disable MPTCP and install a patched kernel. The lnd v0.21.6-beta release says it disables MPTCP listeners by default, closing the demonstrated route through that application. The release also makes clear that this is a mitigation, not a replacement for the kernel patch.
33
37
Disabling MPTCP at the application level can reduce that application’s exposure; disabling it host-wide can affect other MPTCP listeners too. Neither change fixes the underlying IPv4 TCP memory-lifetime bug. Treat these measures as ways to reduce exposure while arranging the kernel update—not as evidence that an unpatched kernel is safe.
6
37
44
Patch status in the reports available as of November 4
Patch availability varied by distribution. Canonical said on November 2 that fixes for Ubuntu 22.04 LTS and newer were in the opt-in -proposed pocket while testing continued. The company’s statement described this as part of its validation process; contemporaneous coverage reported that Red Hat had shipped patched kernels for RHEL 8, 9 and 10 on November 1.
6
7
That gap between a fix being available for testing and reaching the normal update channel drove criticism, particularly after the reported remote-root demonstration. The concern is understandable, but patch-status reports are time-sensitive: check the security advisory for your specific distribution and release rather than assuming another distribution’s update applies to your system.
7
12
For operators, the priority is to verify the kernel actually running each workload and install the distribution’s fixed kernel when available. MPTCP restrictions may reduce exposure in the meantime, but only the kernel update addresses the vulnerable memory-handling behavior.
6
37
44