SURIQ
The scary part of CVE-2026-98432 is not the 9.8 score. It is that the precondition Anthropic named for its remote root exploit, a server holding a multipath TCP (MPTCP) listener, is the default for a large slice of modern server software. Since Go 1.24, every Go program that opens a listening socket on Linux asks the kernel for MPTCP unless someone switched it off. And on Ubuntu and Red Hat Enterprise Linux (RHEL), two of the most widely deployed server distributions, there was still no patched kernel package as of October 29.
So the useful question for an operator this week is narrower than "am I on Linux". It is: which of my hosts run an unfixed kernel, and which of those expose a listener that negotiates MPTCP? Those are the machines to deal with first.
What CVE-2026-98432 is, in plain terms
CVE-2026-98432 is a use-after-free (code that keeps reading memory after it has been released) in the Linux kernel's IPv4 TCP handshake code. When the kernel turns a half-open connection into a full socket, it hands the connection's IP options to the new socket instead of copying them. If a retransmitted connection request is being handled on another CPU core at that moment, that core can still read the options after they have been freed. A similar race exists in the request-migration path.
The CVE record, published October 15 by the kernel's own CVE team, scores it 9.8 (critical): network-reachable, no login, no user interaction. Red Hat's assessment is 8.1 and rates it Important, because it judges the race hard to win. The upstream fix, commit e3f33b0a1d89, delays freeing those option buffers until no other core can still be holding a reference.
The story changed on October 27, when Anthropic published research saying an unreleased Claude model had built a proof-of-concept exploit that runs commands as root on a Linux server with an MPTCP listener, with no credentials. Per Anthropic's write-up, a lost race only fails one handshake rather than crashing the machine, so an attacker can keep retrying; it reports about 48 minutes to leak a kernel address and roughly five more to reach command execution. Anthropic has not published the exploit.
Why the MPTCP condition is wider than it sounds
MPTCP is opt-in on Linux: an application has to request it when it creates a socket. That makes "servers with an MPTCP listener" sound like a niche. It is not, because of one language runtime.
On October 29 the Go security team warned Go developers that since Go 1.24, Go programs turn MPTCP on by default for listening sockets on Linux. Reverse proxies, API gateways, exporters, control-plane agents and plenty of in-house services are written in Go. Any of them built with Go 1.24 or later, running on a kernel where MPTCP is enabled (the kernel's documented default), matches the configuration Anthropic attacked.
Two caveats keep this honest. First, the Go team stresses that the bug itself is not specific to MPTCP, and Red Hat describes any reachable TCP service as a possible trigger. Turning MPTCP off removes the demonstrated path, not the bug. Second, the Go team calls a per-program opt-out fragile, since one forgotten listener is enough, and it says changing Go's default would be premature. Patching the kernel is the fix every primary source points to.
Who has a patched kernel today
The upstream fix is in every maintained stable branch. Distribution packages are where the gap sits.
| Kernel source | Status for CVE-2026-98432 |
|---|---|
| Upstream stable | Fixed 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 |
| Debian 12 (bookworm) | Fixed in linux 6.1.190-1 (DLA-4841-1) |
| Debian 13 (trixie) | Fixed in linux 6.12.113-1 (DSA-6568-1) |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | No fix released, work in progress |
| Ubuntu 16.04, 18.04, 20.04 | Vulnerable, no fix released |
| RHEL 8, 9, 10 | Affected, no fix released, no mitigation Red Hat endorses |
| RHEL 6, 7 | Not affected |
The affected range starts at kernel 4.4. The Debian tracker lists bookworm fixed in 6.1.190-1 and trixie in 6.12.113-1. Ubuntu's tracker rates it High priority and shows no released fix for any supported release; 22.04 through 26.10 are marked work in progress, while 16.04, 18.04 and 20.04 are simply vulnerable. Red Hat's machine-readable advisory lists RHEL 8, 9 and 10 plus OpenShift 4 as affected with no fix available, and RHEL 6 and 7 as not affected. The Hacker News' roundup also reports fixed kernels for Oracle Linux UEK, Amazon Linux 2023 (kernel 6.18) and some SUSE releases, with others still in testing, so check your own vendor's page rather than assuming.
Exploitation status: as of October 29 no vendor, the CVE record or Anthropic reported attacks using this flaw, and it was not in CISA's Known Exploited Vulnerabilities (KEV) catalog. A third-party GitHub repository created on October 30 publishes race-trigger and memory-leak tooling for lab use; its own README says it stops short of code execution. We have not tested it, and it does not change the advice, but it does mean the race is now being worked on in public.
Find the MPTCP listeners on unpatched hosts first
Kernel CVEs are the background noise of Linux operations. Linux kernel records were the single largest product in our own intel ledger over the last 90 days: 1,607 of them, more than double Chrome's 757. Almost all of that volume waits for the next maintenance window. This one should not, because it is reachable over the network with no account, and on Ubuntu and RHEL the patch you would normally install does not exist yet.
The exposure check takes a minute per host. Confirm the running kernel against the fixed versions above or your vendor's tracker, list sockets that negotiated MPTCP, and read the two sysctls that gate the risky paths:
uname -r ss -Mltnp sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req sysctl -w net.mptcp.enabled=0 echo 'net.mptcp.enabled = 0' > /etc/sysctl.d/90-cve-2026-98432.conf GODEBUG=multipathtcp=0
Any process listed by ss -M on an unfixed kernel is your priority list. Setting net.mptcp.enabled to 0 makes the kernel refuse to create new MPTCP sockets; restart the services that held MPTCP listeners and run ss -M again to confirm they are gone. If you only want to change Go services, the Go team's documented switch is the GODEBUG=multipathtcp=0 environment variable on the service (or godebug multipathtcp=0 in the program's go.mod at build time). Test before rolling it out widely: software that genuinely depends on MPTCP will lose it.
The Ubuntu tracker also names the request-migration path, enabled by net.ipv4.tcp_migrate_req=1 or a reuseport migration BPF program, as carrying a similar race. It is off by default; if you turned it on, consider turning it back off until the kernel is fixed. None of this is a vendor-endorsed mitigation, and Red Hat states plainly that it has none that meets its bar. Treat it as shrinking the attack surface while you wait.
Schedule the reboot, not just the package
A kernel fix only takes effect after a reboot (or a live patch, if your vendor ships one for this CVE). The common failure with network-reachable kernel bugs is a fleet where the new package installed weeks ago and uname -r still reports the old version. When Ubuntu and Red Hat publish their packages, plan the reboot window the same day and recheck uname -r afterwards. Tracking which hosts are still on an unfixed kernel is a fleet inventory problem; our vulnerability detection page covers how we approach it.
One more thing worth sitting with. Anthropic's write-up describes a model turning a race-condition kernel bug into a working remote root exploit in under an hour of runtime. Whatever you think of the claim, the gap between "kernel CVE published" and "someone has a working exploit" is shrinking, and the October 15 disclosure was already twelve days old when the exploit was announced. Remote, unauthenticated kernel bugs deserve their own fast lane in patch policy, separate from the steady stream of local ones. We made a similar argument about the container escape in CVE-2026-53362, and this flaw makes it with higher stakes.