Linux Kernel TCP Flaw Gets AI-Built Root Exploit

A Linux kernel TCP flaw now has a working remote root exploit, and an AI model built it. CVE-2026-98432 (CVSS 9.8) is a use-after-free in the IPv4 TCP handshake that has been in the kernel since version 4.4. As of November 2, Debian and Red Hat ship fixed kernels, Ubuntu still lists its fixes as work in progress, and we found no confirmed exploitation in the wild.

What Happened in the Linux Kernel TCP Flaw

When a TCP SYN packet carrying IPv4 options arrives, the kernel keeps a copy of the options with the pending connection and later hands it to the new socket without duplicating it. If a retransmitted SYN is processed on another CPU, it can read that memory after it was freed. The Linux kernel CNA scores the flaw at 9.8 (network, no privileges), and Red Hat now rates it Critical 9.8 as well.

On October 27, Anthropic researchers described an exploit against a host with an MPTCP listener that bypasses KASLR and runs commands as root. BleepingComputer cites about 53 minutes of model work. AWS says remote attackers could crash a system, read kernel memory or corrupt it, but remote code execution has only been shown against an MPTCP listener, and it is not aware of exploitation in the wild (bulletin updated November 1). Go 1.24 and later enable MPTCP by default for TCP listeners on Linux where the kernel supports it, so some services may offer it without anyone choosing that.

Patch status as of November 2: Debian 12 has 6.1.190-1 and Debian 13 has 6.12.113-1. RHEL 8, 9 and 10 received fixed kernels on November 1 (RHSA-2026:93412, 93413 and 93414). Canonical’s tracker lists Ubuntu 22.04, 24.04, 26.04 and 26.10 as work in progress. The flaw is not in the CISA KEV catalog as of the October 30 catalog version.

Why It Matters

The bug sat in the kernel for about ten years, and a working exploit now exists within days of disclosure. Assessment: the time between a kernel flaw becoming public and a usable exploit is shrinking, so patch deadlines for internet-facing Linux hosts that count in weeks are too slow.

Assumption: the technique is now described well enough that others will adapt it, and plain TCP listeners are also affected, even though remote code execution was only shown with MPTCP. Switching MPTCP off therefore narrows the demonstrated path but does not fix the bug. Only a kernel update plus a reboot does. If you fall under NIS2, unpatched internet-facing servers are a finding your auditors will ask about.

What You Should Do Now

1. Inventory first. List Linux hosts with internet-reachable IPv4 TCP listeners, check uname -r against your distribution’s tracker, and note which of them run Go services.
2. Patch and reboot. A new kernel does nothing until the machine restarts. On Debian and RHEL, install the fixed kernel now. On Ubuntu, watch Canonical’s tracker and plan the maintenance window in advance.
3. If you cannot reboot yet, AlmaLinux and AWS describe a stopgap: drop incoming IPv4 TCP packets that carry IP options, for example with an nftables rule matching meta l4proto tcp ip hdrlength > 5. Caveats from AlmaLinux: traffic between containers on one host bypasses it, it also drops forwarded traffic that uses IP options, and it is not suitable for CIPSO or NetLabel setups. Test first.
4. Turn off MPTCP where you do not need it: sysctl net.mptcp.enabled=0, or GODEBUG=multipathtcp=0 for Go 1.24 and later, then restart existing listeners (ss -lnMp shows them).

DIESEC Perspective

Kernel flaws are easy to postpone because the fix needs a reboot and a reboot needs a window. Decide now who may reboot an internet-facing Linux host on short notice, and make that part of your patch policy instead of a case-by-case discussion.

Not sure which of your Linux servers are exposed? Contact DIESEC for an exposure review and patch verification.

Sources: AlmaLinux advisory | AWS bulletin | Debian tracker | Ubuntu tracker | BleepingComputer
Published: 2026-11-03 | Category: Vulnerabilities & Patches | ~4 min read