Anthropic researchers built working exploit for Linux kernel flaw CVE-2026-98432

Researchers at Anthropic built working exploit code for CVE-2026-98432 that gives unauthenticated attackers the ability to run commands as root on Linux servers with Multipath TCP listeners, the company disclosed in an Oct. 27 post.

Anthropic said its unreleased Claude model wrote the exploit after initial prompting by researchers, and it needed about 53 minutes to achieve remote root code execution. Leaking a kernel address required 48 minutes, and reaching command execution took five minutes more.

It evades kernel address space layout randomization (KASLR), then overwrites a callback pointer so an attacker-chosen shell command runs as root. Losing the race fails just that one connection attempt without crashing the system, so the attacker can repeat the attempt. The kernel team says the flaw could leak nearby kernel memory to an attacker, corrupt kernel memory, or take the system down.

Multipath TCP is a feature that lets one connection use several network paths at once to improve performance and reliability. Linux applications have to ask for MPTCP explicitly when they open sockets, but eBPF, a programmable kernel interface, is among the configuration techniques that can force an application to use it. With Go 1.24, Go enables MPTCP by default for Linux TCP listeners when the kernel supports the feature. IPv6 is not affected: when the kernel handles IPv6 connections, it copies the options.

Anthropic’s post describes an exploit aimed at servers running an MPTCP listener, and it does not say whether systems without such a listener are vulnerable to this takeover method. The flaw also affects ordinary TCP connections, though a remote takeover has not been publicly shown on servers that lack an MPTCP listener. Neither the CVE record nor the kernel fix mentions MPTCP; Anthropic’s post supplies the connection between that feature and the bug.

CVE-2026-98432 is a use-after-free vulnerability, in which code reuses freed memory, in the kernel’s IPv4 TCP networking code, caused by a race condition, and exposed versions go back as far as Linux 4.4.

The faulty code entered the codebase in Linux 4.4, committed on Oct. 2, 2015, and went undetected for roughly 11 years. Developers applied a patch on October 5, ten days before the CVE record was published.

The vulnerability earned a 9.8 out of 10 rating on the CVSS vulnerability-scoring scale from the Linux kernel CVE team.

That 9.8 rating assumes an attacker sends a TCP connection request with IPv4 Record Route or Timestamp options, then resends it hoping to win the race. It rated attack complexity low, since both parties in the race are attacker-induced.

On Oct. 28, the National Vulnerability Database was still showing the kernel team’s 9.8 rating instead of its own score. CISA’s Known Exploited Vulnerabilities catalog, as copied by CIRCL and last updated Oct. 28, does not list the flaw. No confirmed reports exist of attackers exploiting CVE-2026-98432 in the wild.

Red Hat calls the flaw Moderate at 5.9, saying the race is hard to win, while its advisory file marks it Important at 8.1.

Oracle and SUSE put the score at 8.1, while Amazon puts it at 7.0. Vendor scores of 8.1 agree with the kernel team’s metrics apart from attack complexity, which vendors rate high and the kernel team rates low.

In Red Hat’s view, winning the race is harder than sending one malicious network packet.

According to Red Hat, RHEL 8, 9 and 10 are affected; RHEL 7 is not, because its kernel does not contain the vulnerable code. As of October 30, Red Hat also listed OpenShift 4 as affected.

Canonical’s security tracker shows Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 as vulnerable, with kernel fixes still in progress as of October 30.

It marks cloud, FIPS and real-time kernels as vulnerable or still being completed. As of October 30, fixed kernels had not been released by Ubuntu or RHEL, and neither vendor gives a release date.

According to CIQ, Rocky Linux versions 8, 9 and 10 are affected. For Debian, the fixed kernel packages are 6.1.190-1 for Debian 12 Bookworm and 6.12.113-1 for Debian 13 Trixie. macOS is not affected because it runs Apple’s XNU kernel rather than Linux.

The fixed upstream kernel releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. On Oct. 15, Greg Kroah-Hartman said the bug was fixed in kernel versions 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. In the upstream fix, affected objects are not released until after an RCU (read-copy-update) grace period, so concurrent readers can finish first. The patch requires the kernel to wait for other processors to finish reading the options before releasing the memory.

The Linux kernel team credits Xinyang Ge of Anthropic with reporting the bug. The company’s Oct. 27 post described the research across exploit chains for Chrome, Safari, Android, Windows and Linux. Anthropic says its 90-day coordinated disclosure policy means more details about its other findings may come later, and it has not released the exploit code.

CIQ advises blocking IPv4 TCP packets with IP options ahead of the vulnerable TCP processing code and shared nftables rule examples (nftables is the Linux packet-filtering framework), warning that disabling MPTCP alone will not suffice because attackers can still trigger the underlying flaw with ordinary TCP traffic.

According to the Go Security Team, setting GODEBUG=multipathtcp=0 turns MPTCP off by default at runtime, but per-program disabling remains a fragile mitigation. The team also says the flaw extends beyond MPTCP, that systems without MPTCP listeners could face comparable attacks, and that the best fix is updating to a patched kernel.

Red Hat says no existing mitigation meets its criteria, which cover simple deployment, broad installation suitability and stability, and none of the other distributions’ advisories lists one that does either. System administrators should check kernel versions, determine whether MPTCP listeners accept external connections, review distribution security advisories, and apply updated kernel packages when vendors release them. Neither the distribution advisories nor Anthropic’s post says whether disabling MPTCP or blocking incoming connection requests carrying IP options would reduce the risk. The kernel CVE team recommends adopting the most recent stable kernel and says the community does not support cherry-picking individual fixes.