CVSS 9.8 Linux flaw lets attackers take root on Go servers by default

Updated 3 November, 12:49 UTC. Corrected: Red Hat released fixed kernels for RHEL 8, 9 and 10 on 1 November; earlier versions of this article said RHEL was unpatched.

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 put fixed kernels for 22.04, 24.04 and 26.04 into its -proposed testing pocket on 3 November (5.15.0-203, 6.8.0-149 and 7.0.0-43), which administrators must enable and install explicitly. It gave no date for the regular updates, which follow qualification testing; fixes for 20.04 and older releases are still pending. Ubuntu says security updates are "the only appropriate mitigation", because the fix is not specific to MPTCP. Red Hat raised the flaw to Critical on 30 October and released fixed kernels for RHEL 8, 9 and 10 on 1 November.

Until the updated kernel 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 stops new MPTCP sockets on the whole host, but it does not close listeners that are already open, security researcher Marcus Hutchins pointed out: those services must be restarted, and ss -Mlnp shows any MPTCP listener still running. Neither measure fixes the kernel bug.

Threshold Network, which runs the tBTC bridge between Bitcoin and Ethereum, said on 1 November that every tBTC node operator had either patched against CVE-2026-98432 or taken its node offline until a fixed kernel is available. Minting and redemptions are paused until the nodes are back on patched systems, and Aave has frozen its tBTC market. Threshold said it had found no evidence the flaw was used against any node.

Scanning has started

Hutchins said on 3 November that his team had seen residential proxies and Russia-based VPN servers scanning the internet on port 443 with MPTCP-enabled connections since 2 November, sending no data to the web servers they reached. Ordinary scanners do not negotiate MPTCP, so he believes the scans are looking for CVE-2026-98432, and that the sources point to a threat actor rather than researchers.

His own scan on 30 October found about 2.1 million servers reachable over MPTCP on port 443, and about 763,000 that completed a TLS handshake with MPTCP enabled. The scans cannot tell patched kernels from unpatched ones. Because exploiting the flaw does not need a valid HTTP connection, he expects the real attack surface to be closer to the larger number.

No exploitation has been reported and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Hutchins knows of no public remote code execution exploit, but several denial-of-service proofs of concept are circulating. Ubuntu 20.04 and older releases still had no fix on 3 November.