VULNpocalypse
CriticalVulnerabilityPatch available

Linux kernel CVE-2026-98432: IPv4 TCP handshake use-after-free, with an AI-built remote root exploit

A race in Linux’s IPv4 TCP handshake, present since 4.4, allows remote code execution. Install a fixed kernel or drop IPv4 packets carrying IP options.

Published
Updated
Fixed in
Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3; Debian, Oracle UEK, SUSE Micro 6.2, openSUSE Leap 16.0 and Amazon Linux 2023 kernels; Ubuntu and RHEL pending as of 30 October
Exploitation
No exploitation in the wild reported as of 30 October 2026; not in CISA KEV; Anthropic built a working exploit but did not publish it

Live scores

CVE-2026-98432
EPSS
0.005
low predicted chance of attack
VEDAS
0.969
strong exploit evidence
On CISA KEV
Not listed
Detection rule
None yet

What happened

CVE-2026-98432 is a use-after-free in the kernel’s IPv4 TCP connection setup. tcp_v4_syn_recv_sock() hands the request socket’s IP options (ireq_opt) to the new child socket without copying them. Another CPU can still be reading those options to answer a retransmitted SYN, and the child socket can be freed in the meantime. A similar race exists during request socket migration. The bug has been there since Linux 4.4. IPv6 is not affected by the main issue, because it copies the options (CVE record).

The fix was applied upstream on 5 October and the CVE published on 15 October. Anthropic researcher Xinyang Ge reported it (The Hacker News). The kernel CNA scores it CVSS 9.8: network, no privileges, no user interaction (CVE record).

On 27 October, Anthropic described how an unreleased internal Claude model built a working exploit. The first stage abuses the race to make the kernel send back extra bytes, leaking a kernel pointer and defeating KASLR. The second overwrites a callback pointer and runs a shell command as root. In its test it took about 48 minutes to leak the address and about five more to get command execution, against a server with a multipath TCP (MPTCP) listener. A lost race only fails one handshake, so the attacker can keep retrying (Anthropic). Anthropic did not publish the exploit, the kernel version or the configuration it used (The Hacker News).

MPTCP is not the root cause. The CVE and the kernel fix do not mention MPTCP. Go’s security team says the bug is not MPTCP-specific and calls disabling MPTCP a fragile mitigation (The Hacker News). CIQ also says disabling MPTCP alone is insufficient. Remote root has not been shown publicly on a server without an MPTCP listener, but ordinary TCP traffic can trigger the flaw (BleepingComputer). Go 1.24 and later enable MPTCP on Linux listeners by default, so many Go services have MPTCP listeners without anyone choosing it.

Ratings differ. Red Hat first rated the flaw Moderate (5.9) because winning the race is hard (BleepingComputer). On 30 October it published bulletin RHSB-2026-016, rated the flaw Critical and said it is “expediting the release of fixes” (Red Hat RHSB-2026-016; Red Hat CVE page). Amazon rates it 7.0 (The Hacker News).

No exploitation in the wild had been reported as of 30 October (BleepingComputer). The CVE was not in CISA’s KEV catalog as of that date (CISA KEV).

Am I affected?

Every Linux kernel from 4.4 onward without the fix is affected, on any system that accepts inbound IPv4 TCP connections. Distribution status as of 29 to 30 October (The Hacker News; BleepingComputer):

  • Fixed: Debian 13 (linux 6.12.113-1) and Debian 12 (linux 6.1.190-1 or 6.12.113-1~deb12u1); Oracle Linux 7 to 10 UEK; SUSE Linux Micro 6.2 and openSUSE Leap 16.0 (kernel-default 6.12.0-160000.40.1 or later); Amazon Linux 2023 kernel6.18 (6.18.56-125.164.amzn2023) and kernel6.12 (6.12.113-138.209.amzn2023).
  • Not yet fixed: Ubuntu 22.04, 24.04, 26.04 and 26.10 (in progress); RHEL 8, 9 and 10, OpenShift 4 and Rocky Linux 8 to 10; SLES 15 SP7; Amazon Linux 2 and the default AL2023 kernel package. RHEL 7 is not affected.
bash
# Running kernel; compare with your distribution's advisory
uname -r

# Is MPTCP enabled, and is anything listening with it?
sysctl net.mptcp.enabled
ss -Mltn

An MPTCP listener matches the exploited setup, but servers without one are still affected.

What to do now

  1. Install a fixed kernel and reboot. Use your distribution’s patched build or an upstream stable release from the list above. The kernel CVE team recommends the latest stable kernel rather than cherry-picking the fix (The Hacker News). Rebuild node images and VM templates so new instances do not boot the old kernel.
  2. Where no fix exists yet, drop inbound IPv4 TCP packets with IP options. Red Hat publishes this nftables rule. Normal TCP options sit in the TCP header and are not affected. Test it first, since it can break workloads that rely on IP options (Red Hat RHSB-2026-016):
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Load it with sudo nft --check --file cve-2026-98432.nft, then sudo nft --file cve-2026-98432.nft, and confirm with sudo nft list table inet cve_2026_98432. Remove it after the kernel update with sudo nft delete table inet cve_2026_98432. The packet counter also shows whether anyone is sending such packets.

  1. Disabling MPTCP in Go services is a partial measure only. Setting GODEBUG=multipathtcp=0, or godebug multipathtcp=0 in go.mod, turns it off unless the code calls SetMultipathTCP (The Hacker News). Use it only alongside the filter or the patch.
  2. Patch internet-facing hosts first: load balancers, reverse proxies, Kubernetes nodes with public services and anything else taking inbound TCP from untrusted networks. Where neither patch nor filter is possible, limit inbound access to trusted addresses.

Sources