A critical, remotely reachable flaw in the Linux kernel’s IPv4 TCP code now has fixes rolling out, and admins need to plan reboots. Tracked as CVE-2026-98432 and rated CVSS 9.8 by the kernel CVE team and Red Hat, the bug is a use-after-free race that an unauthenticated attacker can trigger against any listening TCP port, and it has been present since Linux 4.4. Red Hat shipped fixed kernels for RHEL 8, 9, and 10 on November 1, 2026, Debian, SUSE, and Oracle Linux patched in October, but Canonical’s fixes for Ubuntu 22.04, 24.04, and 26.04 LTS are still in the opt-in -proposed testing pocket. Anthropic says an internal AI model already wrote a working remote root exploit. Here’s what’s affected, what to install, and why the commonly shared MPTCP workaround isn’t enough.
The Flaw: A Race in TCP Connection Setup
According to The Hacker News, when a server accepts an IPv4 TCP connection, the kernel passes IP options from the incoming request to the new socket without copying them. If the client retransmits its connection request while another CPU is still reading those options, the kernel can read memory it has already freed. An attacker triggers the race by sending connection requests carrying IPv4 Record Route or Timestamp options. No login is needed, and IPv6 isn’t affected on the main path.
Red Hat raised its rating from Moderate (5.9) to Critical (9.8) because the flaw can be hit remotely over ordinary IPv4 TCP traffic, with no local privileges or user interaction, leading to kernel memory corruption or a crash. Amazon Linux scored it lower at 8.1 (Important).
An AI-Written Exploit Already Exists
What makes this one stand out is how it was found. In an October 27 research post, Anthropic’s Frontier Red Team said an unreleased internal model wrote an exploit that lets a remote attacker run commands as root on Linux servers with a multipath TCP (MPTCP) listener, with no credentials or user interaction. In its proof of concept, leaking a kernel pointer took 48 minutes and reaching command execution took another 5 minutes. Crucially, a lost race only fails the handshake rather than crashing the box, so an attacker can retry indefinitely.
Anthropic has not published the exploit code. The Hacker News reports that proof-only code that triggers the race and detects leaked memory has appeared on GitHub, but it does not achieve code execution. No vendor or CERT has reported in-the-wild attacks, and the flaw was not in CISA’s Known Exploited Vulnerabilities catalog as of its latest update.
Where the Fixes Stand
- RHEL 8.10: kernel 4.18.0-553.182.1.el8_10 (RHSA-2026:93414).
- RHEL 9.8: kernel 5.14.0-687.64.1.el9_8 (RHSA-2026:93412).
- RHEL 10.2: kernel 6.12.0-211.72.1.el10_2 (RHSA-2026:93413).
- Ubuntu 22.04 / 24.04 / 26.04 LTS: 5.15.0-203.213, 6.8.0-149.149, and 7.0.0-43.43, available only in -proposed for now.
- Ubuntu 26.10: fixed in 7.3.0-10.10.
- Ubuntu 20.04, 18.04, 16.04: fix pending; older releases need Ubuntu Pro ESM.
- Debian, SUSE, Oracle Linux, Amazon Linux: fixes shipped in October.
Canonical says it tests kernel updates on more than 2,000 certified servers and devices before promoting them to the regular updates channel and has not given a date. Packages in -proposed don’t install automatically; admins who run their own kernel acceptance testing can enable the pocket and explicitly install the kernel meta-package from it, following the steps in Canonical’s blog post. Every fix requires a reboot.
Mitigations and What Not to Rely On
- Disabling MPTCP is not a fix: Canonical says turning off MPTCP alone is insufficient, and “The Ubuntu Security Team believes that security updates are the only appropriate mitigation.”
- Red Hat’s nftables rule: published October 30, it drops inbound IPv4 TCP packets carrying IP options. Red Hat says it is not a complete fix and may break workloads that use IPv4 options.
- Watch container traffic: a CIQ kernel engineer noted on oss-security that container-to-container traffic on the same host can bypass the host filter.
- Verify running kernels: compare uname -r output against the fixed versions above. A kernel installed but not booted is still vulnerable.
Why It Matters for IT Teams
Nearly every Linux server, appliance, and cloud instance accepts TCP connections, which makes the exposure huge even without confirmed exploitation. The AI angle raises the stakes: with a frontier model having already built a working root exploit, it’s reasonable to assume others will reproduce one. Prioritize internet-facing hosts, edge appliances built on Linux, and hypervisor or Kubernetes nodes, and check with appliance vendors about their kernel timelines.
Looking Ahead
Expect Canonical to promote its fixes to the regular updates channel once testing wraps, and watch for appliance and embedded vendors to publish their own advisories over the coming weeks. If exploitation is confirmed, a CISA KEV listing would likely follow quickly.
For now, patch RHEL and Debian-family systems that already have fixes, schedule reboots, decide whether your Ubuntu fleet should take the -proposed kernels or wait, and apply Red Hat’s packet filter as a stopgap where you can’t reboot yet. This is one to close out this week, not next quarter.
Sources:
- Canonical Ubuntu Blog, November 2, 2026
- Red Hat, November 1, 2026
- Anthropic, October 27, 2026
- The Hacker News, November 3, 2026
