Linux kernel CVE-2026-98432: why switching off MPTCP won't save you, and what to patch

A flaw in the code every Linux server uses to accept IPv4 connections scores 9.8 out of 10, and researchers have already built a working root exploit for servers with an MPTCPdefinitionMultipath TCP, which lets one connection use several network paths. Anthropic's exploit used it, but the bug doesn't depend on it. listener. Install your distribution's fixed kernel and reboot, starting with anything the internet can reach. If your distribution has no fix yet, as with Ubuntu 20.04 and older, put a packet filter in front of it today. OpenShift 4.22 now has a fixed release, 4.22.22, and other OpenShift versions are still waiting.

A rooted Linux server is rarely the end of the story. Whatever that machine can reach, the attacker can now reach: its service account keys, TLS private keys, database passwords in config files, cloud role credentials and vault tokens. On a Kubernetes node, add every pod that runs there. So the cost of this one tends to be a long credential rotation on top of a rebuild, and that's the part most patch tickets don't budget for.

How likely is an attack? Here's what we can actually say. CISA hasn't listed it as exploited, Fortinet's advisory marks known exploitation as no, and our own searches found no confirmed reports. Ubuntu's write-up says Anthropic's exploit is unreleased and that no other exploit was known when Ubuntu wrote it. That's a snapshot, and quiet attacks don't show up in catalogs. The detail that bothers us is in Anthropic's write-up: losing the race only fails that one handshake and doesn't crash anything, so an attacker can just keep retrying.

You'll also see wildly different severity labels, and they aren't all talking about the same risk. Red Hat and Ubuntu call it critical. Amazon, SUSE and Oracle rate it important, and their 8.1 scores count the attack as harder to pull off. Google labels its bulletin medium. BleepingComputer reported that Red Hat first scored it 5.9, though Red Hat's page now says 9.8. If your scanner took the lower number, the ticket may be sitting in the wrong queue.

For engineers: the fix is commit e3f33b0a1d89, "ipv4: free inet_opt and ireq_opt after an RCU grace perioddefinitionA kernel waiting period that lets every CPU finish reading shared data before it gets freed. The fix makes these options wait for it.". tcp_v4_syn_recv_sock() hands ireq_opt to the child socket without copying it, and inet_sock_destruct() then frees it with a plain kfree() while tcp_v4_send_synack() may still be reading it under rcu_read_lock(). The fix moves those frees to kfree_rcu(). There's a second route through request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF reuseport migrate program), which AlmaLinux notes is off by default. IPv6 isn't affected by the main race, because it duplicates the options.

MPTCP still decides who goes first, though. Since Go 1.24, Go programs turn on MPTCP by default for listening sockets on Linux, where the kernel allows it. So a host that has MPTCP enabled and runs an internet-facing Go service matches the setup Anthropic described, and the team that owns it may have no idea. Run ss -lnMp to see which MPTCP listeners exist. The Go team calls disabling it per program a fragile fix, because one forgotten listener undoes the work, and it assumes every exploit needs MPTCP.

Containers change the picture too, and this is easy to miss. Google's bulletin says an unprivileged process in a container can trigger the flaw locally without CAP_NET_RAW, and that the result can be a kernel panic or a container escape to root on the node. Google's rating is for GKE, but containers share the host's kernel everywhere, so rebuilding your images won't fix anything. If you run other people's code on shared nodes, those nodes move up your list even when no port faces the internet.

Patch status is the messy part, because the fix depends entirely on who built your kernel. The upstream version numbers below don't help if you run a distribution kernel, since those keep their old version numbers and backport the fix. Check your distribution's list instead of comparing against kernel.org. If you run OpenShift 4.22, the 4.22.22 update also fixes the Brotli decoder flaw that CISA lists as exploited, which we cover in our Brotli post.

Ubuntu needs its own note, because its archive has moved ahead of its web pages. Canonical's blog still says the fix for 22.04 and newer is in the opt-in -proposed pocket, and its CVE page, last updated November 5, still reads vulnerable, work in progress. But Launchpad shows the generic kernels for 22.04, 24.04 and 26.04 published to the regular updates pocket by early November 6 UTC. So apt upgrade should bring them in, as long as that pocket is enabled. They aren't in the security pocket yet, so automatic updates limited to security won't pick them up. Some builds lag behind: the Azure, Oracle and 22.04 HWE kernels were still in -proposed when we checked. Releases 16.04 to 20.04 still have no fix.

Not to be confused with CVE-2026-46300, a different kernel bug that CISA did add to its exploited list in October, and which it says can be chained with the PHP2Shell flaws. Two kernel CVEs in the news at once makes it easy for a ticket to get closed against the wrong one. Check that your change record names this number.

# example output. Your version strings won't match ours, so don't compare against this line
$ uname -r
5.14.0-687.64.1.el9_8.x86_64    # compare with your distribution's fixed version
$ sysctl net.mptcp.enabled
net.mptcp.enabled = 0
$ sudo ss -lnMp    # any MPTCP listeners still open?
# Red Hat's stopgap filter, saved as cve-2026-98432.nft. It doesn't survive a reboot unless you make it persistent
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
$ sudo nft --check --file cve-2026-98432.nft
$ sudo nft --file cve-2026-98432.nft
$ sudo nft list table inet cve_2026_98432    # check the counter. It tells you if the rule actually dropped anything
$ sudo nft delete table inet cve_2026_98432    # once you're on the fixed kernel

A few warnings on that filter. Red Hat says it reduces exposure but can't fully prevent exploitation, and it asks you to test it first. It only sees traffic crossing the host's own network stack, so traffic between containers on the same host can get past it. On OpenShift, Red Hat says pod-to-pod traffic isn't covered and has no mitigation for that yet, so a fixed kernel is still the only full answer there. For 4.22 that means 4.22.22. Whether outside traffic forwarded to pods gets filtered depends on your network setup, while filtering at the boundary in front of the cluster avoids those limits. AlmaLinux adds that you shouldn't use this filter if your network relies on CIPSO security labels, which travel in IPv4 options.

You'll also find an extra suggestion doing the rounds: the boot setting init_on_free=1. Someone proposed it on the oss-security mailing list, and a member of CIQ's kernel team replied that it doesn't do anything meaningful here, because the leak comes from live memory rather than freed memory. The reply called it harmless, but said it shouldn't carry weight in advisories. We'd skip the reboot for it and spend that reboot on a fixed kernel if you can get one.

This bug lives below every control most teams rely on: below the app, the login and the web firewall rule. What limits the damage is how few machines can be reached, how quickly you can reboot them, and how little a single server holds. Those are worth fixing whichever kernel CVE comes next.

Short-lived credentials pay off the most here, since they shrink the worst day. If a host's secrets come from something like HashiCorp Vault and expire in hours, a rooted machine gives an attacker far less to carry away. We've no reason to single out Vault for this CVE, and we haven't checked its MPTCP behaviour. The point is the design, whichever tool you use.

We run upgrades and cluster work on platforms that sit on these kernels. If you need help planning node reboots across clusters, start with our OpenShift page, which also covers OpenShift support dates, or bring in OpenShift engineers for the rollout. If you're more worried about what a rooted server could reach, take the free assessment to see where your service accounts and secrets stand.