Linux kernel bug found by Claude is now Critical, and Ubuntu and RHEL still have no fix

Four days ago, Anthropic showed that one of its unreleased Claude research models had turned a quiet Linux kernel patch into a working remote root exploit. At the time, the story sounded like a milestone for AI security research with a reassuring footnote: the bug was already fixed upstream. By Friday, October 30, 2026, that footnote had worn thin. Red Hat raised its rating for the flaw, CVE-2026-98432, to Critical with a CVSS score of 9.8 and published an emergency security bulletin. The Go Security Team warned that every Go server on Linux opens exactly the kind of socket the public exploit targets. And two of the most widely deployed server distributions, Ubuntu and Red Hat Enterprise Linux, still had no fixed kernel to install.

This is a follow up to our report on how Anthropic's Claude model built exploit chains for Chrome, Safari and Linux. That piece covered the research. This one is about the gap that opened afterwards, between a fix that existed in the kernel source for weeks and the machines that actually run it.

What the bug is

CVE-2026-98432 is a use-after-free in the IPv4 part of the Linux TCP stack. When a server accepts a new connection, the kernel turns a pending connection request into a full socket in a function called tcp_v4_syn_recv_sock(). During that step, the IP options that arrived with the client's first packet are handed over from the request to the new socket without being copied. If the client retransmits its opening SYN at just the wrong moment, another CPU core can still be building a SYN ACK reply from those same options while the first core has already freed them.

That is a classic race condition, and the consequence is memory that the kernel reads or writes after it has been released. Depending on what lands in that memory, an attacker can leak kernel data or overwrite it with a payload of their choosing. The upstream fix is small: the option structures are now released with kfree_rcu(), which waits for a so called RCU grace period, so no other code path can still be using them when they disappear.

The flaw is old. According to the kernel CVE record it was introduced in Linux 4.4, a kernel released in early 2016, so practically every Linux server, virtual machine and container host of the last decade carries the vulnerable code unless it has been patched this month. IPv6 is not affected by this particular path. Fixed upstream kernels are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and the 7.3 series.

Why multipath TCP turned it into a remote root

On paper, the race is hard to win. Anthropic's model found a way to make it practical by aiming at a multipath TCP listener. Multipath TCP, or MPTCP, is an extension that lets one connection use several network paths at once, for example Wi Fi and mobile data on a phone, and Linux has supported it in the mainline kernel for several years. The code paths around MPTCP listeners gave the exploit a far better chance to hit the timing window and to shape the freed memory.

Anthropic described the result as a two stage attack. The first stage repeatedly triggers the race to leak a kernel address and defeat KASLR, the randomization that normally hides where kernel code sits in memory. In the demonstration this took about 48 minutes. The second stage used that knowledge to write a payload and obtain a root shell about five minutes later. A lost race does not crash the machine, which means an attacker can simply keep trying, quietly, until it works. No credentials and no user interaction are needed. The attacker only has to reach a listening port.

Anthropic says the exploit was produced by an unreleased Claude research model after initial prompting, and credits its researcher Xinyang Ge as the reporter. There are no public reports of exploitation in the wild, and the flaw was not listed in the CISA Known Exploited Vulnerabilities catalog as of October 28. But a detailed public write up of a working remote root path is exactly what shortens the time until someone else tries.

Red Hat goes from Moderate to Critical

The scoring history shows how differently vendors read the same bug. When the CVE was first published on October 15, it had no score at all. The kernel CVE team added a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which is 9.8, on October 24. Oracle and SUSE settled on 8.1, Amazon on 7.0, and Ubuntu gave it a High priority with a CVSS v4 score of 8.3.

Red Hat was the outlier. As late as October 29, its CVE page still listed the issue as Moderate with a score of 5.9, while its own advisory data already showed Important and 8.1. On October 30, Red Hat published security bulletin RHSB-2026-016 and moved to Critical with the full 9.8. Its statement is blunt: an unauthenticated remote attacker can cause kernel memory corruption or an immediate crash over standard IPv4 TCP traffic, and default enterprise configurations accept TCP connections without special tuning, so the exposed code path is everywhere. Red Hat says it is expediting fixes.

Note what changed in the wording. Red Hat's bulletin describes the bug as affecting any system with a vulnerable kernel and IPv4 TCP networking enabled. The public exploit needs an MPTCP listener, but the underlying use-after-free does not. Red Hat, the Go team and other analysts all make the same point: MPTCP is the easiest door, not the only one.

Who has a fixed kernel and who is still waiting

This is where the story stops being about AI and becomes about patch logistics. Some distributions moved within days of the CVE. Debian shipped a fixed kernel for Debian 13 trixie (6.12.113) on October 16 and updates for Debian 12 on October 17 and October 22. Oracle released fixed Unbreakable Enterprise Kernel builds on October 16. Amazon Linux 2023 fixed its kernel6.18 package on October 24 and kernel6.12 on October 29. SUSE Linux Micro 6.2 and openSUSE Leap 16.0 have fixed kernels.

Others had not, as of October 30. Ubuntu's tracker still listed every supported release from 16.04 to 26.10 as vulnerable, with the fix marked as work in progress. Red Hat lists RHEL 8, 9 and 10 and OpenShift 4 as affected without a released fix, and says products built on the RHEL kernel, including RHEL CoreOS, OpenStack and Virtualization, are potentially affected too. RHEL 7 is not affected. Several SUSE Linux Enterprise Server releases, 15 SP4 to SP7 and 16.0, were still in testing or in progress, and the default kernel of Amazon Linux 2023 was still pending.

There are good reasons for some of the delay. Enterprise kernels are heavily backported, and a fix that is a few lines upstream may need careful adaptation to code that diverged years ago. Still, the timing is awkward. The upstream fix was merged on October 5. Anthropic's exploit details went public on October 27. For many of the most common server images on the internet, administrators had nothing to install when the attack technique became public knowledge.

The Go detail that widened the blast radius

On October 29, the Go Security Team posted to the oss-security mailing list with an uncomfortable reminder. Since Go 1.24, the standard library enables MPTCP by default for listening sockets on Linux. That means a large share of modern cloud software, from API servers and reverse proxies to Kubernetes components and countless internal tools written in Go, may be running MPTCP listeners without its operators ever having opted in. The kernel only uses MPTCP if it is enabled there too, but on many distributions it is.

The Go team offered a mitigation: set the environment variable GODEBUG=multipathtcp=0, or add a godebug multipathtcp=0 line to go.mod and rebuild. Programs that call SetMultipathTCP themselves override both settings. The team was careful to call this a fragile mitigation. It removes the most convenient path for the public exploit, but the bug itself is not specific to MPTCP, and upgrading the kernel remains the real fix.

What administrators can do now

The first step is simple: check whether your distribution has a fixed kernel, install it and reboot. Kernel fixes do not take effect until the new kernel is running, and live patching coverage varies by vendor. Where a fix exists, that is the whole answer.

Where it does not, the options are partial. Red Hat's bulletin includes an nftables rule that drops incoming IPv4 TCP packets carrying IP options, which are rare in ordinary traffic because normal TCP options live in the TCP header, not the IP header. Red Hat says this reduces exposure but cannot fully prevent exploitation, and asks admins to test it before deploying. Other analysts suggest disabling MPTCP system wide with the sysctl net.mptcp.enabled=0 on machines that do not need it, and checking for MPTCP listeners with ss -Mltn. For Go services, the GODEBUG switch removes the default MPTCP listener. None of these replace the kernel update, and Red Hat explicitly says no mitigation meets its usual standards.

It also makes sense to look at exposure. Machines that accept inbound TCP connections from the internet, especially cloud hosts running Go based services, should be first in line. Internal hosts that only talk to trusted networks buy some time, but a vulnerability that needs nothing more than a reachable port is a good candidate for lateral movement once an attacker is inside.

Why it matters

The technical part of this story is a familiar one: an old race condition, a small fix, a complicated rollout. What is new is how the clock started. A frontier AI model did not only flag the bug, it produced a reliable exploit path in under an hour of runtime, and its developer published the method. That is the kind of capability security teams have been warning about for two years, and it changes the economics of the gap between upstream fix and deployed patch.

Linux kernel security has long relied on the fact that turning a race condition into a reliable exploit takes rare skill and a lot of time. If that work gets cheaper, the comfortable weeks between a quiet upstream commit and a distribution update become dangerous. The kernel CVE team already issues CVEs for nearly every fix, partly because it argues any bug can be a security bug. Cases like this one strengthen that argument and put pressure on distributions to treat the CVE stream as a deadline rather than background noise.

There is also a lesson about defaults. Go turning on MPTCP for listeners was a reasonable engineering choice for performance and resilience. Nobody expected it to decide which servers were exposed to a kernel race condition. Every default that widens the attack surface of the kernel is now a little more expensive, because the tools for finding the weak spots behind it are getting better fast.

Dany's take

I like that Anthropic published this, and I like even more that the bug was reported and fixed before the write up. That is how responsible disclosure should work, AI or not. But this week shows the uncomfortable side of the same coin. The defenders did their part early, the upstream fix landed on October 5, and still a big part of the server world had nothing to install when the exploit story hit the news. Red Hat needing two weeks to move from Moderate to Critical tells you that vendors are still scoring kernel bugs for a world where exploits take months to write.

If you run Linux servers, do not wait for the next headline. Check your kernel version today, patch where you can, and if you run Go services on Ubuntu or RHEL, set GODEBUG=multipathtcp=0 until the update arrives. And if you build AI security tools, this is the benchmark that matters: not how many bugs a model finds, but how quickly the fix reaches real machines.

Sources

• Anthropic: Discovering vulnerabilities with Claude, October 27, 2026
• Red Hat security bulletin RHSB-2026-016: Use-after-free, kernel IPv4 (CVE-2026-98432)
• Red Hat CVE page for CVE-2026-98432
• Ubuntu security tracker: CVE-2026-98432
• Linux CVE announce list: CVE-2026-98432, October 15, 2026
• Go Security Team on oss-security: Go programs and multipath TCP, October 30, 2026
• Go issue 82717
• LWN: Remote code execution on Linux systems with multipath TCP
• The Hacker News: Linux kernel TCP flaw with 9.8 CVSS
• CSO Online: Anthropic AI model finds Linux kernel bug that leads to remote root access
• Corgea: CVE-2026-98432 analysis, MPTCP and Go