A Claude-written exploit achieves remote root over Linux TCP through an MPTCP listener

15 October 2026. CVE-2026-98432, a use-after-free in IPv4 TCP handling present since Linux 4.4, is published. 27 October 2026. Anthropic reveals that an exploit written by Claude runs commands as root, without authentication, on servers listening with MPTCP. 29 October 2026. The Go security team issues an advisory, because Go 1.24 and later listen with MPTCP by default.

A race between two threads inside the handshake

The flaw is a use-after-free: the kernel reads memory it has already freed. It plays out during the TCP handshake’s three steps (SYN, SYN-ACK, ACK). When the kernel receives the first SYN, it creates a temporary object — the request socket — and stores the header’s IPv4 options (such as Record Route or Timestamp) in a field called ireq_opt.

When the ACK arrives, the connection is established and the kernel creates the real, child socket. The critical point: the memory behind ireq_opt is not copied; the pointer is simply handed to the child socket as inet_opt. From then on, the same memory region is referenced by both objects.

If another CPU meanwhile handles a retransmitted SYN for the same request socket, it starts rebuilding the SYN-ACK and reads those options. But the child socket’s destructor, inet_sock_destruct(), freed that memory with a plain kfree() — immediately, without waiting for in-flight readers to finish. The result: one CPU reads memory that the other just freed. If that region is reallocated to something else between two reads of the length, the two reads disagree, and the kernel can disclose memory or write out of bounds.

The race dates back to October 2015, to commit 079096f103fa (“tcp/dccp: install syn_recv requests into ehash table”), which removed the listener lock while request sockets are processed. Linux 4.4, the first release containing that commit, opens the affected range.

A two-line fix, but a deep correction

The fix, signed Eric Dumazet, is commit e3f33b0a1d89. It changes two lines in net/ipv4/af_inet.c and net/ipv4/tcp_ipv4.c, swapping the kfree() for a kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor():

-	kfree(rcu_dereference_protected(inet->inet_opt, 1));
+	kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);

The move to RCU forces the free to wait until in-flight readers leave — exactly what was missing. The other paths that set or replace options (do_ip_setsockopt(), cipso_v4_sock_setattr()) already used kfree_rcu(); only these two socket-teardown sites freed immediately.

Fixed releases span every maintained branch: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3 for mainline. The point to remember: installing the package does nothing on its own — you must reboot into the new kernel, since live patching is a separate mechanism.

# Check the running kernel and MPTCP state
uname -r
sysctl net.mptcp.enabled

Why Anthropic’s exploit changes the calculus

What sets CVE-2026-98432 apart from yet another use-after-free is the proof delivered on 27 October. In its post “Discovering and exploiting vulnerabilities in critical, real-world software with Claude,” Anthropic’s Frontier Red Team describes an exploit that achieves unauthenticated remote root on a Linux server listening with MPTCP.

The exploit proceeds in two stages. It first defeats KASLR by using the race to make the kernel read an attacker-controlled length and send extra bytes back in the reply — if one of those overreads contains a kernel pointer, the load address is deduced. It then hijacks control flow by overflowing a buffer to overwrite a callback pointer, chaining calls to existing kernel functions to run an attacker-chosen shell command as root.

The numbers tell the story of the persistence required: in the proof of concept, leaking a kernel pointer took 48 minutes, and reaching shell command execution another five. Losing the race only fails the handshake without crashing the system, so the attacker can keep retrying until it works. Anthropic notes that an unreleased internal research model wrote the exploit after initial prompting.

MPTCP: the prerequisite became the default setting

The paradox of this flaw is that it is not MPTCP-specific — the race lives in IPv4 TCP handling. MPTCP is only the demonstrated precondition for the exploit. And that precondition has silently become ordinary.

Since Go 1.24, Go programs listen with MPTCP by default on Linux (multipathtcp=2: enabled on listeners only). Any service written in Go and compiled with 1.24 or later — APIs, proxies, databases — therefore opens an MPTCP listener without anyone asking for it. On 29 October, the Go security team issued an advisory and opened issue #82717 proposing to disable MPTCP by default.

The temporary mitigation takes two forms:

# Disable MPTCP when starting a Go program
GODEBUG=multipathtcp=0 ./server

// Or at build time, in the main module's go.mod
godebug multipathtcp=0

The Go team says it plainly: this setting is fragile. It removes only the demonstrated precondition, not the flaw — a single forgotten MPTCP listener keeps the condition in place, and there may be attack paths that do not go through MPTCP at all. Disabling MPTCP is a band-aid, not a fix.

Where the distributions stand

The status on 30 October is uneven, and that is what should dictate your urgency. Debian has fixed it: Debian 12 (bookworm) via linux 6.1.190-1 (DLA-4841-1) and linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1), and Debian 13 (trixie) via DSA-6568-1. By contrast, Ubuntu was not yet confirmed fixed on its security tracker, and RHEL 8, 9, 10 plus OpenShift 4 are listed as affected with no fixed package at the time of writing. Red Hat also rates the flaw 8.1 (Important, AC:H), versus 9.8 (Critical) from the kernel CNA — a gap driven by an assessment of attack complexity, not a disagreement about impact.

That uneven availability has a concrete consequence: part of the Linux fleet has no fix to apply tonight. For those systems, the Go setting and control of MPTCP exposure are, for now, the only line of defence.

Verdict

If your distribution ships a fixed kernel, install it and reboot now: that is the only real correction, and the uname -r after reboot is the only proof you are protected. If you run Ubuntu or RHEL with no fix available, treat your Go 1.24+ services as potentially reachable: enumerate what listens with MPTCP, apply GODEBUG=multipathtcp=0 as a stopgap, and restrict the network exposure of those listeners until a fixed kernel ships. And do not reduce this CVE to an AI story: a model writing the exploit is spectacular, but the operational lesson is more mundane — a race introduced in 2015 sat invisible for a decade, and it was the default-turned prerequisite (Go’s MPTCP listeners) that turned it into mass risk. CVE-2026-98432 is a reminder that, on a server, exposure is sometimes decided less by code than by a setting nobody chose.

Références

• NVD — CVE-2026-98432
• Anthropic — Discovering and exploiting vulnerabilities in critical, real-world software with Claude (27 October 2026)
• LWN — Remote code execution on Linux systems with multipath TCP (30 October 2026)
• Fix commit — e3f33b0a1d89 (Eric Dumazet)
• The Hacker News — Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat (29 October 2026)
• Go — godebug multipathtcp