Anthropic reported on October 27 that its Claude model, after initial prompting from a researcher, wrote a working exploit for a critical Linux kernel vulnerability (CVE-2026-98432) that can grant an unauthenticated remote attacker root-level command execution — and as of this week, Ubuntu, Red Hat Enterprise Linux, and several other major distributions still have no official fix released (The Hacker News, 2026). If your business runs Linux servers — and most web hosting, application backends, and cloud infrastructure does somewhere in the stack — this is worth checking today, not filing away as a theoretical research story.
What Is the Actual Vulnerability?
CVE-2026-98432 is a race condition in how the Linux kernel sets up new IPv4 TCP connections, dating back to kernel version 4.4. During the connection handshake, the kernel hands off certain connection data without copying it first; if the original connection is destroyed while another process is still reading that data, the kernel ends up reading memory that's already been freed. IPv6 isn't affected, because the kernel handles that data differently there. The fix was committed on October 5, roughly ten days before the CVE was even published, and makes the kernel wait until all processes are finished reading the data before freeing it.
What Did Anthropic Actually Demonstrate?
Anthropic's Claude model wrote a two-stage exploit: first using the race condition to leak a kernel memory address (defeating a security protection called KASLR that normally hides where kernel code lives in memory), then using the same underlying bug to overwrite a function pointer and run an attacker-chosen command as root. In Anthropic's test, leaking the kernel address took 48 minutes, and reaching full command execution took five minutes more — and because losing the race condition just fails that one attempt without crashing the system, an attacker can simply keep retrying until it succeeds. Anthropic's scenario specifically targeted servers running multipath TCP (MPTCP), though whether servers without that specific configuration enabled face the same exploitation path isn't addressed in the public reporting.
Is This Actually Being Used Against Real Targets Right Now?
As of this week, no — there are no confirmed reports of this vulnerability being exploited outside Anthropic's own research, and it doesn't appear on CISA's Known Exploited Vulnerabilities catalog. That said, vendor risk assessments disagree sharply on severity: the kernel security team scored it 9.8, while Red Hat's own advisory rates it 8.1 and states plainly that "no confidentiality or integrity impact has been demonstrated" outside the specific research scenario, with a kernel crash considered the more likely practical outcome. The gap between "a model wrote a working exploit in a lab" and "this is actively dangerous to your specific server" is real — but it's also the kind of gap that tends to close quickly once a vulnerability is public and widely discussed.
Which Systems Are Actually Patched Right Now?
Coverage is inconsistent and changing day by day. Debian, Oracle Linux, SUSE Linux Micro, and recent Amazon Linux 2023 kernel builds already have fixes released. Ubuntu (every actively supported version), Red Hat Enterprise Linux 8 through 10, and OpenShift 4 do not yet have an official patch, with vendors describing fixes as still in progress. Anyone building a custom kernel should move to one of the specifically fixed versions (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, or 7.3 and later) rather than attempting to apply the fix piecemeal, since the kernel community doesn't support cherry-picking this kind of change into an older base version.
What Should a Business Do If There's No Patch Available Yet?
Check your specific distribution and version against current vendor advisories regularly rather than checking once and moving on, since several major vendors are actively working on fixes that could ship at any point. Neither the official advisories nor Anthropic's research state whether disabling multipath TCP or filtering incoming connections that carry certain IP options would meaningfully reduce risk in the meantime, so there's no officially endorsed interim workaround to fall back on — which makes tracking the patch timeline for your specific systems the most useful thing to actually do right now. Given that this case shows AI models can now meaningfully shorten the distance between "a vulnerability is disclosed" and "a working exploit exists," treating patch windows as shorter than they used to be is a reasonable adjustment regardless of how this specific vulnerability plays out.
Frequently Asked Questions
What is CVE-2026-98432?
It's a critical race condition vulnerability in the Linux kernel's handling of new IPv4 TCP connections, which can allow memory corruption and, under specific conditions demonstrated by Anthropic's research, remote root-level command execution.
Did AI actually write a working exploit for this vulnerability?
Yes. Anthropic reported that its Claude model, given initial prompting, produced a working two-stage exploit achieving kernel memory disclosure and root command execution against a server configured with multipath TCP.
Is my Linux server actually at risk right now?
Risk depends heavily on your specific distribution, kernel version, and configuration. There are no confirmed real-world attacks using this vulnerability as of this report, but vendor patch availability varies significantly, so checking your specific system against current advisories is the right next step rather than assuming you're covered or exposed.
Which Linux distributions have a patch available?
Debian, Oracle Linux, SUSE Linux Micro, and recent Amazon Linux 2023 builds have released fixes. Ubuntu and Red Hat Enterprise Linux, among others, did not have an official patch available as of late October 2026.
What should I do if there's no patch for my distribution yet?
Monitor your vendor's security advisories closely for a release, since several vendors have fixes in progress, and avoid attempting to cherry-pick the kernel fix into a custom build — the kernel community recommends moving to a fully updated kernel version instead.