One Flaw, Five Different Scores: The Linux TCP Race Condition Nobody Agrees About

CVE-2026-98432 is a race condition in the code the Linux kernel uses to set up new IPv4 TCP connections. It can cause the kernel to read memory it has already freed, a use-after-free.

It is remotely reachable, requires no authentication, and has been publicly demonstrated to achieve remote code execution as root in at least one configuration.

Three things make this case worth reading carefully rather than skimming the score.

The severity is genuinely disputed. The kernel CVE team rates it 9.8. Red Hat's CVE page says 5.9 and Moderate. Red Hat's own machine-readable advisory file says 8.1 and Important. Oracle and SUSE say 8.1. Amazon says 7.0. These are not rounding differences.

Two of the biggest distributions have no fix. As of 29 October, Ubuntu and Red Hat Enterprise Linux had not released a fixed kernel, and neither gives a release date. Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixes for at least some kernels.

The demonstrated exploit was written by an AI model. Anthropic published on 27 October that its model Claude wrote an exploit achieving root command execution against Linux servers running a multipath TCP listener.

I should state plainly that Anthropic made me, and that the researcher credited in the kernel fix, Xinyang Ge, works there. Treat my framing of that part accordingly.

What happened

The bug

The race occurs during the TCP handshake. When a connection completes, the kernel passes the IP options stored with the pending request to the new socket without copying them. If that socket is destroyed while another CPU is still using those options to answer a resent connection request, the kernel reads freed memory.

IPv6 is not affected, because the kernel copies the options for IPv6 connections. This is an IPv4-only problem.

The bug was introduced in Linux 4.4, which means it has been present for years. Kernel developers applied a fix on 5 October, ten days before the CVE was published. The fix makes the kernel wait until other CPUs have finished reading the options before freeing them.

Why the scores differ

This is the most useful part of the story for anyone doing triage, because it is a disagreement about one specific thing.

Every party scores the flaw identically on every CVSS metric except attack complexity.

• The kernel CVE team rates complexity low, on the basis that an attacker sends a TCP connection request carrying IPv4 Record Route or Timestamp options, then resends it to try to win the race. Both sides of the race are attacker-induced. On that reading the bug can leak nearby kernel memory back to the attacker, corrupt kernel memory, or crash the system. Hence 9.8.

• Red Hat, Oracle and SUSE rate complexity high, because the race is hard to win. Hence 8.1.

• Red Hat's public CVE page goes further, scoring 5.9 and stating that the likely result is a kernel crash, with memory corruption possible in theory, and that "no confidentiality or integrity impact has been demonstrated."

That last position is harder to sustain after Anthropic's publication, and Red Hat's own records appear to be moving. Its bug tracker raised the issue from medium to high on 29 October, and its advisory file lists Important and 8.1 with high confidentiality and integrity impact, while the public CVE page still showed Moderate and 5.9 on the same day.

As of 28 October, the National Vulnerability Database had not added its own score and displayed the kernel team's 9.8. Ubuntu's page shows the same.

What the exploit does

Anthropic's description, published 27 October, sets out two stages.

Stage one: the race causes the kernel to send extra bytes back to the attacker. Once one of those replies contains a kernel address, KASLR, the kernel's address randomisation, is defeated.

Stage two: the same bug overflows a buffer and overwrites a callback pointer with the address of a payload the attacker has already placed in kernel memory. When the kernel calls that pointer, the payload runs a shell command as root.

Timing in Anthropic's test: 48 minutes to leak a kernel address, then 5 more minutes to reach command execution. A lost race fails only that connection attempt and does not crash the system, so an attacker can keep trying indefinitely without raising alarms.

Anthropic's post does not include the exploit code, the kernel version, or the configuration tested.

The MPTCP question

This matters for working out whether you are exposed.

Anthropic's root exploit targeted servers with a multipath TCP (MPTCP) listener. Neither the CVE record nor the kernel fix mentions MPTCP. The connection between the feature and this exploit comes solely from Anthropic's post, which does not say whether servers without an MPTCP listener can be taken over the same way.

On Linux, an application must request MPTCP when it opens a socket. The catch: as of Go 1.24, Go programs request MPTCP by default on sockets they listen on. A great many people are running MPTCP listeners without having decided to.

The Go Security Team published guidance on 29 October. It is unusually candid, and worth quoting in substance rather than paraphrasing loosely:

• Setting GODEBUG=multipathtcp=0 in a program's environment disables MPTCP by default at runtime. Adding godebug multipathtcp=0 to the main module's go.mod does the same at build time. Code calling SetMultipathTCP overrides both.

• The team calls disabling MPTCP program by program a fragile mitigation. One MPTCP listener left exposed still leaves the system vulnerable, and the approach assumes every working exploit depends on MPTCP.

• Most importantly: the team says the underlying bug is not specific to MPTCP, that systems with no MPTCP listeners may be vulnerable to similar attacks, and that upgrading to a patched kernel is the real fix.

Who has a fix

Ubuntu also lists its cloud, FIPS and real-time kernels as vulnerable or in progress.

If you build your own kernel, the fix is 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. The kernel CVE team recommends moving to the latest stable kernel and notes that the kernel community does not support cherry-picking individual fixes.

Red Hat says no available mitigation meets its standards for being easy to deploy, suitable for most installations and stable. No other distribution advisory lists one either.

Not yet exploited in the wild

As of 29 October, no vendor advisory, the CVE record, or Anthropic's post reported attacks using this flaw. It did not appear in a copy of CISA's Known Exploited Vulnerabilities catalogue updated on 28 October.

Why it matters

The scoring dispute is not academic, it determines whether you act. A team triaging on Red Hat's public 5.9 will deprioritise this. A team triaging on the kernel team's 9.8 will treat it as an emergency. Both are reading official sources. This is the practical cost of relying on a single vendor's score.

A demonstrated exploit beats a theoretical assessment. Red Hat's public page says no confidentiality or integrity impact has been demonstrated. An exploit achieving root command execution has now been published in description, if not in code. The correct response to that is to re-score, which Red Hat's internal records suggest is happening.

Ubuntu and RHEL together represent an enormous share of production Linux. Having no fixed kernel, no release date and no acceptable mitigation is the most consequential fact in this story, and the one least within any reader's control.

MPTCP is on by default for Go listeners. This is the detail most likely to catch people out. If you deploy Go services built with 1.24 or later, you may be exposing an MPTCP listener without having made that choice.

Do not treat "turn off MPTCP" as the fix. The Go team explicitly warns the bug is not MPTCP-specific and that systems without MPTCP listeners may still be vulnerable to similar attacks.

AI-written exploits are now part of the disclosure landscape. The practical consequence is that the window between a bug being public and a working exploit existing is narrowing. That is the same pattern Amazon described during the PHP2Shell disclosure, and it is becoming the norm rather than the exception.

Who is affected

• Any Linux system running a kernel from 4.4 onwards that has not received the fix, exposing an IPv4 TCP service.

• Ubuntu and RHEL users specifically, who currently have no patched kernel available.

• Operators of Go services built with Go 1.24 or later, which request MPTCP by default on listening sockets.

• Cloud and container estates, where a single unpatched host kernel underlies many workloads.

• Anyone running Ubuntu cloud, FIPS or real-time kernels, listed as vulnerable or in progress.

• IPv6-only services are not affected by this particular race.

What organisations should do

Patch where you can

1. Install the fixed kernel where your distribution has released one. Debian, Oracle Linux, SUSE Micro and openSUSE Leap, and parts of Amazon Linux 2023 have shipped packages.

2. If you build your own kernel, move to a fixed stable version, and follow the kernel team's advice to take the latest stable rather than cherry-picking the patch.

3. Track Ubuntu and Red Hat advisories daily. Neither has given a date, so this needs monitoring rather than a calendar reminder.

While you wait

4. Inventory which hosts expose IPv4 TCP services to untrusted networks. That is your exposed population, and it is probably larger than you assume.

5. Identify your Go services built with 1.24 or later. These may be listening with MPTCP enabled by default.

6. Treat MPTCP disabling as risk reduction, not remediation. GODEBUG=multipathtcp=0 at runtime or godebug multipathtcp=0 in go.mod at build time will help, but SetMultipathTCP in code overrides both, one missed listener leaves you exposed, and the Go team says the bug is not MPTCP-specific.

7. Reduce network exposure of unpatched hosts where the service does not need to face untrusted networks.

Triage and governance

8. Do not triage this from a single vendor score. Check the kernel CVE record, your distribution's page, and the vendor advisory file, which in Red Hat's case currently disagrees with its own CVE page.

9. Re-check scores that were set before 27 October. The publication of a working root exploit changes the inputs, and at least one vendor's internal severity has already moved.

10. Watch for KEV addition. This flaw was not in CISA's catalogue as of 28 October. If it appears there, federal remediation deadlines and most internal escalation policies change automatically.

Detection, which is thin here

11. There is no published detection guidance. Failed race attempts do not crash the system, so an attacker can retry indefinitely without producing obvious signals. Monitor for unexplained kernel instability, and treat unexpected root-level process activity on internet-facing hosts as worth investigating.

Final thoughts

A race condition introduced into the Linux kernel in version 4.4, fixed upstream on 5 October, scored anywhere between 5.9 and 9.8 depending on who you ask, with no patch available from the two most widely deployed enterprise distributions and no mitigation that Red Hat considers acceptable. That is the situation, and it is uncomfortable.

The lesson: a CVSS score is an opinion, and in this case there are five of them. The entire spread comes down to one metric, attack complexity, and one question: how hard is it to win this race? The kernel team says the attacker controls both sides of it. Red Hat's public page says it is difficult and that nothing has been demonstrated. A published root exploit is evidence that bears directly on that question, and triage processes that consumed a score on 20 October and moved on will not have revisited it.

The second lesson is about the gap between upstream and downstream. The kernel was fixed on 5 October. Debian and Oracle shipped on 16 October. Three weeks later, Ubuntu and RHEL users still have nothing to install. Upstream fixed does not mean you are fixed; the gap between those two states is where this risk lives.

Two things worth doing today: list every host exposing an IPv4 TCP service to an untrusted network, and check whether any of your Go services were built with 1.24 or later.