A CVSS 9.8 use-after-free in the Linux kernel's IPv4 TCP handshake. Anthropic's Claude built a remote root exploit over MPTCP, but any IPv4 TCP listener is in scope.
CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. Anthropic says its Claude model wrote a remote, unauthenticated root exploit for it against servers with a Multipath TCP (MPTCP) listener. Any Linux server that accepts IPv4 TCP connections should be treated as in scope. The bug is not MPTCP-specific, and MPTCP is only the route Anthropic demonstrated. We found no report of exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalogue (catalogue version 2026.11.04).
What happened
The CVE was published on 15 October 2026. The Linux kernel CNA scores it 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). SUSE scores it 8.1 because it rates attack complexity High, and rates it important. Red Hat rates it Critical for RHEL and Ubuntu rates it Critical. NVD still shows the record as "Received".
On 27 October Anthropic published a write-up of an exploit Claude produced. It has two stages. First, a race makes the kernel copy extra bytes back to the attacker, and a kernel pointer in that reply defeats KASLR. Anthropic reports about 48 minutes for this leak. Second, the same bug overflows a buffer to overwrite a callback pointer, which redirects execution to a payload staged in kernel memory and runs an attacker-chosen shell command as root. That took about five more minutes. A lost race only fails the handshake and does not crash the machine, so an attacker can retry.
ThreatDefence reports partial public PoC code on GitHub since 29 October, covering the race, pointer leak, KASLR recovery and a KASAN reproduction. It says no public code reaches code execution, that CloudLinux could not reproduce execution, and that Anthropic has not published its full chain. These are secondary claims. It also relays reports of internet-wide scanning for MPTCP listeners since 2 November. Treat PoC repositories as untrusted.
From publication to reported scanning in under three weeks.
Technical detail
When a TCP child socket is created from a request socket, the IP options pointer (ireq->ireq_opt) is moved without being copied. A retransmitted SYN on another CPU can still read those options while building a SYN-ACK. If they are freed first, ip_options_build() reads freed memory. The same problem affects request socket migration, enabled by net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. The fix switches the frees in inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu(). The flaw dates to commit 079096f103fa and has been present since Linux 4.4. IPv6 is not affected by this first issue. A related IPv6 migration issue will get a separate patch.
The oss-security thread states the bug is not specific to MPTCP. Go matters here: since Go 1.24, Go programs enable MPTCP by default on Linux listening sockets, so a Go service may expose an MPTCP listener without the operator choosing it.
Fixed versions
The CVE record lists these stable fixes: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, with mainline 7.3. The record is the kernel CNA's data as shown by NVD. We could not open the kernel mailing list announcement, so the per-branch numbers rest on that record. Debian's tracker independently shows 6.1.190-1, 6.12.113-1~deb12u1 and 7.2.10-1 in its fix data, and puts the upstream fix in 7.3-rc7. Check your distribution's own tracker, because vendors backport fixes without changing the upstream version.
Distribution packages we confirmed:
- Debian: bookworm 6.1.190-1; trixie 6.12.115-2 per the tracker status table; forky 7.2.12-1.
- SUSE: SLES 15 SP7
kernel-default6.4.0-150700.53.90.1 or later; SLES 16.0 6.12.0-160000.40.1 or later. - RHEL family (as listed by SUSE Liberty Linux): el8_10 4.18.0-553.182.1, el9_8 5.14.0-687.64.1. Red Hat's CVE page points to bulletin RHSB-2026-016.
- Ubuntu: fixes are still marked work in progress on its tracker (24.04 6.8.0-149.149, 22.04 5.15.0-203.213). 20.04 and older are listed as vulnerable.
A fixed package does not protect a host until the fixed kernel is booted.
What defenders should do
- Patch and reboot. Prioritise internet-facing hosts.
- Check exposure:
uname -r # running kernel
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -Mlnp # MPTCP listeners and owning processes
ss -ltn4 # all IPv4 TCP listeners
- If no fixed kernel is available, reduce exposure. None of these fixes the bug.
- Disable MPTCP with
sysctl -w net.mptcp.enabled=0and persist it in/etc/sysctl.d/. It affects new sockets only, so restart services that hold MPTCP listeners and confirm withss -Mlnp. It is per network namespace, so containers need separate handling. For Go services setGODEBUG=multipathtcp=0. The Go Security Team calls this fragile, because one forgotten listener leaves you exposed and it assumes every exploit needs MPTCP. - Drop inbound IPv4 TCP packets that carry IP options (header length above 5 words) with nftables, at the host and at the perimeter. Test first, since some workloads use IP options, and note that Kubernetes pod traffic can bypass the input hook. Ubuntu's page describes this as reducing risk without preventing exploitation.
- Keep
net.ipv4.tcp_migrate_reqat 0 and inventory BPF reuseport migrate programs.
- Disable MPTCP with
- Hunt from 15 October. ThreatDefence suggests looking for inbound SYNs with Record Route or Timestamp options, SYN-ACKs carrying IP options leaving your hosts, kernel log lines naming
ip_options_build, and unexplained host reboots. If you find an attempt, preserve evidence before rebooting.