Root Access in Under an Hour: CVE-2026-98432 Hits Linux MPTCP
If you've ever wondered how a small bug in the Linux kernel could turn into a full-blown crisis, here's a textbook example. In October 2026, researchers at Anthropic discovered a vulnerability, CVE-2026-98432, that is essentially a ticket for remote attackers to commandeer servers running Multipath TCP (MPTCP). The punchline: they managed to get root access from the other side of the world, with no authentication needed on MPTCP listeners.
What Actually Broke
This isn't just any bug. CVE-2026-98432 scores a sobering 9.8 out of 10 on the severity charts. The root cause is a use-after-free in the kernel's IPv4 TCP networking code, present in kernels going back to version 4.4. If you're running Ubuntu, Red Hat Enterprise Linux, Rocky Linux or most mainstream distributions (except RHEL 7), you are in the blast radius.
Here's the nutshell version: there's a race condition when two CPUs handle incoming TCP connection requests at the same time. Specifically, in the tcp_v4_syn_recv_sock() function, Linux hands off socket options without actually copying them. If a second SYN packet arrives and gets picked up by another CPU, the kernel gets confused about who owns what. Suddenly, memory that should be off-limits is dangling, and that's how you end up with remote code execution.
Red Hat, with their usual conservatism, called the bug's practical risk low because pulling off the attack is complex. However, Anthropic's researchers built a working exploit that bypassed all the kernel address space layout randomization (KASLR). It is not point-and-click, but after 53 minutes of automated attempts, they achieved root access. This demonstrates the seriousness of the vulnerability.
Why MPTCP Is in the Crosshairs
Multipath TCP is one of those features that promises improved speed and reliability by letting a single TCP connection use multiple network links at once. Most people probably assume it's not enabled unless they turned it on, but there's a twist. Some programming languages (Go, from version 1.24, for instance) quietly switch it on by default for any TCP listener running on Linux. MPTCP may be active without administrators realizing it.
Performance and reliability are valuable, but more complexity means more places for things to break. That upside can become a liability if attackers can use it as a backdoor.
From Theoretical to Real-World Exploit
Vendors have noted that exploiting this bug is tricky and requires precise timing. Anthropic showed otherwise. Their exploit reliably beat KASLR and achieved root shell access over the network on MPTCP-enabled systems. It took less than an hour, which is a short time for an automated exploit. The impact is clear: attackers gaining root means full control over the system, not just on a single box, but potentially anywhere MPTCP is quietly running in the network stack.
Patching: A Race Against Attackers
Once word got out, patches started appearing. Canonical quickly flagged several Ubuntu releases. Red Hat called out RHEL 8, 9 and 10 as vulnerable, with updates on the way. Debian and several commercial Linux vendors issued their own fixes. However, not everyone moves at the same speed. Some administrators are left waiting, and as patches roll out unevenly, a patchwork emerges where some servers are protected and others remain vulnerable.
Workarounds: Not as Simple as Flipping a Switch
Some Linux support providers (like CIQ for Rocky Linux) published firewall rules and nftables configurations to block attack traffic. That helps, but it is not a complete solution. Even turning off MPTCP does not eliminate the risk, since the root bug exists in conventional TCP handling as well.
What This Really Means
CVE-2026-98432 is a reminder that every shortcut or feature added for performance can come with a hidden price tag. MPTCP was meant to make life easier for developers and users, but under the hood, it opened up another attack surface. The way this flaw went from "hard to exploit" to "remote root in under an hour" shows how quickly things can go sideways in complex systems.
Security is not just about locking doors, it is about knowing which doors even exist. The more moving parts, the harder that gets. When the next feature promises to make our lives better, it is worth considering what else it brings along for the ride.
Top comments (0)