Claude Built a Remote Root Exploit for a Linux TCP Bug. RHEL, AlmaLinux and Ubuntu Have No Fixed Kernel Yet

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 October 30, Debian has fixed kernels, while RHEL 8, 9 and 10, AlmaLinux 8, 9 and 10 and Ubuntu’s LTS releases do not.

Of the operating systems cPanel supports, AlmaLinux, CloudLinux and Ubuntu therefore had no fixed kernel to install. Anthropic’s root exploit requires an exposed MPTCP listener, although the underlying flaw is not limited to MPTCP. Neither Red Hat nor Ubuntu gives a 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 rates the flaw 9.8, Red Hat and 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 29 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.

9.8 From the Kernel, 8.1 From Red Hat and 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.

As of October 30, Red Hat and SUSE score the flaw 8.1. Their vectors match the kernel team’s on every metric except attack complexity, which they rate high. Red Hat’s description gives a system crash as the main result, with potential memory corruption. As of October 30, NVD had not added a score of its own.

Fixed Kernels by Distribution, as of October 30

No Confirmed Workaround Before the Patch

Red Hat lists no mitigation that meets its criteria for ease of deployment, broad applicability and stability. In the Go issue tracker, Go contributor Damien Neil suggested that configuring the system packet filter to drop IPv4 TCP packets with IP options may suffice as a defense, adding that he had not confirmed it.

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.