Linux flaw scored 5.9 to 9.8; Ubuntu and RHEL had no fix on Oct 29

A score is an estimate until someone shows an exploit

A severity score is a vendor's judgment of how hard a bug is to abuse. One Linux flaw now shows what happens when those judgments and a claimed working exploit point in different directions.

The flaw is CVE-2026-98432, in the Linux kernel's TCP networking code. Anthropic says that, after initial prompting, its unreleased internal Claude research model wrote an exploit for it. In Anthropic's account, a remote attacker needs no password and no user action. Specially crafted network traffic can run commands as root, meaning total control, on Linux servers that accept multipath TCP connections.

Anthropic's proof of concept needed 48 minutes to obtain a kernel memory address and five more minutes to get a shell command running. That is roughly 53 minutes. The figures come from Anthropic's own test, and the post does not describe the conditions. Readers cannot judge how the timing would carry over to real servers. Anthropic adds that a lost attempt only fails the handshake and does not crash the machine, so an attacker can keep trying.

How the flaw works

The Hacker News describes the bug as a timing clash in how the kernel handles IPv4 connection handshakes. A half-open connection request carries stored IP options. When the connection finishes, the new socket receives those options by reference rather than as its own copy.

Suppose the socket is closed while another processor core still reads those options to answer a repeated request. The kernel then reads memory that was already released. This is called a use-after-free. IPv6 connections are spared because the kernel makes copies there. The faulty code dates to Linux 4.4. The patch changes the order of events, so the options are released only after every other core has finished using them.

Anthropic describes two stages. First, the attacker coaxes the kernel into returning extra bytes that include a kernel address. That defeats KASLR, a defence that randomises where kernel code sits in memory. Second, the same flaw lets the attacker overwrite a function pointer so the kernel runs prepared code that ends in a root shell command.

Anthropic's exploit depends on a setting, not only a version

Anthropic's exploit targets servers with a multipath TCP (MPTCP) listener. MPTCP lets one connection use several network routes. The Hacker News notes that neither the CVE record nor the kernel fix mentions MPTCP. The connection comes only from Anthropic's post.

Linux applications must ask for MPTCP when they open a socket. The Go Security Team reported on October 29 that, from version 1.24, Go programs switch it on by themselves for the sockets where they wait for incoming connections. So your software, not only your kernel, may decide whether that exploit path exists.

That is not the same as saying other servers are safe. The kernel team's 9.8 score assumes a different route. It describes an attacker sending ordinary IPv4 connection requests with Record Route or Timestamp options, then resending them to win the race. Servers without MPTCP on affected kernels should not be assumed safe.

One bug, many scores

The 9.8 came from the kernel's own CVE team. It entered the score in the record on October 24, when the CVE had already been public for nine days. The team judged the attack easy to launch, because the attacker can trigger both parts of the race. The Hacker News reports that Red Hat, Amazon, Oracle and SUSE land lower, between 5.9 and 8.1.

Red Hat's CVE page says Moderate, 5.9, because the race is difficult to win. It calls a kernel crash the likely outcome and states that "no confidentiality or integrity impact has been demonstrated." Red Hat's machine-readable advisory file, updated October 29, says Important and 8.1. The CVE page still showed 5.9 that day.

Anthropic's post describes the kind of demonstration Red Hat's page said was missing. The lesson here is that "hard to win" measures an attacker's effort, and effort can fall. Anthropic says models can now do this work with little human involvement. It also says Claude began with initial prompting. This is one vendor's account of one case, not a trend. Even so, an exploit Anthropic says it demonstrated is stronger evidence than an estimate, though the sources we reviewed do not show it has been independently reproduced.

The fix exists, but not for everyone

A kernel fix was committed on October 5. The CVE was published ten days later. Anthropic says the fix reached all maintained stable kernel branches. Distribution users receive it only through their vendor's kernel package.

Fixed packages are out from Debian, Oracle Linux, SUSE and Amazon Linux, though for some of them only on certain kernels. As of October 29, Ubuntu and RHEL had none. The Hacker News adds that Ubuntu's cloud, FIPS and real-time kernel variants are also not yet cleared, listed either as vulnerable or as work still underway.

Red Hat's position moved within a day. On October 29 it said the fixes were postponed to a later update. By October 30 its listing showed RHEL 8, 9 and 10 and OpenShift 4 as affected, not as fix-deferred. Neither Red Hat nor Ubuntu has named a release date.

Questions to put to your team

Ask which internet-facing servers run Ubuntu or RHEL kernels, and which run vendors that have shipped fixes. Patch the second group now.

Ask which services listen with MPTCP, including software built with Go 1.24 or later. That tells you where Anthropic's demonstrated exploit applies. It does not clear the rest, because the kernel team's scoring describes an attack over ordinary IPv4 connection requests.

Ask Red Hat and Ubuntu for a release date and any interim mitigation. Write down the answer.

Set priority by exposure and by the existence of a claimed working exploit, not by one vendor's score. A score records what one party believed on one day. Plan around the evidence, and weigh who produced it.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Anthropic.