Remote root via Multipath TCP: kernel flaw CVE-2026-98432 and the default in Go
Summary
In a report on five attack chains found with Claude, Anthropic's Frontier Red Team describes a race condition in the Linux kernel's TCP stack that lets a remote attacker without credentials run commands as root on servers with a Multipath TCP listener (CVE-2026-98432). The bug sits in the setup of IPv4 connections and is fixed in all maintained stable kernels, but Ubuntu and Red Hat had not shipped complete updates by the end of October 2026. Go makes the flaw more serious: since version 1.24, Go programs on Linux open their listeners with MPTCP by default, so many services meet the precondition without their operators knowing.
What goes wrong in the kernel
The bug is in the code that sets up new IPv4 TCP connections. According to LWN, the reply to a retransmitted SYN packet has to be generated at exactly the moment another thread finishes establishing the connection. The second thread frees the structure holding the connection's IP options, and the first one still accesses it afterwards. This class of bug is called use-after-free.
The kernel CVE team's rating assumes an attacker who sends connection requests with the IPv4 options Record Route or Timestamp and repeats them until the timing works out. According to Golem, IPv6 is apparently not affected because the kernel copies the options there. The fix frees the structure only after an RCU grace period, that is, only once no other CPU can still be using it.
According to Golem, the bug goes back to Linux 4.4. The fix entered the main branch on 5 October 2026, about ten days before the CVE was published; Xinyang Ge of Anthropic is credited as reporter.
How the exploit works
Anthropic describes two stages. First, the race condition makes the kernel read an attacker-controlled length field and send back extra bytes. As soon as one such reply contains a kernel pointer, the attacker knows the memory layout and KASLR is defeated.
In the second stage, the same bug triggers a buffer overflow that overwrites a callback pointer. It then points to code the attacker has previously placed in kernel memory through an ordinary protocol feature. When the kernel invokes the callback, it chains existing kernel functions up to a shell command of the attacker's choice running as root.
What matters in practice: a lost race only makes that single connection setup fail, and the system keeps running. In Anthropic's test, leaking a kernel pointer took 48 minutes and command execution another five minutes. Anthropic has not published exploit code, kernel version or test configuration.
Why Go enlarges the attack surface
On Linux, an application has to request MPTCP explicitly when opening the socket. That is exactly what Go has done automatically for listeners since version 1.24: net.ListenConfig uses MPTCP by default where the kernel supports it. Many network services are written in Go, reverse proxies, exporters, container tools, and all of them therefore bring an MPTCP listener along.
On 29 October, the Go security team wrote on golang-announce that the bug is not tied to MPTCP; systems without MPTCP listeners might also be vulnerable to similar attacks. Turning MPTCP off per program, with GODEBUG=multipathtcp=0 at runtime or godebug multipathtcp=0 in go.mod at build time, is therefore only fragile protection: a single forgotten listener is enough. The team does not want to change Go's default for now.
How far the distributions are
The bug is fixed in the stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Debian shipped it for trixie with DSA-6568-1 and kernel package 6.12.113-1; according to Golem, Oracle Linux, SUSE and Amazon Linux have packages for at least some kernels. On 29 October, Ubuntu listed versions 16.04 to 26.10 as vulnerable or in progress, and Red Hat deferred the fix for RHEL 8, 9 and 10 to a later update.
The ratings differ widely: the kernel CVE team gave 9.8 out of 10, Oracle and SUSE 8.1, Amazon 7.0. Red Hat first listed 5.9 ("Moderate") on its CVE page and raised it to 8.1 ("Important") on 29 October. The difference lies mainly in how hard it is to win the race. No attacks are known so far, and the flaw was not in CISA's KEV catalog on 28 October.
Ideas
- A race during connection setup frees memory that another thread still reads.
- A lost race costs the attacker only one connection attempt, not a crash.
- A memory leak via extra reply bytes defeats KASLR remotely.
- Since version 1.24, Go programs on Linux open their listeners with MPTCP automatically.
- Disabling MPTCP per program only protects as long as no listener is forgotten.
- An installed kernel only protects after the reboot.
- Distributions rate the same flaw between 5.9 and 9.8 points.
Insights
- A default in a runtime shifts the attack surface of entire server landscapes without any operator configuring anything. Anyone who wants to know what a system offers has to look at the sockets that are actually open, not at the configuration files.
- Race conditions in network code were often considered hard to exploit. If every failed attempt has no consequences, "hard" merely becomes "takes an hour"; ratings based on high attack complexity underestimate this.
- Neither the CVE entry nor the patch mentions MPTCP. Anyone filtering security notices only by affected features would have missed the flaw for their own Go services.
Quotes
- "An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." (Anthropic)
- "The best fix for this vulnerability is to upgrade to a patched kernel version." (Go security team on golang-announce, 29 October 2026)
Facts
- CVE-2026-98432 is a use-after-free in the setup of IPv4 TCP connections; the kernel CVE team rates it 9.8.
- Fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3; Debian trixie from 6.12.113-1 (DSA-6568-1).
- In Anthropic's test: 48 minutes to the kernel pointer, another five minutes to the root command.
- Go 1.24 and later uses MPTCP for listeners on Linux by default; can be turned off with GODEBUG=multipathtcp=0.
- On 28 October 2026 the flaw was not in CISA's KEV catalog; no attacks are known.
References
- Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude (section 5)
- Golem: Linux flaw: Claude writes root exploit, Ubuntu and RHEL without patch (German)
- LWN.net: Remote code execution on Linux systems with multipath TCP
- Go security team: Protecting against CVE-2026-98432 (golang-announce, via oss-security)
- Go issue #82717: discussion of the MPTCP default
- Go 1.24 release notes (net: ListenConfig uses MPTCP by default)
- Linux: commit e3f33b0a1d89 (fix)
- Debian Security Tracker: DSA-6568-1
- NVD: CVE-2026-98432
Critique
- Anthropic names an MPTCP listener as a precondition but does not explain why the exploit needs it, and withholds kernel version and configuration. Operators therefore cannot judge for themselves whether servers without MPTCP are at risk; the Go security team explicitly considers it possible.
Remarks
- The report is also an advertisement for Anthropic's models and its Cyber Verification Program. The kernel commit, the CVE entry and the distributions' notices confirm the technical details of the flaw independently.
- Red Hat currently considers no mitigation other than the patch sufficient. According to Golem, it is open whether disabling MPTCP or filtering IP options reduces the risk.
Recommendations
- Check the kernel: compare uname -r with the fixed versions; on Debian trixie install at least 6.12.113-1 and reboot, because the old kernel keeps running until then.
- List open MPTCP listeners with their processes: ss -Mlnp. Every hit is a service that meets the precondition described in the report.
- Where the patch is still missing, sysctl net.mptcp.enabled=0 prevents new MPTCP sockets system-wide. This is a stopgap, not a replacement for the kernel fix: it is not established that it reliably prevents the attack.
- Build your own Go services that do not need MPTCP with godebug multipathtcp=0 in go.mod, or set net.ListenConfig.SetMultipathTCP(false).
Links to the original source and the Web Archive open in a new tab.