Blog · 2026-10-29 (updated 2026-11-02) · Gardience Engineering

CVE-2026-98432: the 9.8 Linux TCP bug an AI turned into remote root

A use-after-free in the Linux kernel's IPv4 TCP handshake, rated 9.8, that Anthropic says an unreleased Claude model turned into a zero-click root exploit. Which distributions have a fix, which do not yet, and what to do on each.

CVE-2026-98432 is a race condition in the Linux kernel code that sets up new IPv4 TCP connections: memory can be freed while the kernel is still using it (a use-after-free). The fix went into the upstream kernel in early October and the CVE was published on October 15. The kernel's own CVE team rates it 9.8 out of 10.

Then this week Anthropic said an unreleased Claude research model had turned it into a zero-click remote root exploit against Linux servers running a multipath TCP listener: about 48 minutes to leak a kernel address and get past the kernel's memory randomization, then about five more minutes to run commands as root. No login, no user action.

Two facts keep this in proportion. The exploit was built in a lab, and the bug is not known to be used in attacks and is not in CISA's Known Exploited Vulnerabilities catalog. But the hard part, turning a kernel bug into working code, has now been shown to be something a model can do, and the bug has been public for two weeks.

Who has a fix#

Upstream fixed it in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Distributions ship their own builds, so your distribution's package is what counts. As of November 2:

Rocky Linux, AlmaLinux and Oracle's Red Hat-compatible kernel follow Red Hat's fixes, which shipped on November 1. Red Hat raised its own rating to Critical, 9.8 on October 30 and published a security bulletin (RHSB-2026-016). Amazon still rates it 8.1, because winning the race is harder than the 9.8 assumes.

Sources: Debian, Ubuntu, Red Hat, Red Hat's bulletin, Amazon Linux, Anthropic's post.

What to do on each server#

Where a fix exists (RHEL and its rebuilds, Debian, Oracle UEK, Amazon Linux, SUSE Micro and Leap): install the new kernel and restart. The restart is the step that protects you: until the machine boots the new kernel, the old one is still running.

sudo apt update && sudo apt install --only-upgrade linux-image-amd64   # Debian (linux-image-cloud-amd64 on cloud images)
sudo dnf upgrade kernel                                                # RHEL, Rocky, AlmaLinux, Oracle Linux, Amazon Linux 2023
uname -r                                                               # after the restart: the new version

Where no fix exists yet (Ubuntu, as of November 2): there is nothing to install today. Do three things:

1. Find out whether anything listens over multipath TCP, the case Anthropic's exploit used. ss -lnM lists multipath TCP listening sockets. Most servers have none: an application has to ask for multipath TCP explicitly.
2. Keep the kernel otherwise current, so the fix is one update away when it lands.
3. Watch your distribution's page for the fix and patch the day it appears.

Be careful with quick fixes you see suggested, such as turning multipath TCP off with sysctl net.mptcp.enabled=0. The bug itself is in the ordinary IPv4 TCP handshake code. Anthropic's post ties the working exploit to a multipath TCP listener, but neither it nor any vendor advisory says that turning multipath TCP off removes the risk, and Red Hat calls patching the only complete solution. Treat it as reducing exposure, not as a fix.

Red Hat's bulletin does offer one stopgap for machines that cannot be patched yet: an nftables rule that drops incoming IPv4 TCP packets carrying IP options (ip protocol tcp ip hdrlength > 5 counter drop). Red Hat says it may disrupt traffic that needs IP options, to test it first, and to remove it once the kernel is updated.

Why the restart matters more than ever#

Package scanners, including most vulnerability tools, look at what is installed. After apt upgrade or dnf upgrade, a server reports the fixed kernel package, and the scan turns green, while the old kernel keeps running until someone schedules the restart. On a fleet, that gap can last weeks.

On a fleet, the hard part is making sure every server actually restarts onto the fixed kernel. Gardience 1.19 checks the kernel each Debian and Ubuntu machine is actually running, not just the one installed, and marks every Linux machine whose newest kernel is not running yet as restart needed. It ranks the CVEs on your machines by whether they are being exploited (CISA's catalog) and how likely they are to be (FIRST's EPSS score). Then the Patch, reboot, wait, verify workflow installs the update, restarts each machine, and waits until it is back before the run counts as done, inside your change windows, with every machine's result in the audit log.

Questions#

Is CVE-2026-98432 being exploited?#

Not as of November 2. The known exploit was built in Anthropic's lab, and the bug is not in CISA's Known Exploited Vulnerabilities catalog (catalog of October 30). That can change quickly: the bug and its fix have been public since mid-October.

Am I affected if I do not use multipath TCP?#

The bug is in the IPv4 TCP handshake code that every Linux server uses, so install the fix when your distribution ships it either way. The published zero-click exploit needs a multipath TCP listener; whether other paths are practical has not been shown.

Why do the ratings differ?#

Red Hat first scored the attack as harder to pull off (a race that must be won), and Amazon still does (8.1). The kernel CVE team's 9.8 assumes it is easy. On October 30 Red Hat raised its own rating to Critical, 9.8: Anthropic's lab exploit showed that "harder" does not mean "impractical".

Is this the same as PwnEscape?#

No. PwnEscape (CVE-2026-99999) lets a virtual machine take over its Linux host. It cannot be reached from the network. On RHEL and Debian, the current kernel update fixes both.