A use-after-free in the Linux kernel’s IPv4 TCP handshake (CVE-2026-98432, CVSS 9.8) was fixed upstream in October and is still landing in distribution kernels. What we found: any unauthenticated peer can reach it on any IPv4 TCP port; the working root exploit has been described but not published; and the setup it needs is more common than it looks, because Go programs open multipath TCP listeners by default.

TL;DR

On 15 October 2026 the Linux kernel CNA published CVE-2026-98432 with a CVSS 3.1 score of 9.8. The bug has been in the kernel since Linux 4.4. On 27 October, Anthropic, whose researcher Xinyang Ge reported it, said its Claude model wrote a remote root exploit for it. This post follows our initial assessment on the Upwind feed and on X.

• The bug is in the kernel, not in any application. It runs when the kernel accepts an IPv4 TCP connection, before any application sees it. A new application or container image changes nothing.
• A remote root exploit exists, but only in Anthropic’s lab. No code was published, no in-the-wild exploitation has been reported, and the CVE is not in CISA’s KEV catalog.
• The setup that exploit needs is common. Since Go 1.24, Go programs open multipath TCP (MPTCP) listeners by default on Linux.
• The gap is in distribution kernels. Red Hat shipped fixed RHEL kernels on 1 November. Ubuntu still has none.
• Patching means rebooting. A kernel update does nothing until the host boots into it.

Fixed upstream kernels: 7.3, 7.2.10, 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223 and 5.10.272. Lines 4.4 to 5.4 are end-of-life upstream and depend on distribution kernels.

What is CVE-2026-98432?

In one sentence: the kernel freed a connection’s IPv4 options while another CPU was still reading them to answer the handshake.

When a client’s SYN carries IPv4 options, such as Record Route or Timestamp, the kernel saves them to echo in its replies. When the handshake completes, the kernel handed those saved options to the new connection without copying them. When that connection went away, the kernel freed them immediately. Another CPU, handling a retransmitted SYN for the same connection, could still be reading them. That is a use-after-free.

The fix, titled “ipv4: free inet_opt and ireq_opt after an RCU grace period”, changes two kfree() calls to kfree_rcu(). The memory is now freed only after every reader has finished. Two missing lines, in code that runs on every IPv4 connection, for about ten years.

The kernel CNA lists three possible outcomes: kernel memory leaked to the remote peer, memory corruption, or a crash. All of it happens before authentication.

Does a public exploit work?

No public root exploit has been confirmed. What exists is Anthropic’s description of one.

According to Anthropic, Claude’s exploit runs commands as root on servers with an MPTCP listener, with no credentials and no user interaction. In its proof of concept, leaking a kernel pointer took 48 minutes and command execution took five more. A lost race only fails the handshake, so an attacker can keep retrying without crashing the host.

Anthropic did not publish the code, the kernel version, the test setup, or why MPTCP is needed. Several GitHub repositories claim race triggers or proofs of concept, and none is confirmed to reach code execution.

Who is affected?

Nearly every Linux server running a kernel from 4.4 onward without the fix.

• Internet-facing hosts with an MPTCP listener: patch first. They match the setup of Anthropic’s exploit.
• Any host accepting IPv4 TCP connections: web, SSH, databases and load balancers are all reachable by a single SYN.
• Kubernetes nodes and container hosts: containers share the host kernel. Only a fixed node kernel and a reboot help.
• IPv6-only traffic: not affected by the main issue, though a related IPv6 case is still waiting for its own patch.

The Go Security Team adds an important caveat: the bug is not specific to MPTCP, and systems without an MPTCP listener may be vulnerable to similar attacks.

Is there a fixed kernel for my distribution?

• Fixed: Debian 12 and 13, RHEL 8, 9 and 10 (since 1 Nov), SUSE SLES 16.0 and 15 SP4 to SP6 LTSS, openSUSE Leap 16.0, Oracle Linux 7 to 10 UEK, Amazon Linux 2 and 2023.
• In testing: AlmaLinux 8, 9 and 10.
• Not fixed: all Ubuntu releases, and OpenShift’s RHEL CoreOS as of 1 Nov.

How can exploitation be detected?

The trigger is hard to see. It lives inside the kernel’s handshake handling, and a lost race looks like a failed connection. Watch instead for:

• Inbound SYNs carrying IPv4 options. Legitimate TCP traffic almost never has them, so they signal probing.
• Bursts of such SYNs from one source with many failed handshakes. Consistent with someone retrying the race.
• Kernel warnings, oopses or panics in TCP code. The race was hit and memory was corrupted.
• Unexpected root processes on internet-facing hosts with no login session or service behind them. The strongest sign of successful exploitation.

What should security teams do now?

• Check the running kernel on every host and node, not inside containers, and compare it with your vendor’s tracker. If the installed kernel is newer than the running one, you still need to reboot.
• Find MPTCP listeners and patch those hosts first. Running ss -Mlnp lists them.
• Patch and reboot. It is the only complete fix.
• Until you can patch, drop IPv4 TCP packets that carry IP options. Red Hat and AlmaLinux publish nftables rules for this. Red Hat notes the filter reduces exposure but cannot fully prevent exploitation, and traffic between containers on the same host may bypass it.
• Turn off MPTCP where you don’t use it, by setting net.mptcp.enabled to 0. It is set per network namespace, so containers need it too. For Go programs, GODEBUG=multipathtcp=0 disables the default.
• Don’t forget OpenShift nodes and appliances that bundle their own kernel.

How can Upwind help?

This CVE is a fleet problem, not an application problem. What decides your risk is which hosts and nodes run which kernel, which face the internet, and which still need a reboot. Upwind’s sensor inventories hosts and Kubernetes nodes with their kernel packages and known CVEs, and maps internet exposure, so you can patch the reachable hosts first.

Because the trigger is nearly invisible, the reliable signal is what runs afterward. Upwind watches process execution and lineage at runtime, including unexpected root processes that no service or login explains.

To learn more about how Upwind finds exposed Linux hosts and detects post-exploitation activity at runtime, schedule a demo