CVE-2026-98432: Ubuntu and RHEL Still Without Patches as Anthropic Reports AI-Built Linux Root Exploit

Update, 4 November 2026: Red Hat has since released fixed kernels for RHEL 8, 9 and 10 (RHSA-2026:93414, RHSA-2026:93412 and RHSA-2026:93413, all dated 1 November), and Oracle Linux and AlmaLinux 8 have followed. As of 4 November, Ubuntu’s fixes for 22.04 through 26.10 are built but not yet released, and AlmaLinux 9 and 10 have not shipped a fixed kernel. Current distribution-by-distribution status, with each advisory, is on our Linux patch status tracker.

A use-after-free in the Linux kernel's IPv4 TCP handshake code — rated CVSS 9.8 Critical by the kernel's own CVE Numbering Authority — had no patched kernel package from Ubuntu or Red Hat Enterprise Linux as of the source timestamps cited below, more than two weeks after upstream kernel maintainers shipped fixes. Anthropic reported on October 27 that its Claude model built a working proof-of-concept exploit targeting Linux servers with a multipath TCP (MPTCP) listener in a controlled lab setting, raising the remediation priority for operators waiting on their distribution vendors.

What the vulnerability is

CVE-2026-98432, formally titled "ipv4: free inet_opt and ireq_opt after an RCU grace period," was reported by Xinyang Ge of Anthropic and fixed by kernel networking maintainer Eric Dumazet. The bug has existed since Linux 4.4, introduced in October 2015 by a performance optimization in the IPv4 TCP stack. The Atlas writeup — the most detailed technical summary available — and Ubuntu's security tracker both describe the mechanism: when a Linux server accepts a TCP connection, the kernel tracks the half-open handshake in a lightweight "request socket," then promotes it to a full socket once the three-way handshake completes. If the connecting peer's IPv4 header carries options, the kernel retains those options to echo in its replies. The bug is that the kernel handed those saved options from the request socket to the new connection without copying them, then freed the memory when the request socket was torn down — while another CPU could still be reading those options to build a SYN-ACK reply for a retransmitted SYN.

The result is a classic use-after-free: two CPU cores processing related but distinct packets share a pointer to memory that one of them has already freed. Per the kernel CNA's scoring notes (cited in the Atlas writeup), stale data can leak kernel heap contents back to the remote peer, cause out-of-bounds kernel writes, or crash the host. IPv6 connections are not affected by this specific issue, per both the fix commit and Ubuntu's tracker.

The fix is a four-line change: two plain kfree() calls in tcp_v4_reqsk_destructor in net/ipv4/tcp_ipv4.c are replaced with kfree_rcu(), which defers the free until every RCU reader has released the memory. Other code paths that already replaced IP options had used kfree_rcu() correctly; this path did not.

Upstream kernel status: fixed, with specific release dates

Upstream stable and longterm kernel branches shipped the fix in two waves. According to the Atlas writeup:

Kernel branches older than 5.10 reached end-of-life upstream and will not receive a fix from kernel.org; any fix for distributions that ship those lines must come from the distribution itself.

To identify whether the fix is in the running kernel — not merely installed — the Atlas writeup points to the key indicator: check net/ipv4/tcp_ipv4.c within tcp_v4_reqsk_destructor for kfree_rcu in place of kfree. For operators without source access, comparing the running version against distribution advisories is the practical path.

Distribution status

Distribution kernels carry backported fixes under their own package version numbers, which differ from the upstream numbers above. The gap between upstream and distro is where most production systems sit.

Ubuntu: The Ubuntu security tracker, last updated 30 October 2026, listed every active Ubuntu release as "Vulnerable" or "Vulnerable, work in progress." Ubuntu 22.04 LTS (Jammy), 24.04 LTS (Noble), 26.04 LTS (Resolute), and 26.10 (Stonking) were all marked vulnerable with fixes in progress. No fixed kernel package had shipped for any Ubuntu release as of that page timestamp. Ubuntu rates the bug High severity internally, below the kernel CNA's Critical rating.

Red Hat Enterprise Linux (RHEL): Per the Red Hat CVE page and the Rescana advisory (which reflects checks as of 29 October 2026), Red Hat rates CVE-2026-98432 Critical (CVSS 9.8), raised from Important (8.1) on October 30. RHEL 8, 9, and 10 are listed as affected with no fixed kernel package released. Red Hat has published mitigation guidance in bulletin RHSB-2026-016. AlmaLinux, which tracks RHEL, had fixed kernels in testing but not yet released.

Amazon Linux: All kernels are fixed, according to the Atlas writeup. Amazon Linux 2023 received fixes via ALAS2023-2026-3251 (kernel6.18, October 24), ALAS2023-2026-3335 (kernel6.12, October 29), and ALAS2023-2026-3365 (the default kernel, October 30). Amazon Linux 2 core and its 5.4, 5.10, and 5.15 Extras kernels were fixed October 30 (ALAS2-2026-4065 and related advisories). Amazon rates the bug Important, CVSS 8.1. EC2 instances running Amazon Linux 2 or 2023 that have applied those specific advisories and rebooted are no longer vulnerable; instances that have not applied the updates remain exposed.

Debian: The Aviatrix research page cites Debian Security Advisory DSA-6568-1 (linux 6.12.113-1) as verified. The Atlas writeup notes Debian has fixed kernels available; check the Debian security tracker for current status.

SUSE: SUSE Linux Enterprise Server 16.0 and the 15 LTSS releases have fixes available. SUSE rates the bug "important."

Oracle Linux: Fixed in Oracle's Unbreakable Enterprise Kernel (UEK) since October 16, per Oracle's UEK errata page, covering Oracle Linux versions 7 through 10 (ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399). Oracle rates the bug Important, CVSS 8.1.

NVD/CISA KEV: The NVD record was listed as "Received" with no independent analysis as of the Atlas writeup's 5:15 PM CDT October 31 timestamp. The vulnerability does not appear in the CISA Known Exploited Vulnerabilities catalog. There is no confirmed in-the-wild exploitation reported by any vendor or government body.

The Anthropic exploit and the Go MPTCP default

On October 27, Anthropic's Frontier Red Team reported that Claude built a remote root proof-of-concept exploit for the vulnerability in a lab setting, targeting Linux servers with a multipath TCP (MPTCP) listener, with no credentials required. According to details cited in the Atlas writeup from Anthropic's own research publication, the proof-of-concept takes approximately 48 minutes to leak a kernel pointer and another five minutes to reach shell command execution. The Atlas writeup notes that "a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." Anthropic has not published the exploit.

A practical amplifier: on October 29, the Go Security Team announced that Go programs have opened MPTCP listeners by default since Go 1.24, where the operating system supports it. The Atlas writeup confirmed this on October 31, noting that ss -Mlnp listed a Go HTTP server whose go.mod specifies go 1.24 as an MPTCP listener, while the same server built with Go 1.23 was not. This makes MPTCP listeners more common than operators may assume — any host running a recent Go service may have one active.

That said, the vulnerability is not limited to MPTCP. The Atlas writeup and the HN discussion both note it is a generic IPv4 TCP handshake race, reachable through any listening TCP port when IP options are present in the SYN packet. MPTCP is the exploit path Anthropic demonstrated in the lab; it is not the only path. One Hacker News commenter noted that most ISP routers drop packets with IP options, which reduces — but does not eliminate — internet-facing exposure. Successful exploitation also requires the target system to have multiple CPU cores available to process packets concurrently; the HN thread notes single-core systems or those with packet processing pinned to a single core are not affected by this specific race.

What operators should check now

Step 1: Identify your running kernel.

uname -r # running kernel version
uname -v # Debian: includes package build version
dpkg -l 'linux-image*' | grep ^ii # Debian/Ubuntu: installed kernel packages
rpm -q kernel # RHEL and derivatives: installed kernels
needs-restarting -r # RHEL (dnf-utils): whether a reboot is needed

Run these on the container host or Kubernetes node, not inside a container. A container reports the host's kernel; updating a container image does not change what kernel it runs on. Compare your result against your distribution's advisory, not against the upstream version numbers above — distribution kernel version numbering is independent.

Step 2: Check for MPTCP listeners.

ss -Mlnp # MPTCP listening sockets and owning processes
sysctl net.mptcp.enabled # 1 = applications may open MPTCP sockets

ss -M lists only MPTCP sockets; an empty result means no active MPTCP listener. net.mptcp.enabled = 1 alone does not create a listener — an application must open an MPTCP socket. If you run Go 1.24 or later services, treat MPTCP listeners as likely until confirmed otherwise.

Step 3: If you cannot patch immediately.

For systems running Ubuntu or RHEL where no patched kernel is yet available, interim measures may reduce exposure:

• Disable MPTCP system-wide (addresses Anthropic's demonstrated lab exploit path, not the underlying bug):

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0
sudo ss -Mlnp # MPTCP sockets opened before this change remain; restart their services

According to the Atlas writeup, this setting is per network namespace, and each new namespace starts with MPTCP enabled. To disable it in Docker containers, Atlas notes that passing --sysctl net.mptcp.enabled=0 disables it per container. The Go Security Team, as cited in Atlas, calls per-program mitigation via GODEBUG=multipathtcp=0 "a fragile mitigation" and not a substitute for the system-level setting.

• Drop TCP packets with IPv4 extended options at the firewall (may reduce exposure to the generic attack path; not a complete mitigation per Red Hat's bulletin RHSB-2026-016):

# iptables rule to drop TCP packets carrying IPv4 extended header options
-A INPUT -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

A UFW equivalent can be added to /etc/ufw/before.rules. The Rescana advisory frames inbound IPv4 options filtering as a possible reduction in exposure. Red Hat's bulletin confirms that dropping IP options may help but is not a complete mitigation. The Atlas writeup notes additional limitations with bridged container traffic and CIPSO. One HN commenter who deployed this rule reported that match counters on public-facing VPSes had not incremented, which they attributed to ISP-level IP options filtering being common — though not universal.

Step 4: Patch and reboot.

Installing a fixed kernel does not take effect until the host reboots. On container hosts and Kubernetes nodes, the reboot propagates the fix to all containers running on that host. Appliances and cloud images that bundle a kernel need their vendor's specific update.

Exploitation status and KEV

As of the Atlas writeup's 5:15 PM CDT October 31, 2026 timestamp and the Red Hat page captured November 1:

• No confirmed in-the-wild exploitation has been reported by any vendor, CISA, or security researcher.
• No CISA KEV listing. CISA has not added CVE-2026-98432 to its Known Exploited Vulnerabilities catalog.
• Proof of concept exists in a controlled lab setting, built by Anthropic's Claude. Anthropic has not published it.
• NVD has not completed analysis of the CVE record; it remains in "Received" status.
• Red Hat's upgrade from Important to Critical on October 30, combined with its issuance of a dedicated bulletin, reflects its own assessment that the race condition is exploitable enough to warrant Critical severity, even as it characterizes reliable arbitrary code execution as requiring "precise heap control."

The combination of a demonstrated lab exploit, Go 1.24's default MPTCP behavior (per the Go Security Team), and patched Amazon Linux alongside still-vulnerable Ubuntu and RHEL creates an uneven exposure landscape. Operators running Ubuntu or RHEL on internet-facing infrastructure should treat this as an active remediation priority — and apply interim mitigations until a distribution kernel update ships.

Primary sources: Atlas CVE-2026-98432 writeup (updated through October 31, 2026, 5:15 PM CDT); Ubuntu security tracker (last updated 30 October 2026); Red Hat CVE page and RHSB-2026-016; Oracle Linux UEK CVE page; Amazon Linux CVE page; Rescana advisory (updated 31 October, technical details reflect 29 October checks); upstream fix commit: torvalds/linux on GitHub; CVE record: cve.org.