Mitchel van Emmerik Full-stack developer
Steam LinkedIn Twitch
© 2026 Mitchel van Emmerik
Nederlandse versie RSS feed
Blog

Linux TCP flaw CVE-2026-98432: why disabling MPTCP isn't enough

A critical flaw in Linux's TCP code, a root exploit written by an AI and no fix yet for Ubuntu LTS. What helps, what doesn't, and what to check now.

7 min read 2 views

  • linux
  • security
  • kernel
  • cve-2026-98432

On 27 October, Anthropic reported that an internal, unreleased Claude model had written a working exploit for a bug in the Linux kernel. An attacker without an account sends network packets to a server and can then run commands as root. Debian and Amazon Linux have fixes by now. As of 7 November, Ubuntu 22.04, 24.04 and 26.04 are still marked "work in progress". And the advice that spread fastest, disabling MPTCP, doesn't fix it.

What's wrong #

CVE-2026-98432 is a use-after-free in the IPv4 TCP handshake. A connection request can carry IP options, such as Record Route or Timestamp. If that request is sent again, the kernel can free those options while another CPU core is still using them to build a SYN-ACK. According to Akamai, the flaw has been in the kernel since version 4.4, so since 2016.

The fix has been upstream since 5 October. The CVE number followed on 15 October, and on 24 October the kernel's CVE team gave it a CVSS score of 9.8. Ubuntu and Red Hat both rate it "Critical" now. These stable kernels have the fix:

Kernel branch Fixed from
5.10 5.10.272
5.15 5.15.223
6.1 6.1.190
6.6 6.6.159
6.12 6.12.113
6.18 6.18.56
7.2 7.2.10
7.3 all versions

Distributions backport fixes to their own kernel versions, so for your own servers your distribution's advisory is what counts, not this table.

The exploit #

Anthropic's Frontier Red Team describes a two-step attack. First the exploit uses the race to leak kernel memory and get around KASLR. Then it overwrites a callback pointer so the kernel runs the attacker's code. Leaking a kernel pointer took 48 minutes, getting root another five. A lost race only makes the handshake fail and doesn't crash the system, so an attacker can keep trying forever.

The code, the kernel version and the test setup haven't been published. Anthropic gives vendors 90 days to patch, and then waits another 45 days before it shares more details.

The demonstrated attack works on servers with a Multipath TCP (MPTCP) listener. That's where the discussion went next.

Why disabling MPTCP isn't enough #

The first advice going around was net.mptcp.enabled=0. But MPTCP is only the path Anthropic showed, the bug itself is in plain TCP code. Red Hat says so in as many words: "Having MPTCP enabled is not a precondition of this vulnerability." RHEL ships with MPTCP off and is still vulnerable, according to Red Hat. CIQ tested it on Rocky Linux: with MPTCP off, a plain TCP listener still answered a SYN carrying a Record Route option.

Disabling MPTCP does lower the risk. AWS says it limits the conditions for the attack, but "does not resolve the issue". MPTCP sockets that are already open also stay open until you restart the service.

There are two places where you run more MPTCP than you'd think:

  • Go 1.24 and later. According to the Go Security Team, listeners on Linux use MPTCP by default when the kernel supports it. Turn it off with GODEBUG=multipathtcp=0 or with godebug multipathtcp=0 in go.mod.
  • Containers. The MPTCP setting applies per network namespace, so the value on the host tells you nothing about your containers. The vulnerable code does run in the kernel all containers share. According to the Cloud Security Alliance, one exposed listener in one container can put the whole host at risk.

A reverse proxy doesn't protect you #

The TCP handshake happens in the kernel of the machine that accepts the connection. If nginx or HAProxy runs on the same host as your application, that host is simply reachable by the attack. If the proxy runs on a separate Linux machine, that's the machine you need to patch first. A managed load balancer that handles the TCP connections itself, as on AWS, does keep an attacker's packets away from your servers. Even then you still need to update the servers behind it.

Is it being exploited yet? #

There's no public working exploit and there are no confirmed attacks. AWS wrote on 6 November: "We have no evidence that this issue has been leveraged at this time." According to Aikido, Marcus Hutchins reported on X that residential proxies and VPN servers have been probing port 443 over MPTCP since 2 November, and he suspects they're looking for this flaw. I haven't found a second source that confirms it.

What to do now #

1. Update the kernel and reboot #

This is the only real fix. A new kernel does nothing until you reboot the machine.

  • Debian: fixed in 6.1.190-1 (bookworm) and 6.12.115-2 (trixie), via the security repository.
  • Amazon Linux 2 and 2023: fixes are out.
  • Ubuntu: only 26.10 has a fix (7.3.0-10.10). For 22.04, 24.04 and 26.04, fixed kernels are in -proposed, which apt doesn't install by default. Keep an eye on the Ubuntu CVE page.
  • RHEL 8, 9, 10 and OpenShift 4: Red Hat's bulletin is still marked "Ongoing". Check the errata for your version.

2. Check what you're running #

uname -r                                           # running kernel
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req  # MPTCP on? request migration on?
sudo ss -Mlnp                                      # processes with an MPTCP listener

On RHEL, Rocky and Alma, this shows whether the fix is in your running kernel. A result above 0 means yes:

rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

3. No fix yet? Filter TCP packets with IP options #

Red Hat, CIQ, AlmaLinux and AWS give the same stopgap: drop TCP packets that carry IP options. Normal traffic almost never uses them. An IPv4 header without options is exactly five 32-bit words long, so anything above 5 has options. This is CIQ's rule:

sudo nft add table inet cve_2026_98432
sudo nft add chain inet cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; policy accept; }'
sudo nft add rule inet cve_2026_98432 prerouting ip hdrlength gt 5 meta l4proto tcp counter drop

Keep a few things in mind:

  • Not permanent. The rule is gone after a reboot, and systemctl stop nftables removes it too.
  • Can break legitimate traffic. Traffic that really needs IP options, such as CIPSO/NetLabel, gets blocked too. Test the rule on one machine first.
  • Not complete. According to Ubuntu, this rule lowers the risk but doesn't fully prevent exploitation.
  • To remove it, run sudo nft delete table inet cve_2026_98432.

4. Shrink what attackers can reach #

If you don't use MPTCP, turn it off and also set net.ipv4.tcp_migrate_req to 0. That setting belongs to a second vulnerable path in the same code. Save both in a file under /etc/sysctl.d/, then restart your services, and don't forget your Go services and containers.

Same lesson as PHP2Shell #

As with PHP2Shell, your application can be fully up to date, and the layer underneath still decides whether you're safe. This time that's the kernel, and it isn't updated until you reboot the machine.

Sources #