TCP2RootShell

Who's exposed

The vulnerable code runs inside the kernel while it handles incoming connection requests, before any application sees the connection. If a host listens on an IPv4 TCP port that an attacker can reach, the attacker can reach the bug. No credentials and no user interaction are needed.

• Internet-facing servers with any open IPv4 TCP port: web, mail, SSH, VPN, APIs
• Hosts with an MPTCP listener, the configuration in the demonstrated root exploit. Go 1.24 and later open these by default where the kernel allows it
• Hosts with request socket migration enabled (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program), which opens a second path. Both are off by default

The bug

A client can put IPv4 options, such as Record Route or Timestamp, in its SYN. The kernel stores them with the half-open connection in ireq_opt, because the SYNACK has to echo them back. When the handshake completes, tcp_v4_syn_recv_sock() hands that pointer to the new child socket's inet_opt without copying the data.

If the client retransmits its SYN at the right moment, another CPU builds a fresh SYNACK from the same options. Since commit 079096f103fa (Linux 4.4), request sockets are processed without the listener lock, so nothing stops the child socket from being torn down in the meantime. Its destructor frees the options with a plain kfree(), and the SYNACK path reads freed memory.

The kernel CNA's scoring notes describe three outcomes once the freed object is reclaimed:

• Information disclosure: a stale length makes the kernel copy adjacent heap memory into the SYNACK it sends to the attacker
• Memory corruption: stale offsets steer writes in ip_options_build(), allowing out-of-bounds kernel writes
• Denial of service: an oversized length can push past the packet headroom and trigger skb_under_panic()

The fix by Eric Dumazet, upstream commit e3f33b0a1d89, changes two kfree() calls to kfree_rcu(), in inet_sock_destruct() (net/ipv4/af_inet.c) and tcp_v4_reqsk_destructor() (net/ipv4/tcp_ipv4.c). Readers already used RCU; now the memory waits for them.

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

A lost race only fails that one handshake. It does not crash the server, so an attacker can keep retrying as long as the port is open.

Exploitation status

• Anthropic Frontier Red Team, 27 October: an unreleased internal Claude research model wrote a remote root exploit against a Linux server with an MPTCP listener. Stage one wins the race to leak a kernel pointer through the SYNACK and defeat KASLR. Stage two overwrites a callback pointer to run a shell command as root. Anthropic reports 48 minutes to leak the pointer and another five to reach command execution
• Exploit code: not published. The kernel version and exact test configuration are not public either, and no independent public reproduction had been reported by 30 October
• In the wild: no vendor or CERT had reported exploitation by 30 October, and the CVE was not in CISA KEV
• Without MPTCP: nobody has publicly shown root against a host without an MPTCP listener. The Go Security Team notes the underlying bug is not MPTCP-specific and such systems may be vulnerable to similar attacks

MPTCP and Go

On Linux, an application only gets MPTCP if it asks for it when it opens a socket, so for years most teams could assume they were not running it. Go changed that: since Go 1.24, Go programs enable MPTCP on listening sockets by default where the kernel supports it. Gateways, reverse proxies and internal services written in Go may hold MPTCP listeners their owners never asked for.

Whether the kernel allows it depends on net.mptcp.enabled. RHEL 8, 9 and 10 and their rebuilds ship with it set to 0; distributions that keep the upstream default ship 1.

The Go Security Team's guidance (29 October) for disabling the default:

# at runtime, per program
GODEBUG=multipathtcp=0 ./your-service

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

Code calling SetMultipathTCP on a net.ListenConfig or net.Dialer overrides both. The Go team calls this a fragile mitigation and recommends a patched kernel.

Affected kernels

Every Linux kernel from 4.4 onwards, until these stable releases:

Distribution status

Installing a fixed kernel package is not enough. The running kernel stays vulnerable until the host reboots into the new one, or a livepatch for this specific CVE is applied.

Why the scores differ

Your scanner may show this CVE as Critical on one host and Moderate or Important on another.

The remaining disagreement is attack complexity. Vendors rate a cross-CPU race as hard to win; the CNA argues both sides of the race are attacker-induced and a lost race costs nothing but one connection attempt. If your patch SLA keys off vendor severity, treat this CVE as remote code execution regardless.

Check your hosts

# running kernel (compare against your vendor's advisory, not upstream)
uname -r

# is the fix in the running kernel's changelog?
apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432   # Debian, Ubuntu
rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432               # RHEL family, Amazon Linux
rpm -q --changelog kernel-default | grep CVE-2026-98432                   # SUSE

# installed but not yet booted?
[ -f /var/run/reboot-required ] && echo "Reboot required"                 # Debian, Ubuntu
needs-restarting -r                                                       # RHEL family

# MPTCP allowed, migration path closed?
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

# every line printed is an MPTCP listener (needs a recent iproute2)
ss -H -lMnp

Check everywhere Linux runs: bare metal, VMs, Kubernetes and OpenShift nodes, appliances, CI runners. Containers share the host kernel, so patching images does nothing here; patch and reboot the nodes.

Fix it

Install your distribution's fixed kernel, then reboot into it (or apply a livepatch that covers this CVE).

# Debian (ensure security.debian.org is in your sources), Ubuntu once released
sudo apt update && sudo apt full-upgrade && sudo reboot

# RHEL family, Amazon Linux, Oracle Linux, once released
sudo dnf upgrade kernel && sudo reboot

# SUSE
sudo zypper patch && sudo reboot

If you build your own kernels, move to the latest release on your stable branch from the table above. The kernel CVE team recommends that over cherry-picking individual fixes.

Prioritise internet-facing hosts with open IPv4 TCP ports, then anything with MPTCP listeners or Go services, then internal hosts.

If you can't patch yet

Red Hat states no mitigation meets its criteria, and no vendor has validated the options below against an exploit. They follow from how the bug works. Test them in staging, and do not treat them as a substitute for a fixed kernel.

1. Turn MPTCP off where nothing needs it

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-cve-2026-98432.conf
# then restart services that already opened MPTCP listeners

Removes the listener the demonstrated chain needs. The bug is still reachable through plain IPv4 TCP.

2. Keep request socket migration off

sysctl net.ipv4.tcp_migrate_req   # should print 0 (the default)

3. Drop inbound TCP packets carrying IPv4 options

The main path needs IP options in the SYN, and normal TCP traffic does not carry them. This rule matches any IPv4 header longer than 20 bytes, so it covers Record Route and Timestamp alike, MPTCP or not:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop

# undo
nft delete table ip cve_2026_98432

Not persistent across reboots; add it to your firewall configuration if you keep it. Filtering IP options at the network edge covers every host behind it, provided all traffic passes through that edge.

4. Watch for crashes

journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic'

Timeline

1. Jan 2016Linux 4.4 ships commit 079096f103fa, which introduces the race
2. 5 Oct 2026Eric Dumazet's two-line fix is applied upstream, reported by Xinyang Ge (Anthropic)
3. 15 Oct 2026The kernel CVE team publishes CVE-2026-98432
4. 16 Oct 2026Oracle fixes UEK; Debian fixes trixie (DSA-6568-1)
5. 17-22 Oct 2026Debian fixes bookworm (DLA-4841-1, DLA-4850-1)
6. 24 Oct 2026The kernel CNA adds its 9.8 score; Amazon fixes kernel6.18
7. 27 Oct 2026Anthropic describes a remote root exploit against an MPTCP listener
8. 29 Oct 2026Red Hat raises its rating to Important; SUSE ships kernel advisories; Amazon fixes kernel6.12; the Go Security Team publishes guidance
9. 30 Oct 2026AlmaLinux publishes patched kernels for testing. RHEL and Ubuntu fixes still pending

About the name

Every serious bug now seems to arrive with a something2shell domain. This one starts with a TCP SYN and, in the configuration Anthropic demonstrated, ends in a root shell. Hence TCP2RootShell. The name describes the demonstrated chain; root has not been publicly shown on hosts without an MPTCP listener.

To be clear, we did not find, fix or exploit this bug. Credit belongs to the people who did the work: Xinyang Ge of Anthropic reported it, Eric Dumazet fixed it, and Anthropic's Frontier Red Team did the exploitation research. The Linux kernel CVE team published and scored it, and the distribution security teams are shipping the fixes.

Sources

• CVE.org record: CVE-2026-98432
• NVD: CVE-2026-98432
• Linux kernel CVE announcement
• Upstream fix: commit e3f33b0a1d89
• Anthropic: Discovering vulnerabilities with Claude
• Go Security Team: Protecting against CVE-2026-98432 (oss-security)
• Ubuntu, Red Hat, Debian, SUSE, Oracle, Amazon Linux
• AlmaLinux: patched kernels available in testing
• Red Hat Bugzilla 2553390
• CISA Known Exploited Vulnerabilities catalogue