Linux kernel root exploit reaches Go servers through MPTCP default

A flaw in how the Linux kernel sets up IPv4 TCP connections can let a remote attacker run code as root on a server without logging in. Tracked as CVE-2026-98432, it is a use-after-free: when a server accepts a connection, the kernel passes IP options saved from the client's packets to the new connection without copying them, and can free them while another processor is still reading them, according to the CVE description. Kernels since 4.4 are affected. Xinyang Ge of Anthropic reported the bug, the kernel's CVE team rates it 9.8 out of 10, and the fix has been in the stable kernels since mid-October, though several large distributions have not shipped it yet.

Anthropic says Claude built an exploit that "allows a remote attacker to send packets to Linux servers with a multipath TCP listener" and run commands as root, "without any credentials or user interaction". In its test it took 48 minutes to leak a kernel pointer and five more to run a command. A lost race only fails the handshake, so an attacker can retry until it works. Anthropic has not published the exploit or explained why MPTCP is needed.

The exploit needs a server that accepts Multipath TCP (MPTCP) connections. Whether a server does is usually decided by the application, not the distribution, and Go programs do it by default. The Go Security Team confirmed on 29 October that "as of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux."

Who listens on MPTCP

The kernel allows MPTCP sockets unless an administrator turns them off: net.mptcp.enabled defaults to 1. An application still has to open an MPTCP socket, and since Go 1.24 the multipathtcp setting defaults to 2, which turns MPTCP on for every listener. The default follows the go line in a program's go.mod, so the same code built with go 1.23 listens on plain TCP. Atlasum tested both builds and found only the 1.24 one in the output of ss -Mlnp, which lists MPTCP listeners on a host.

The Go team does not treat MPTCP as the whole problem. "The underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks," it wrote, calling per-program opt-outs "a fragile mitigation". It said changing Go's default now would be premature. A proposal to switch it off is still open, and some downstream projects have disabled MPTCP listeners in their own code.

Patch status

The upstream fix, which delays freeing the saved IP options until other CPUs stop reading them, was merged on 5 October and is in every maintained stable branch. Debian, SUSE, Oracle and Amazon Linux ship fixed kernels, according to Atlasum's tracking. Ubuntu lists every LTS release from 16.04 to 26.04 as vulnerable, with fixes in progress for 22.04 and newer. Red Hat raised the flaw to Critical on 30 October and has no fixed kernel yet for RHEL 8, 9 or 10.

Until a kernel update is installed, Red Hat's interim measure is an nftables rule that drops incoming IPv4 TCP packets carrying IP options (ip protocol tcp ip hdrlength > 5 counter drop, in an input chain at priority -310). Red Hat says the rule reduces exposure but "cannot fully prevent" exploitation. On Go services, setting GODEBUG=multipathtcp=0 or adding godebug multipathtcp=0 to go.mod removes the MPTCP listener; setting net.mptcp.enabled=0 does the same for the whole host. Neither fixes the kernel bug.

No exploitation has been reported and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Atlasum counted 36 GitHub repositories referencing the CVE on 31 October, at least six of them describing a race trigger or proof of concept.