A Severity 9.8 Linux Kernel Flaw: What the AI-Built Attack Needs, and Where Each Distribution Stands

Anthropic announced on October 27, 2026 that it had demonstrated an attack on a flaw in the Linux kernel’s IPv4 TCP code (CVE-2026-98432) that runs commands as root, remotely and without authentication (Anthropic). The kernel’s CVE assigner rates the severity 9.8 out of 10 (CVE record).

The headline “root without authentication” is accurate. But the demonstration had conditions. This article sets out those conditions, how to check whether your own servers are in scope, and where each distribution stands, all from primary sources. The information is current as of October 30, 2026.

Key points

• The flaw is a race condition while a TCP connection is being set up: the memory holding IPv4 options is freed while it is still in use (a use-after-free). It can be reached remotely, during the connection handshake and before any authentication (CVE record).
• Kernels from 4.4 onward are affected. The upstream fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3 (CVE record).
• Anthropic’s demonstration targeted servers with an MPTCP listener (MPTCP is a TCP extension that uses several paths), using exploit code written by an unreleased research model. It says it took 48 minutes to defeat KASLR (kernel address randomization) and about five more to run a command (Anthropic).
• The flaw itself is not specific to MPTCP. The Go security team also writes that systems without MPTCP listeners may be open to similar attacks (oss-security).
• I could not confirm any report of real-world exploitation. The flaw is not in CISA’s Known Exploited Vulnerabilities (KEV) catalog as of the October 29 data (I checked CISA’s KEV data directly).
• Distributions vary. Debian is fixed, Ubuntu has work in progress on every release, and Amazon Linux 2 is awaiting a fix.

What happened

The flaw arrived with the change that puts connection requests received via SYN into a hash table (commit 079096f103fa), which is in kernel 4.4 (CVE record).

How the flaw works

According to the CVE description (CVE record):

1. If a connection request (SYN) carries IPv4 options (Record Route, Timestamp), the kernel stores them
2. When the connection is established, those options are handed to the new connection without being copied
3. If a retransmitted SYN for the same connection is processed on another CPU, that CPU keeps reading the options
4. If the connection closes in the meantime and the options are freed with a plain kfree(), the freed memory is used

The fix changes the free to kfree_rcu(), which waits until other CPUs have finished reading. IPv6 is not affected by the first issue. The same kind of problem in request migration is to be fixed in a separate patch (CVE record).

As possible results, the CVE description lists disclosure of kernel memory, out-of-bounds writes, hijacked control flow and a crash.

What the demonstration showed

Anthropic’s post contains five demonstrations, and Linux is one of them (the others are Chrome, Safari, Android and Windows). What it says about Linux (Anthropic):

• An unreleased, internal research model wrote the exploit
• The target is a Linux server with an MPTCP listener. No credentials and no user action are needed
• Stage one uses the race to over-read kernel memory until a reply contains a kernel pointer, which defeats KASLR (48 minutes)
• Stage two overwrites a callback pointer so that a payload already staged in kernel memory runs, executing a command as root (about five minutes)
• Losing the race only fails the handshake and does not crash the system, so the attacker can try again

Anthropic presents this as a demonstration. It is not a report that someone was attacked. A caveat for the post as a whole says that humans gave the initial prompts for these attack chains.

The post does not say whether the exploit code has been released or withheld (as far as I read). The Go team’s oss-security message refers only to an exploit “described by Anthropic”, and does not include the code (oss-security). Whether it is public is not confirmed.

How true is “root without authentication”?

For how to read the gap between a headline and the primary sources, see also the PHP2Shell article.

Red Hat describes the possible result as “a crash (denial of service) or possible memory corruption”, and says no mitigation is available (Red Hat).

The gap in ratings is a difference over whether attack complexity is low or high. I could not confirm whether each vendor explains its reasoning in the pages I read. Anthropic says a lost race can be retried. Either way, this is worth fixing first.

Why MPTCP matters

MPTCP is a TCP extension that lets one connection use several paths. Anthropic’s demonstration required an MPTCP listener.

The easy-to-miss case is Go. Programs built with Go 1.24 or later make their listening sockets MPTCP by default on Linux (the Go security team’s description; oss-security). A web server, reverse proxy or API gateway written in Go may be an MPTCP listener without anyone knowing.

The workarounds the Go team gave on oss-security (oss-security):

• Set the environment variable GODEBUG=multipathtcp=0 at runtime
• Add godebug multipathtcp=0 to go.mod at build time
• Set it per socket with SetMultipathTCP

The Go team itself calls this approach fragile: leaving a single MPTCP listener exposed still leaves the system vulnerable. It considers changing Go’s default behavior premature for now (oss-security).

Where each distribution stands

Status as read on each vendor’s page on October 30, 2026.

“The upstream kernel is fixed but my server is not” is a real situation on Ubuntu and others right now. Anthropic’s statement that the fix was backported to all maintained stable branches is about the upstream kernel. Distributions pull it into their own kernels at a separate stage. “It should be fixed, but it is not” also happened with the GitLab flaw the same week.

Distribution kernels can carry a fix under a different version number from upstream. Do not decide by the number alone. Check each vendor’s advisory.

What to do now

1. Check your servers’ kernels and fix status

uname -r

Compare that with the vendor pages in the table above. Start with servers exposed to the internet.

2. Check whether you have MPTCP listeners

sysctl net.mptcp.enabled
ss -Mltn

If ss -Mltn shows an MPTCP listener, you meet the condition of the demonstration (this method comes from KrakenD’s article, not from an official guide). Containers use the host’s kernel, so updating a container image does not fix this. Update the host kernel.

3. If a fix is available, update and reboot

After a kernel update, the old kernel keeps running. You need to reboot (or, if you use live patching, confirm it has been applied).

4. Stopgaps if you cannot update

None of these makes you safe. They only buy time.

• Turn MPTCP off (the kernel setting net.mptcp.enabled=0; for Go programs, GODEBUG=multipathtcp=0). This removes the demonstration’s precondition, but the flaw remains
• Limit the traffic that public servers accept to the minimum

Red Hat says no mitigation is available (Red Hat).

5. Check for compromise

I could not confirm any report of exploitation, but the public information is complete. Check the following.

• Whether the kernel has crashed or rebooted unexpectedly. The CVE description lists a kernel crash from memory corruption as a possible result
• But in Anthropic’s description, losing the race does not bring the system down, so there may be no trace
• Whether public servers show processes, users or outbound connections you do not recognize

What not to do

• Do not conclude “we don’t use MPTCP, so we’re fine”. The flaw is not specific to MPTCP
• Do not relax because the upstream kernel is fixed. What matters is whether your distribution’s fix is out
• Do not update and skip the reboot
• Do not try exploit code you found online on production

What is not confirmed

• I could not confirm any report of real-world exploitation. It is not in CISA’s KEV either
• Whether Anthropic’s exploit code is public. The post does not say. The Go team’s message says only that Anthropic described it, and does not include the code
• Whether remote code execution is possible in an environment without an MPTCP listener. There is no demonstration, and it has not been ruled out
• Whether MPTCP is on by default depends on the distribution and its configuration. I did not check each vendor’s default
• I could not confirm Red Hat’s fix status per RHEL version
• The CVE description gives the trigger as a SYN carrying IPv4 options (Record Route or Timestamp). Whether dropping such traffic at the perimeter helps is not stated officially, and I have not confirmed it
• CVE-2026-46300, the Linux kernel flaw added to KEV on October 28, is a separate flaw. The story of its chain with PHP2Shell is in the summary of PHP2Shell for engineers

Related articles

• Haven’t Updated PHP Yet? Where PHP2Shell Stands and What to Check Now: Where PHP2Shell stands. The firewall compromises also used a kernel flaw, on top of PHP
• PHP’s Critical PHP2Shell Vulnerabilities (CVE-2026-109618 / 109619): A Technical Summary for Engineers [Updated Regularly]: The technical story of how PHP2Shell chains with a Linux kernel flaw (CVE-2026-46300)
• Where PHP2Shell Reports and the Primary Sources Disagree: How the numbers in the headlines differed from the primary sources, and how to read them
• Two Critical GitLab Flaws, Not One: Why the October 12 Fix Is Not Enough: The severity 10.0 GitLab flaw from the same week. Updating GitLab alone may not fix it
• As Breaches Mount in Japan, What Leaders Should Decide First: Zero Trust and Security in the Age of AI: A way for executives to think about the current wave of breaches, and security in the age of AI
• 15 Jenkins Core Flaws: Only One Works Without Login, but Some Need Nothing More Than Read Access: The same week, the Anthropic OSS program was credited as a reporter: 15 Jenkins core flaws

If you’d like help checking your servers’ kernels, updating, or checking for intrusion, get in touch.