Claude Built a Remote Root Exploit for a Linux TCP Bug. Ubuntu Still Has No Fix

Update, November 2, 2026: Red Hat released fixed kernels for RHEL 8, 9 and 10 on November 1 and now rates the flaw Critical, 9.8. AlmaLinux 8 and CloudLinux 8 also have fixes, and Red Hat has published a packet-filter mitigation. Ubuntu’s fix is still pending. The status table below reflects November 2.

A use-after-free bug in the Linux kernel’s IPv4 TCP code, CVE-2026-98432, can be triggered by an unauthenticated sender during the TCP handshake. In an October 27 post, Anthropic’s Frontier Red Team describes an exploit, written by an unreleased Claude research model, that runs commands as root on Linux servers with a multipath TCP listener. Upstream stable kernels with the fix were available when the CVE was published on October 15, but distributions ship the fix at different speeds. As of November 2, Debian, Red Hat and Oracle Linux have fixed kernels, as do AlmaLinux 8 and CloudLinux 8, while Ubuntu’s LTS releases do not.

Among the operating systems cPanel supports, AlmaLinux 9 and 10, CloudLinux 9 and 10 and Ubuntu still have no fixed kernel in production. Anthropic’s root exploit requires an exposed MPTCP listener, although the underlying flaw is not limited to MPTCP. Ubuntu gives no release date for its fix.

Key facts

• The bug: a race in IPv4 TCP connection handling, present since Linux 4.4 and fixed upstream on October 5. IPv6 is not affected by the main race.
• The exploit: Anthropic reports root command execution after 53 minutes in its proof of concept. Anthropic has not published the exploit code.
• The scores: the kernel CVE team and Red Hat rate the flaw 9.8, SUSE 8.1. The only difference is attack complexity.
• Go programs: since Go 1.24 they listen with multipath TCP by default. The Go Security Team calls turning it off a fragile mitigation.

A Race Inside the TCP Handshake

The flaw sits in the code that turns a pending connection request into a new socket. According to the CVE record, the kernel hands the IPv4 options stored with the request to the new socket without copying them. If a retransmitted request for the same connection arrives at that moment, another CPU can still be reading those options to build its reply when the socket is freed. The kernel then uses memory it has already released. A similar race exists when pending requests are migrated between listening sockets. IPv6 connections are not affected by the main race, because the kernel copies the options there.

Eric Dumazet authored the fix on October 1, and it was applied on October 5. The commit credits Anthropic researcher Xinyang Ge with reporting the bug, which dates back to Linux 4.4. The fix makes the kernel free the options only after other CPUs have finished reading them. The kernel CVE team published the CVE on October 15, initially listing fixes in 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. The updated record also lists fixes for the older stable branches, 5.10.272, 5.15.223, 6.1.190 and 6.6.159, and the fix is included in Linux 7.3.

Anthropic’s Exploit Needs a Multipath TCP Listener

Anthropic’s post lays out two stages. The attacker first uses the race to make the kernel leak a memory address in its replies, which defeats KASLR address randomization. The same bug is then used to overwrite a callback pointer, so that the kernel ends up running a shell command as root. A lost race only fails the handshake rather than crashing the system, so the attacker can keep retrying. In the proof of concept, leaking a kernel pointer took 48 minutes, and reaching command execution another five. According to the post, Claude produced the exploit “after initial prompting.” The post does not publish the exploit code. The flaw was not in CISA’s Known Exploited Vulnerabilities catalog as of the catalog’s October 30 update.

Multipath TCP, or MPTCP, lets one connection use several network paths. Since Go 1.24, programs written in Go enable it by default for the sockets they listen on, according to Go’s documentation. In its October 29 announcement, the Go Security Team stressed that the underlying bug is not specific to MPTCP, and that systems with no MPTCP listeners may be vulnerable to similar attacks.

CloudLinux reports that its kernel team could not reproduce Anthropic’s claim and that its own remote reproduction did not trigger the bug on any distribution it tested. It also notes that MPTCP is disabled by default on Enterprise Linux and CloudLinux systems, so the known exploit chain is not reachable there in the default configuration.

9.8 From the Kernel and Red Hat, 8.1 From SUSE

The score of 9.8 comes from the kernel CVE team, which rates attack complexity low because, in its words, both sides of the race are “attacker-induced.” Its scenario has an unauthenticated peer send a connection request carrying IPv4 Record Route or Timestamp options, then race a retransmission against the setup and teardown of the same connection. The possible results it lists range from leaking kernel memory to the attacker to corrupting it and crashing the system.

SUSE scores the flaw 8.1, with a vector that matches the kernel team’s on every metric except attack complexity, which it rates high. Red Hat had also scored it 8.1. In a security bulletin published on October 30, it rates the flaw Critical, and it now scores it 9.8, with low attack complexity. Its statement cites the lack of network prerequisites and the potential for severe system instability, while noting that reliably executing code requires precise heap control. As of November 2, NVD had not added a score of its own.

Fixed Kernels by Distribution, as of November 2

KernelCare live patches for EL8, EL9 and EL10 kernels, covering RHEL, AlmaLinux, Rocky Linux, Oracle Linux and CloudLinux, have been on CloudLinux’s test feed since October 31 and November 1, with the production feed next, according to CloudLinux.

A Packet Filter Reduces Exposure Until the Patch

Red Hat’s bulletin gives an nftables rule that drops incoming IPv4 TCP packets carrying IP options. According to Red Hat, the rule reduces exposure but cannot fully prevent exploitation, may disrupt necessary workloads and is not a substitute for patching. Ordinary application traffic is generally expected to remain unaffected, because standard TCP options travel in the TCP header. In the Go issue tracker, Go contributor Damien Neil had suggested a similar packet-filter defense, adding that he had not confirmed it. For its own systems, CloudLinux recommends keeping MPTCP disabled with net.mptcp.enabled=0 until a live patch is installed.

For Go programs, the Go Security Team’s announcement explains how to turn MPTCP off by default: setting GODEBUG=multipathtcp=0 in a program’s environment at runtime, or placing a godebug multipathtcp=0 line in the main module’s go.mod file at build time. The team calls this program-by-program approach a fragile mitigation, because a single MPTCP listener left exposed still leaves the system vulnerable and because it assumes every viable exploit depends on MPTCP. The team considers it premature to change Go’s default behavior in response.

Where a fixed kernel package exists, installing it is the fix that both the kernel CVE team and the Go Security Team recommend. It takes effect only once the server runs the patched kernel, after a reboot or through a live patch where one is offered. Distribution kernels carry the fix under their own version numbers, so the upstream versions listed above are not a guide to them. The kernel CVE team advises updating to the latest stable kernel rather than applying individual commits, which it calls unsupported.