Linux Kernel MPTCP Flaw Enables Remote Root Access

A kernel race condition can turn an exposed Linux MPTCP listener into a path to remote root access. Anthropic says an unreleased Claude research model helped develop a zero-click exploit that lets an unauthenticated attacker run arbitrary commands without user interaction. That combination matters: the target is a particular network configuration, but a successful attack can reach the highest level of control on the machine.

Tracked as CVE-2026-98432, the bug is a use-after-free in the Linux networking stack. Anthropic’s proof of concept took about 53 minutes to move from leaking kernel memory to executing a root-level command, according to the company’s blog post. The exploit chain used the leak to bypass Kernel Address Space Layout Randomization (KASLR), then hijacked kernel control flow.

That reported development time is a measure of what the model helped produce in Anthropic’s research setting; it doesn’t establish how quickly a different attacker could reproduce the work or how broadly the exploit can be deployed. Still, the demonstrated chain is more significant than a crash or a denial of service. It links a memory error to disclosure, a defense bypass, and command execution with root privileges.

The race behind the exploit

The flaw appears during IPv4 TCP connection setup, where the kernel handles IP options. When Linux creates a new connection, it can transfer those options from a pending request to the new socket without copying them. At the same time, another CPU may be processing a retransmitted request and using the same options to build a SYNACK response.

The risk comes from those operations overlapping. One path changes ownership of the options while another still expects to read them. If the new socket is freed before that second CPU finishes reading the options, the kernel can access memory that has already been released. The result is a timing-sensitive bug: the sequence of events matters, and the race can be difficult to reproduce reliably in ordinary testing.

If that freed memory is reused, an attacker may be able to shape what the kernel reads or does next. The source describes Anthropic’s exploit as first leaking kernel memory, then using that information to bypass KASLR and hijack kernel control flow. KASLR makes kernel memory locations less predictable, so a leak can undermine that protection by revealing information the exploit needs.

The upstream fix delays freeing the affected objects until an RCU grace period has passed, allowing concurrent readers to finish. In practical terms, that gives CPUs already using the shared data time to complete before the kernel releases its memory. It addresses the lifetime mismatch at the center of the race rather than changing how the network feature is meant to work.

The issue has a critical severity score of 9.8 and affects eight kernel branches, with exposure dating back to version 4.4. Fixed releases include 5.10.272, 5.15.223, 6.6.159, 6.1.190, 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. Those version numbers make it important to identify the exact kernel branch in use; a distribution may also package fixes according to its own release process.

MPTCP determines exposure

Anthropic’s Linux exploit targets servers with an MPTCP listener. Multipath TCP allows one connection to use several network interfaces, supporting bandwidth aggregation, network selection and failover. The protocol can be useful where a system needs to manage connections across multiple paths, but this vulnerability makes the listener’s presence relevant to security review.

Linux applications generally need to request MPTCP explicitly when creating sockets, though eBPF and other configuration methods can enable it for applications. That means checking only whether a machine runs Linux won’t establish whether it’s exposed. Administrators need to understand how the feature is enabled in their environment and whether a service is listening with it.

That distinction narrows the immediate exposure, but it doesn’t remove the need to patch. Network-facing services can be overlooked, and configuration can be managed outside the application itself. (And this is the part most people overlook.) A vulnerability’s reach depends on the combination of kernel version and enabled behavior, so asset inventories and configuration records need to answer both questions.

Fixed kernel packages are available for at least some releases from Debian, Oracle Linux, SUSE and Amazon Linux. As of October 30, Ubuntu and Red Hat Enterprise Linux had not yet released patched kernels. Administrators should check their kernel version and whether they expose MPTCP listeners, then apply the relevant update.

For teams managing many systems, the practical work is to map affected kernel branches to the packages actually deployed, then identify hosts with MPTCP enabled or listening. A version check alone can miss configuration-specific exposure; a configuration check alone can miss whether the vulnerable code remains present. Both pieces are needed to make the patch decision useful.

AI vulnerability research expands

Anthropic presented the Linux result as part of a broader evaluation of AI-assisted vulnerability discovery and exploitation. The company disclosed five exploit chains involving Chrome, Safari, Android, Windows and Linux, demonstrating how its internal model could combine weaknesses into working attacks. The Linux case shows why patching decisions may need to account for both kernel version and network protocol exposure.

There’s a meaningful difference between finding a bug and building an exploit chain. A memory safety flaw can be hard to turn into reliable control of a system; the reported sequence here required a leak, a way around KASLR, and a control-flow hijack. Anthropic’s account suggests its model contributed to that practical work. It doesn’t, by itself, establish how often such results will occur or how much human expertise was involved.

For defenders, the demonstration raises the value of treating vulnerability reports as operational evidence, not just lists of affected versions. A flaw that becomes a working remote exploit can change the urgency of remediation, especially where the vulnerable service is reachable and the protocol is enabled. If you’re working in this space, the immediate question is concrete: which of your systems run an affected kernel branch, and which expose an MPTCP listener?

The broader implication is that AI can help compress parts of vulnerability research, including the path from bug analysis to a functioning proof of concept. That doesn’t make every reported weakness exploitable, and the source provides no basis for predicting how quickly other models or attackers will reproduce this work. But it does show why organizations should be ready to validate exposure and deploy vendor fixes when they become available. The exploit took shape quickly. The response still depends on knowing what’s running.

A narrower attack surface. A serious consequence if it’s present.