KIungefiltert

· 4 min read · Auf Deutsch lesen

Linux kernel: 11-year-old TCP flaw found by Claude: what admins should do now

CVE-2026-98432 in the Linux kernel's IPv4 TCP code: Anthropic's Claude found it and wrote a root exploit. Debian, Oracle and SUSE have patches. Ubuntu and RHEL don't have fixes out yet.

securityAIself-hosting

Translated from the German original with an AI language model, approved by me. Read the original

There's a flaw in the Linux kernel's TCP code that has been there since version 4.4, so a bit more than eleven years. It's tracked as CVE-2026-98432, and the kernel CVE team rates it 9.8 out of 10. According to Anthropic, its AI model Claude found the bug and also wrote a working exploit for it. Some details have come out since my first post on X and in the WhatsApp channel. The main ones: several distributions now have patches, people disagree about how severe it is, and multipath TCP plays a role.

What happened

The bug is in the code that sets up new IPv4 connections. It's a race condition, which means two CPUs touch the same data at the same time and the result depends on which one gets there first. That leads to a use-after-free: the kernel reads memory it has already released. Specifically, the kernel hands the IP options from a connection request over to the new socket without copying them. The Hacker News and heise both report that IPv6 is not affected, because there the kernel does copy the options.

According to heise, the faulty commit dates back to October 2015. The kernel fix credits Anthropic researcher Xinyang Ge with reporting the bug. Anthropic says Claude built the exploit itself after "initial prompting." The exploit has two stages. First, the kernel leaks memory addresses, which defeats KASLR (the randomization of where the kernel sits in memory). Then a function pointer gets overwritten so that a command runs as root. If the attacker loses the race, only that one connection attempt fails and the system doesn't crash, so they can just try again. In Anthropic's test, the address leak took 48 minutes and code execution took five more. Anthropic hasn't published the code, the kernel version or the test setup.

There's one important caveat. Anthropic's exploit targeted servers running a service that listens via multipath TCP (MPTCP). That's a TCP extension that spreads one connection across several network paths. Nobody has said yet whether servers without MPTCP are just as exposed. Red Hat says any reachable TCP service is enough to trigger the race. According to heise, Go programs use MPTCP by default.

Why the severity ratings differ so much

The 9.8 comes from the kernel CVE team, and others see it differently. Red Hat gives 5.9 on its CVE page and 8.1 in its machine-readable advisory. Oracle and SUSE give 8.1, and Amazon gives 7.0. The disagreement is mostly about how hard it is to win the race. For me, what counts is this: the attack works remotely, needs no credentials, and a working root exploit exists, even though it isn't public. That's enough to put the update at the top of the list.

No attacks in the wild have been reported so far. Vendors, the CVE record and Anthropic all say nothing about active exploitation, and the flaw isn't in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Who is affected and where patches exist

Every kernel from 4.4 onward running IPv4 is affected, which covers practically every Linux server. Upstream fixes are 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. Here's where the distributions stood as of October 29, according to The Hacker News:

  • Debian: Trixie and Bookworm have patches.
  • Oracle Linux 7 to 10 (UEK): Patched since October 16.
  • SUSE: openSUSE Leap 16.0 and SUSE Linux Micro 6.2 are patched. Some SLES versions are still in testing.
  • Amazon Linux 2023: The kernel6.18 and kernel6.12 packages are patched. The rest is still pending.
  • Ubuntu (16.04 to 26.10): No fix released yet.
  • RHEL 8, 9, 10 and OpenShift 4: No fix yet. Red Hat first said fixes were "deferred to a future update." RHEL 7 is not affected.

What you should do

  1. Patch as soon as you can. Where updates are out, install them and reboot. A new kernel only takes effect after a restart.
  2. Watch the advisories. If you run Ubuntu or RHEL, check them every day.
  3. Start with exposed systems. Servers whose TCP services can be reached from the internet go first.
  4. Check for MPTCP. For Go services, the Go Security Team suggests GODEBUG=multipathtcp=0 as a stopgap. The team itself calls this fragile and says systems without MPTCP may still be vulnerable. It doesn't replace a patch. Red Hat says no mitigation meets its standards.

My take

Several experts reviewed and approved this bug eleven years ago, and now an AI model has found it, exploit included. heise author Jürgen Schmidt expects "a huge wave of vulnerabilities." I think that's realistic. Whatever defenders can find, attackers will find too, sooner or later. That makes patch cycles that take weeks a risk in themselves.

Sources