TL;DR
- what: CVE-2026-98432 is a race-condition use-after-free in the Linux kernel's IPv4 TCP code, and an unreleased Claude AI model developed an exploit for it, according to Anthropic.
- impact: The exploit bypassed KASLR and ran commands as root on a server with an MPTCP listener in about 53 minutes, with no authentication required.
- fix: The flaw is fixed upstream and in maintained kernel branches, with Debian 12 fixed in 6.1.190-1 and Debian 13 in 6.12.113-1, while Ubuntu and RHEL fixes were still pending as of October 30 and CIQ published interim firewall guidance.
- who: Linux servers on kernels from 4.4 onward are in scope, with the greatest demonstrated risk on hosts running MPTCP listeners, including some Go services built with Go 1.24 or later.
A use-after-free in the Linux kernel's IPv4 TCP code, tracked as CVE-2026-98432, can give an unauthenticated remote attacker root on a server running a Multipath TCP (MPTCP) listener. Anthropic reported that an unreleased Claude AI model developed an exploit that bypassed kernel address space layout randomization (KASLR) and executed arbitrary commands as root, reaching code execution in about 53 minutes. The flaw dates back to kernel 4.4 and affects widely used distributions, including Ubuntu, Red Hat Enterprise Linux (RHEL) and Rocky Linux.
As of October 30, 2026, patch coverage was uneven. Debian and some other vendors had shipped fixes, while Ubuntu and RHEL fixes were still pending. There are no confirmed reports of exploitation in the wild.
The bug: a race in TCP connection handling
The Linux kernel advisory traces the flaw to a race condition in how the kernel processes TCP connection requests. The code hands a request socket's IP options to a new child socket without making a copy. The advisory states: "tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it."
The race opens when a second CPU works on the same request. Per the advisory: "Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req()." The functions tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, while ip_build_and_send_pkt() and ip_options_build() read opt->optlen twice. The result can be a use-after-free.
The advisory also describes a similar issue during TCP request socket migration, which applies when net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in use.
Two severity scores, one bug
The Linux kernel CVE team scored the vulnerability 9.8 out of 10. Red Hat scored it 5.9 and classifies it as a potential denial-of-service issue that could crash the kernel. Red Hat's reasoning is that triggering the flaw requires no authentication, but exploiting the race is more complex than sending a single malicious packet.
Anthropic's work shows that the outcome can go beyond a crash under specific conditions. Exploit complexity still matters, and the source reporting does not suggest the race is trivial to win. But a denial-of-service label does not describe the full demonstrated impact on MPTCP servers. Organizations that set patch priority from a single vendor score could assign this bug very different urgency depending on which score they use.
⚠️ What has and has not been demonstrated — Remote code execution has been publicly demonstrated only against a server running an MPTCP listener. The flaw also affects ordinary TCP connections, but remote code execution has not been publicly demonstrated on servers without an MPTCP listener. That is the absence of a public demonstration, not evidence that such an exploit is impossible.
MPTCP exposure may not be a deliberate choice
MPTCP lets a single connection use multiple network paths at once to improve performance and reliability. It is commonly used where devices have multiple network connections, such as Wi-Fi and cellular. Applications do not typically enable it by default, which might suggest the exposed population is small and easy to identify.
Go complicates that assumption. Beginning with Go 1.24, the language enables MPTCP by default for TCP listeners on Linux when the kernel supports the feature. Some Go-based network services may therefore run MPTCP listeners without administrators knowing. Exposure to the demonstrated attack path can follow from the toolchain a service was built with, rather than from a decision by the team operating it.
Patch status by vendor
The fix landed in the upstream kernel and was backported to maintained branches. Distribution status as of the October 30 reporting:
- Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 remain vulnerable, with kernel fixes in progress, according to Canonical's security tracker.
- Red Hat: RHEL 8, 9 and 10 are affected, with fixes planned for future updates. RHEL 7 is not affected because its kernel does not contain the vulnerable code.
- Rocky Linux: versions 8, 9 and 10 are affected, as confirmed by support provider CIQ.
- Debian: fixed in kernel package 6.1.190-1 for Debian 12 (Bookworm) and 6.12.113-1 for Debian 13 (Trixie). Fixed packages are also available for testing and unstable.
- Oracle Linux, Amazon Linux and SUSE: fixes have been released for some affected kernel versions.
- macOS: not affected, because it uses Apple's XNU kernel rather than the Linux kernel.
Vendor mitigation guidance
The permanent fix is an updated kernel package from the distribution vendor. For systems where one is not yet available, the published guidance is that restricting access to trusted networks or IP addresses can reduce the risk.
CIQ also recommends temporarily blocking IPv4 TCP packets that contain IP options before they reach the vulnerable TCP processing code, and it has published example nftables rules for this. The approach lines up with the advisory, whose race centers on the IP options data held in ireq_opt.
Disabling MPTCP is not a fix — CIQ cautions that disabling MPTCP alone is insufficient, because the underlying vulnerability can still be triggered through ordinary TCP traffic. Removing MPTCP takes away the condition used in the public exploit, but it does not remove the bug.
RedEye assessment
Three facts drive the risk here: no authentication is required, the affected kernel range goes back to 4.4, and fixes are unavailable on several major enterprise distributions. The lack of confirmed in-the-wild exploitation lowers immediate pressure, but publication of a working exploit path, even without public exploit code, tells other researchers and attackers that remote root is achievable.
The way the exploit was built also matters. A bug classified by a major vendor as a complex denial-of-service issue was turned into remote root by an AI model. This is one case, and the 53-minute figure and the exploit results come from Anthropic's own report. The coverage does not describe independent replication, and the specific conditions required limit how far the result can be generalized. Even so, it is a concrete data point against treating a difficult race condition as a crash-only risk.
For security and IT leaders, the open questions are where MPTCP listeners exist, including those inherited from Go 1.24 or later, and how long affected Ubuntu, RHEL and Rocky Linux systems will wait for vendor kernels. Internet-facing services carry the clearest exposure during that window, since the flaw can be triggered without credentials.
Originally published on RedEye Threat Intelligence.
Top comments (0)