Cut-paper illustration of a server rack sending layered paper arrows toward a network globe, with a torn paper packet slipping between two overlapping paper layers

On October 27, Anthropic published a research post describing five exploit chains its internal research model had built. The last one was the quietest and the most uncomfortable for anyone running Linux servers. A remote attacker with no credentials could send packets to a Linux server with a Multipath TCP listener and run commands as root. In the lab demonstration it took 48 minutes to leak a kernel pointer and five more minutes to reach a shell.

The flaw itself was not new that day. It had been published as CVE-2026-98432 on October 15, and fixed in every maintained upstream stable kernel. Yet as of October 30, Ubuntu and Red Hat Enterprise Linux still had no fixed kernel package to install. That gap is the story.

The flaw is in the handshake, not in an application

CVE-2026-98432 is a use-after-free race in the Linux kernel code that sets up new IPv4 TCP connections. When a server accepts a connection, the kernel turns a pending request into a full socket and hands the saved IP options from the request socket to the new socket without copying them. Another CPU can still be working on a retransmitted request for the same socket, building a reply from those same options. One CPU frees the options while the other is still reading them. The fix delays the free until an RCU grace period has passed, so no reader can still be using the memory.

IPv6 is not affected by this issue, because the IPv6 path copies the options. Containers share the host kernel, so rebuilding an image does nothing here.

The score moved, and that movement is worth reading

The Linux kernel CVE team scores the flaw 9.8 under CVSS 3.1: network reachable, low attack complexity, no privileges required, no user interaction, high impact on confidentiality, integrity, and availability. Red Hat first scored it lower, citing how hard the race is to win reliably, then raised its rating to Critical with a 9.8 score. Its statement adds the needed caution. A remote attacker can cause kernel memory corruption or a crash over standard IPv4 TCP traffic, and reliably executing code through the race requires precise heap control.

The 9.8 describes the worst case, and Anthropic's demonstration shows the worst case is reachable in a lab against a server with a Multipath TCP listener. It does not show that every Linux server falls over in 53 minutes. As of October 30, no vendor, CISA, or Anthropic report described exploitation in the wild, and the CVE was not in CISA's Known Exploited Vulnerabilities catalog. Treat the demonstration as proof that the path exists, not as evidence that it is already being used against you.

One more detail should change how you read your own logs. A lost race only fails the handshake, without crashing the system, so an attacker can retry until it succeeds. No unexplained crashes proves nothing.

Why Multipath TCP changed the urgency

Anthropic's exploit needed a server listening with Multipath TCP, or MPTCP, a TCP extension that lets one connection use several network paths at once. Many operators would reasonably assume they have no MPTCP listeners, because nobody on their team turned the feature on.

That assumption got weaker on October 29, when the Go Security Team pointed out that Go programs have enabled MPTCP by default for listening sockets on Linux since Go 1.24. A service built with Go 1.24 or later may therefore be listening with MPTCP even though nobody configured it. The Go team described how to turn the default off, with GODEBUG=multipathtcp=0 at runtime or the matching setting in go.mod at build time, and noted that code calling SetMultipathTCP overrides both. It called turning MPTCP off program by program a fragile mitigation, and said the underlying bug is not specific to MPTCP. Turning MPTCP off removes the one exploit path that has been described. It does not fix the kernel. If you run Go services, check the host for MPTCP listeners instead of guessing from the application list.

The split that matters is your distribution, not your kernel number

Upstream stable kernels carry the fix 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. Almost nobody runs an upstream stable kernel directly. You run a distribution package, and the distributions did not all ship on the same day. As of October 30, the picture looked like this:

Distribution Status as of October 30, 2026
Debian 12 (bookworm) Fixed: linux 6.1.190-1 (DLA-4841-1), plus a 6.12 package
Debian 13 (trixie) Fixed: linux 6.12.113-1 (DSA-6568-1)
Ubuntu 22.04, 24.04, 26.04, 26.10 Vulnerable; fixes in progress, with target package versions named on Ubuntu's CVE page
Red Hat Enterprise Linux 8, 9, 10 Affected; no fixed kernel released; Red Hat published bulletin RHSB-2026-016 with a partial filter
SUSE, Oracle Linux, Amazon Linux Fixed kernels shipped for at least some releases

Compare the running kernel against your own distribution's tracker, not the upstream version list, because distribution kernels carry the fix under their own package versions. Ubuntu's page, last updated October 30, names the target versions it is working toward. Check the kernel that is running, not the kernel that is installed. A kernel update only takes effect after a reboot, so confirm the running kernel again after rebooting.

While you wait, shrink the reachable surface honestly

For hosts whose distribution has shipped a fix: install the fixed kernel, reboot, verify the running kernel. For hosts still waiting, start with reachability. Red Hat's bulletin offers an nftables filter that drops inbound IPv4 TCP packets carrying IP options, identified by an IPv4 header longer than the standard 20 bytes. Red Hat says the filter reduces exposure but cannot fully prevent exploitation and is not a substitute for patching. Test it before you lean on it, and remove it once the fixed kernel is installed.

Prioritise listeners an attacker on the network can actually reach, and do not stop at the public ones. Internal services count if anything untrusted can send them TCP packets. If you cannot patch a host yet, restricting who can reach its listening ports is a real reduction in exposure.

The durable point

The fix has been available upstream since mid-October. The exposure most operators face is the queue between the upstream project and their distribution, plus the reboot not yet scheduled. Know where your hosts sit in that queue, plan the reboot for the day the package lands, and avoid the two comforting mistakes: assuming no crashes means no attempts, and assuming no MPTCP configuration means no MPTCP listener.

Patch the host, not the app. Then prove it by checking what is running.

Sources