Anthropic Showed a Remote Root Exploit for a Linux TCP Bug. Ubuntu Has No Fixed Kernel Yet. Here Is What Protects You Until It Does.
If you run Linux servers that accept connections from the internet, CVE-2026-98432 is the patch to chase this week. It is a use-after-free in how the kernel handles IPv4 TCP connection setup, and Anthropic published a write-up showing an unauthenticated attacker going from a connection request to a root shell on a server with an exposed multipath TCP listener. Nobody has reported attacks in the wild, and it is not in CISA's Known Exploited Vulnerabilities catalog as of the sources we read. Ubuntu had not shipped a fixed kernel as of November 2.
A disclosure from us: Anthropic makes Claude, which we use to help write these posts. We read the reporting below, not Anthropic's post itself, and the facts here are only as good as that reporting.
What the bug is
The flaw sits in IPv4 TCP connection handling and dates back to Linux 4.4. The trigger is a TCP connection request carrying IPv4 Record Route or Timestamp options, resent to win a race. IPv6 is not affected by the main race. A lost race fails only that attempt and does not crash the machine, so an attacker can try again.
Anthropic's reported test took 48 minutes to leak a kernel address and about five more to run a command as root. Anthropic has not published the exploit code. CloudLinux says its kernel team could not reproduce Anthropic's claim, so treat the 53 minutes as one vendor's demonstration, not a measured attack rate.
Why the severity scores disagree
The same bug carries very different numbers depending on who scored it:
9.8: the kernel CVE team, with attack complexity rated low. NVD and Ubuntu show the same.
8.1: Red Hat's advisory file, Oracle and SUSE, with attack complexity rated high.
7.0: Amazon.
5.9: Red Hat's public CVE page, which called it Moderate because the race is hard to win.
The difference is how hard the race is to win in practice, and nobody has published an attack rate. Do not read the lowest score as permission to wait.
Is MPTCP the problem?
Anthropic's exploit needed an exposed multipath TCP listener. The kernel's own fix does not mention MPTCP, and the Go Security Team says systems with no MPTCP listeners may still be vulnerable. MPTCP is disabled by default on Enterprise Linux and CloudLinux, according to CloudLinux, which says the known exploit chain is not reachable there in the default configuration. Go 1.24 and later enable MPTCP by default on the sockets Go programs listen on, so a Go service can put a listener in play without anyone choosing it.
Where patching stands
As of the November 2 update to the status table we read:
Fixed: Debian 12 and 13, RHEL 8, 9 and 10 (released November 1), AlmaLinux 8, Oracle Linux 7 through 10, and Amazon Linux 2023 on the 6.18 kernel. RHEL 7 is not affected.
In testing: AlmaLinux 9 and 10.
Pending: Ubuntu 22.04, 24.04, 26.04 and 26.10, with no date given. Ubuntu 16.04, 18.04 and 20.04 are vulnerable with no fix released.
Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distribution kernels carry their own version numbers, so compare against your vendor's advisory, not those numbers. The kernel team says to move to the latest stable kernel and does not support cherry-picking the individual fix.
What to do
Patch where a fixed kernel exists, and reboot. A fix is not live until the new kernel is running, or a live patch is applied.
If you run Ubuntu, you are waiting. Reduce exposure now instead.
Turn MPTCP off if you do not need it. CloudLinux recommends setting the kernel setting net.mptcp.enabled to 0 until you are patched.
For Go services, the Go team's workaround is setting the environment variable GODEBUG to multipathtcp=0. They call it fragile and recommend patching.
Consider dropping incoming IPv4 TCP packets that carry IP options at your network edge. Red Hat's bulletin describes a rule like this. Red Hat says it reduces exposure but does not fully prevent exploitation, and it may break some workloads. Test before you roll it out.
Watch for exploitation. The trigger is unusual, since normal traffic rarely carries Record Route options, so a spike of such packets at a server's public address is worth a look.
What we do about it, and what we cannot
We are not a news site, so here is where we stand on this one, as of this writing.
The feed has nothing to block yet. Nobody has published attacker infrastructure for this bug, so there is no IP, domain or hash to put in a blocklist. If exploitation is reported with indicators, we ingest them the same day and add a dated update to this post.
Our edge cannot see it. The edge shield in front of our sites inspects web requests. A malformed TCP handshake happens below that layer, so no web application firewall, ours or anyone's, is the fix here. The kernel update is.
We watch the catalog. Our corpus syncs CISA's KEV list daily, and a check today shows this CVE is not listed.
Public exploit repositories exist. Our exploit harvester has collected three public GitHub repositories named for this CVE. We have not run or vetted them and we are not linking them. A repository claiming to be a kernel root exploit is a classic lure for malware, so do not run one on a machine you care about.
Protecting you is the job. For this bug, protection today means a kernel update or the mitigations above, and the free API key for our blocklist feed will carry the indicators the day there are any.
Limits
Everything about the bug, the patch table and the mitigations comes from two secondary articles, updated October 30 and November 2. We did not read Anthropic's write-up, the kernel CVE record or any vendor advisory, so confirm your distribution's fixed version with your vendor. The October 30 article lists RHEL as unfixed and the November 2 one says fixed RHEL kernels shipped November 1, so check Red Hat's page before you rely on that date. The monitoring suggestion in the last step of the list above is ours, not Red Hat's or Anthropic's.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments