Linux TCP flaw CVE-2026-98432 raised to CVSS 9.8

On November 2, Red Hat raised the CVSS score of Linux kernel vulnerability CVE-2026-98432 to 9.8. It had previously assigned scores ranging from 5.9 to 8.1, and on November 1 it shipped fixed kernels for RHEL 8, 9 and 10. Ubuntu's status is still listed as fix in progress.

The flaw sits in the IPv4 TCP connection-setup path. It can be triggered from the network with no authentication and no user interaction. Affected versions start at Linux 4.4, and the root cause traces back to a commit from 2015.

A race condition fixed in two lines

When a SYN packet carries IPv4 options (Record Route or Timestamp, for example), the kernel stores them on the request socket. Once the handshake completes, the pointer to that memory is handed straight to the child socket without being copied, so both sockets share a single allocation.

If another CPU is building a SYN-ACK in response to a retransmitted SYN at that moment, and the child socket happens to be destroyed, the options memory is released immediately with kfree(). The SYN-ACK path then reads memory that has already been freed.

The fix was submitted by Eric Dumazet as commit e3f33b0a1d89. It replaces kfree() with kfree_rcu(), so the memory is freed only after an RCU grace period, and touches just two lines. The reporter was Xinyang Ge of Anthropic. The CVE record was published on October 15. Stable-branch fixes landed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, with mainline fixed in 7.3.

Only Anthropic can vouch for Anthropic's claim

What brought the bug wide attention was an October 27 post by Anthropic's Frontier Red Team. It said an unreleased internal model wrote an exploit that lets an unauthenticated remote attacker run commands as root on a server with an MPTCP listener enabled.

The exploit runs in two stages. First, the race condition is used to read kernel memory out of bounds, leaking pointers and defeating KASLR. Then an out-of-bounds write overwrites a callback function pointer. Anthropic put the timing at about 48 minutes to leak the pointer and roughly 5 more minutes to reach command execution.

Several points need to be kept apart here. The exploit code, the kernel versions used for testing and the configuration have not been published, and no third party has verified the claim. Neither the CVE record nor the fix commit mentions MPTCP, and the post does not explain why it is required. The 53-minute figure comes from an unknown environment and cannot be applied directly to production servers. As of November 2, no vendor, CERT or the kernel CVE team has reported exploitation in the wild, and the bug is not in CISA's Known Exploited Vulnerabilities catalog.

Some Chinese-language coverage says Anthropic "published an exploit example". More precisely, it published a description of the exploitation process, not runnable code.

Disagreement over the score also persists. The kernel CVE team and Red Hat now rate it 9.8, while Oracle, SUSE and Amazon rate it 8.1; the difference is whether attack complexity is judged low or high. NVD has not yet published its own score.

Go turned the precondition into a default

A Go security team announcement on October 29 widened the exposure. Since Go 1.24, the default value of multipathtcp is 2, meaning MPTCP is enabled on the listening side only. In other words, a Go program that starts a service with net.Listen meets the precondition of Anthropic's demonstration by default.

The Go team's mitigation is to set GODEBUG=multipathtcp=0 at runtime, or to add godebug multipathtcp=0 to the main module's go.mod. It also called this per-program opt-out "a fragile mitigation". The Go team considers it premature to change the default. On the kernel side, setting net.mptcp.enabled to 0 removes the demonstrated precondition, but the vulnerability itself remains.

What operators can do first

Fix status by distribution (some checked on October 29, some on November 2) is roughly as follows:

Ubuntu has a sizable share among cloud-host users, so it is the row in this table that most needs watching. Most distributions fix this through backported patches, so whether a machine is patched should be judged against the package version in the vendor's own advisory; looking only at the major version in uname -r is easy to get wrong. A new kernel takes effect only after a reboot, and live patching is a separate mechanism that has to be confirmed on its own.

For machines that cannot get a patch yet, start by inventorying which services listen on MPTCP, especially binaries built with Go 1.24 or later, and then decide whether to disable it as described above. Vendors have not confirmed that disabling MPTCP removes all risk, so this step only buys time. Kernel crash logs that mention functions such as ip_options_build should also be checked.

Sources: public accounts of Anthropic Frontier Red Team's post, Rescana vulnerability advisory, CocoLoop, Go security team announcement, Debian and Red Hat security trackers. Scores and per-distribution fix status follow each vendor's published figures; Anthropic's exploit details have not been independently verified.