CVE-2026-98432: Linux TCP bug, Ubuntu and RHEL have no fix

CVE-2026-98432 is a race condition in the way the Linux kernel completes an IPv4 TCP handshake. It ends in a use-after-free, the kernel CVE team scores it 9.8, and the bug has been in the code since Linux 4.4. Anthropic says its unreleased research model wrote an exploit for it that gives a remote, unauthenticated attacker a root shell on a server with a multipath TCP (MPTCP) listener. As of 30 October, Ubuntu and Red Hat Enterprise Linux have no fixed kernel, while Debian, Oracle Linux, SUSE and Amazon Linux have shipped one for at least some of their releases.

If you run a VPS or a dedicated server with Laravel, Symfony or anything else on it, you also need to keep its kernel patched. I would check this one today.

The short version

1. Run uname -r on every internet-facing server and check whether your distribution has a fixed kernel (list below).
2. If it does, install it and reboot. The fix takes effect when the machine runs the new kernel.
3. If it doesn't (Ubuntu, RHEL), you can't patch yet. Close unnecessary public ports, check for MPTCP listeners, and look at the stopgap firewall rule further down.
4. Check the vendor's page again tomorrow. Both are working on it, neither has given a date.

What's known, and what isn't

The kernel hands the IP options of a pending connection to the new socket without copying them. If that socket is destroyed while another CPU is still answering a resent connection request with those options, the kernel reads freed memory. IPv6 isn't affected by this race. The fix makes the kernel wait before freeing the options.

Anthropic's write-up describes two stages. The race first leaks a kernel address, which defeats KASLR, and the same bug then overwrites a callback pointer, so the kernel runs an attacker's command as root. A lost race only fails that one connection, so the attacker can keep trying. In Anthropic's test it took 48 minutes to leak the address and five more to get command execution. The post has no exploit code.

There are a few gaps and disagreements in the reports:

• MPTCP. The exploit targets servers with an MPTCP listener, but neither the CVE record nor the kernel fix mentions MPTCP. That link comes from Anthropic alone. The Go Security Team says the bug itself isn't specific to MPTCP and that systems without an MPTCP listener may be open to similar attacks.
• Attacks. None of the advisories I read reports exploitation in the wild, and according to The Hacker News the bug wasn't in CISA's known-exploited list on 28 October. That can change faster than this article.
• The score. The kernel team rates attack complexity low, because both sides of the race are attacker-induced, and lands on 9.8. Red Hat, Oracle and SUSE rate it high and score 8.1, Amazon says 7.0, and according to The Hacker News Red Hat's own pages disagreed with each other for a day. I wouldn't spend time on that argument. The finder says the exploit works and can be retried, and that's enough to treat an exposed server as a priority.

Who has a fix?

Status on 30 October, from the vendors' pages and advisories:

• Debian: fixed. Trixie in linux 6.12.113-1, bookworm in linux 6.1.190-1 (and 6.12.113-1~deb12u1 for the backported 6.12 kernel).
• Oracle Linux 7 to 10 (UEK): fixed on 16 October.
• Amazon Linux 2023: fixed for the kernel6.18 and kernel6.12 packages, pending for the default kernel package.
• SUSE: fixed for SUSE Linux Micro 6.2 and openSUSE Leap 16.0, in testing or in progress for SLES 15 and 16.
• Ubuntu 22.04, 24.04, 26.04, 26.10: vulnerable, fix in progress. Ubuntu 20.04 and older: vulnerable, no fix listed. Cloud, FIPS and real-time kernels are listed as well.
• RHEL 8, 9, 10 and OpenShift 4: affected, no fix. Red Hat says it has no mitigation that meets its criteria. RHEL 7 isn't affected.

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 team recommends moving to the latest stable release rather than cherry-picking the patch.

Check your server

uname -r                                   # the kernel that is running right now

# Debian / Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

# RHEL / Alma / Rocky / Oracle Linux
rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

The changelog can help, but it is not a definitive check. A missing CVE entry does not prove the fix is absent. Compare the running kernel package version with the fixed version in your distribution's advisory. After the update, reboot and run uname -r again. On Ubuntu, /var/run/reboot-required tells you a reboot is waiting.

For containers and managed infrastructure, check which machine needs the update:

• Containers use the host's kernel. Rebuilding a Docker image fixes nothing here; the host needs the new kernel.
• Managed and shared hosting: the kernel is the provider's. Ask them in plain words: "Is the server my site runs on patched for CVE-2026-98432?"
• Kubernetes nodes need the new kernel on each node, one reboot at a time.

If your distribution has no fixed kernel yet

Nothing here replaces the patch, and nobody has shown that any of it stops the exploit. These steps shrink the exposure while you wait.

Reduce what the internet can reach. Check which services actually need to accept connections from the internet. Close what you don't need, put the database and admin tools behind a VPN or a firewall allowlist, and put the site behind a proxy like Cloudflare where that fits. A proxy terminates the TCP connection itself, so the attacker's packets don't reach your kernel. That only holds if the origin accepts connections from the proxy alone and the port isn't open to everyone else.

Look for MPTCP listeners. MPTCP is opt-in, but some runtimes opt in for you: since Go 1.24, Go programs request it by default on their listening sockets.

sysctl net.mptcp.enabled
sudo ss -lnM          # listening MPTCP sockets

For Go services, the Go team's advice is GODEBUG=multipathtcp=0 in the environment, or godebug multipathtcp=0 in go.mod. Code that calls SetMultipathTCP overrides both, and the team calls this a fragile mitigation. The vendors haven't said whether disabling MPTCP in the kernel lowers the risk, and a listener that's already open stays open when you flip the sysctl. I'd treat all of it as a way to find out where you're exposed, not as protection.

The firewall stopgap. The trigger needs IPv4 options on the connection request, and IP options are rare in normal internet traffic. A third-party write-up proposes dropping every IPv4 TCP packet that has them:

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

# remove it again
sudo nft delete table ip cve_2026_98432

The author tested it against the trigger on Rocky and Ubuntu VMs, not against the full exploit, and I haven't run it myself. It isn't persistent across reboots, it will also drop forwarded traffic with IP options, and it's a bad idea on networks that use CIPSO labelling. No vendor recommends it. On a plain web server I'd try it on a staging box first and then consider it, after checking that it does not block traffic the server needs.

Who handles the update and reboot?

Distribution kernels can lag upstream, and here they have. The CVE was published on 15 October, Debian and Oracle Linux had fixed kernels out within two days, while Ubuntu and RHEL still have no fixed kernel to install two weeks later. So it's worth knowing which of your servers run which distribution, who handles updates, and when they can schedule a reboot.

Need a hand?

I build and run PHP and Laravel applications. If you need help checking your server or planning a kernel update and reboot, get in touch.

Sources

• Ubuntu: CVE-2026-98432 status per release
• Red Hat: CVE-2026-98432
• Debian security tracker: CVE-2026-98432
• CVE record: CVE-2026-98432
• Anthropic: discovering vulnerabilities with Claude
• Go Security Team: guidance on CVE-2026-98432 (oss-security)
• The Hacker News: Linux kernel TCP flaw with 9.8 CVSS score
• CSO Online: Anthropic AI model finds Linux kernel bug that leads to remote root access
• RFF: blocking the trigger until Ubuntu and Red Hat ship a kernel