Linux Kernel Flaw CVE-2026-98432 Gives Remote Root on MPTCP Servers

A critical Linux kernel vulnerability, tracked as CVE-2026-98432, lets an unauthenticated remote attacker gain root on servers that run a Multipath TCP (MPTCP) listener. The flaw is a use-after-free in the kernel's IPv4 TCP connection handling, reported across kernels dating back to version 4.4, and both the Linux kernel CVE team and Ubuntu rate it 9.8 out of 10. The detail that turned a serious bug into a milestone: Anthropic says an unreleased internal AI research model built a working root exploit for it, going from a first memory leak to root command execution in about 53 minutes.

What happened

The Linux kernel CVE team published CVE-2026-98432 on October 15, 2026, describing a use-after-free in the IPv4 TCP stack. The trigger is a TCP SYN packet that carries IPv4 options, such as Record Route or Timestamp. A listening kernel stores those options with the pending connection request. As the Ubuntu security tracker describes it, tcp_v4_syn_recv_sock() then hands those options to the child socket without copying them, and a retransmitted SYN processed on a second CPU can build a SYNACK from the same memory. If the child socket is torn down first, the options are freed while the other path is still reading them. The fix converts the free to an RCU-deferred kfree_rcu(), landed upstream on October 5, 2026, and traces the defect to a commit shipped in Linux 4.4 back in January 2016, per TuxCare's analysis. Maintainers backported the fix across eight stable branches, from 5.10 through 7.3.

What moved the story from routine kernel bug to headline was the exploit. In a writeup published October 27, Anthropic says an unreleased internal research model took the flaw from a memory leak to root-level command execution on a server with an MPTCP listener, with no credentials and no user interaction. The model abused the race to make the kernel copy extra bytes into a reply; once one of those overreads returned a kernel pointer, address space layout randomization (KASLR) was defeated. It then reused the same use-after-free to overwrite a callback pointer and run an attacker-chosen command as root. Anthropic reports the address leak took 48 minutes and command execution another 5, about 53 minutes in total, and frames the result as a proof of concept, not an in-the-wild attack. BleepingComputer notes the exploit code, the kernel version and the tested configuration have not been released.

53 MINUTES TO ROOT

Scope is where this flaw gets its teeth and its limits at once. The demonstrated root chain needs an MPTCP listener, and MPTCP is off by default in most software. The catch, as BleepingComputer and TuxCare both note, is that Go 1.24 and later turns on MPTCP by default for TCP listeners on Linux where the kernel supports it, so services written in Go can be listening on MPTCP without their operators knowing. On Red Hat and Rocky Linux 8, 9 and 10, MPTCP ships disabled, which blunts that default. And disabling MPTCP is not a fix on its own: the underlying race is reachable through ordinary IPv4 TCP, so a host with MPTCP off is less exposed, not patched.

The severity is itself contested, which matters for how teams triage it. The Linux kernel CVE team and Ubuntu both score it 9.8 critical. Red Hat at first characterized the issue as a probable crash, a denial of service, citing how hard the race is to win reliably, before raising its assessment as the demonstration showed code execution was feasible; its record now lists the flaw as critical with high confidentiality, integrity and availability impact. The US National Vulnerability Database had not published its own score as of late October. No vendor advisory has reported exploitation in the wild, and the CVE was not in CISA's Known Exploited Vulnerabilities catalog as of October 29.

Why it matters

Strip out the AI and CVE-2026-98432 is already a bad day: an unauthenticated, remote, root-level flaw in code that has sat in the kernel since 2016. What makes it a marker is the second half of the story. The slow, expensive stage of offensive work is not finding a bug, it is turning a memory-safety defect into a reliable exploit that defeats mitigations like KASLR and lands code execution. Anthropic's account puts that stage at under an hour of machine time.

This is not an isolated result. The same unreleased model is the one Anthropic says found and chained working exploits across Chrome, Safari, Android, Windows and Linux, and CVE-2026-98432 was the Linux link in that chain. It arrives in a stretch of 2026 defined by AI agents being pointed at real intrusions and by a record month of disclosed incidents. The through-line, which we have written about in how attackers use AI, is that the cost of the hardest part of an attack is falling.

The caveats are real and worth keeping in view. The exploit is a proof of concept from a model the public cannot download, run inside a red team's environment, with human prompting to start, and no outside party has reproduced it. Vendor advisories confirm the bug is genuine and is being fixed; whether a released tool reproduces the full chain on demand is a separate question. The defensive case points the same way, though. If an AI-assisted attacker can compress flaw to exploit into under an hour, the window between a patch landing upstream and a working exploit existing shrinks with it, and that is an argument for building security to be AI-native rather than surprised by it.

When the slow, expensive stage of an attack, turning a memory bug into working root, takes under an hour, the gap between a patch landing and an exploit existing is the number that should worry you.

The Threatless read

Treat this as two problems that happen to share a CVE. The first is ordinary and urgent: patch the kernel. CVE-2026-98432 is unauthenticated, remote, and ends in root, the worst combination a server-side flaw can carry. Update when your distribution ships a fixed kernel and reboot, prioritize internet-facing hosts, and in the meantime inventory your MPTCP listeners, with attention to Go services that may have switched it on without anyone deciding to. Ranking the flaw correctly helps here, because the scores diverge: weighing CVSS against exploitability and signals like KEV is exactly the practice that tells you to move this one now.

The second problem outlasts this patch cycle. The economics of exploitation are shifting, and the unit of risk is the reachable path from an exposed service to root, not the isolated CVE. Knowing which services you actually expose, and how an attacker would chain from surface to impact, is what turns an advisory like this into a short list instead of a scramble. That continuous, risk-ranked picture of exposure is the premise Threatless CTEM is built on, from Threatless Surface on what you expose to Threatless DeepScan on what reaches deeper. Patch the kernel an attacker can reach today. Then plan for a world where the exploit for the next one shows up faster.