An AI Found a Critical Linux Bug, Then Wrote the Exploit in 53 Minutes

A new Linux kernel vulnerability, CVE-2026–98432, carries a CVSS severity score of 9.8 out of 10, which is about as bad as these get. It affects Ubuntu, Red Hat, and many other distributions, and when the news broke in late October 2026 several of them did not yet have a patch out. If you run a public facing Linux server with a particular TCP feature turned on, this is one to act on rather than file away.

The flaw itself is serious, but ordinary. A race condition in kernel networking code is the kind of bug that surfaces a few times a year. The part that makes this one worth writing about is that an AI found it and then wrote the exploit, and did the exploit part in under an hour.

What the bug actually is

The flaw lives in the code that sets up new IPv4 TCP connections. When a connection completes its handshake, the kernel hands the IP options stored with the pending request over to the new socket without making its own copy. If that socket is torn down while another CPU core is still using those options to answer a recent connection request, the kernel ends up reading memory it has already freed. That is a use after free bug, one of the most common and most dangerous classes of memory safety flaw.

The deeper cause is a race between 2 CPU cores touching the same piece of memory. One core frees it while another is still reading it. If the kernel then reuses that freed memory for something else, an attacker who can influence what lands there can steer the kernel into doing something it should never do. On a networked service, that influence can arrive as a crafted packet, which is why a memory bug in the TCP path is so much worse than the same bug somewhere quieter.

IPv6 is not exposed to this, because the kernel copies the options for IPv6 connections instead of sharing them. The bug was introduced back in Linux 4.4, which means it sat in the kernel for years before anyone caught it.

The multipath TCP angle

The attack that Anthropic demonstrated targeted servers running a multipath TCP listener, usually written MPTCP. Ordinary TCP uses a single network path for a connection. MPTCP lets a connection use several paths at once, so a client could ride a wired link, Wi-Fi, and a cellular link together and hold the session steady as one drops. It is useful, and it is not on by default on most systems.

One caveat matters here. Neither the CVE record nor the kernel fix actually names MPTCP. The link between the feature and this exploit comes from Anthropic’s own write up. Red Hat’s position is broader, that any exposed TCP service could let a remote attacker trigger the race, so I would not treat MPTCP as the only way in. To check whether the feature is enabled on your system, you can read the net.mptcp.enabled setting through sysctl. A value of 1 means it is on.

If you are a regular desktop Linux user, you are probably not affected, because MPTCP is not something most machines turn on. The population that needs to move is server operators, especially anyone with a box facing the public internet, and anyone who once enabled MPTCP for a project and forgot.

How the use after free happens, at a conceptual level. Two cores, one freed buffer, one unlucky overlap. Source: CVE-2026–98432, kernel advisory

The fix is 2 lines, and it already exists

The good news is that kernel developers fixed this on 5 October 2026, about 10 days before the CVE was published. The fix is small, 2 lines in effect. It changes how the kernel frees those IP options, so that instead of releasing the memory immediately, it waits until every CPU core that might still be reading it has finished.

The mechanism it uses is called RCU, read copy update, a synchronization scheme built into the kernel that lets many cores read shared data safely while guaranteeing the memory is not reclaimed out from under them. In practice the fix swaps an immediate free for a deferred one that respects any reader still in flight. The kernel security team’s advice is to update to the latest stable kernel your distribution ships rather than hand applying the 2 line change yourself, because the surrounding code matters and a partial patch can go wrong.

Xinyang Ge, a researcher on Anthropic’s team, is credited in the kernel fix for reporting the bug.

Who is patched and who is not

The fix landing upstream is only half the battle, because a distribution user gets it only when their vendor ships an updated kernel package. As of late October 2026 the picture was uneven. Debian had fixes out. Oracle Linux had a fix. Amazon Linux 2023 had a fix in its 6.18 kernel from 24 October. SUSE’s Micro and Leap builds had fixes landing.

On the other side, Ubuntu had not shipped across its supported releases and marked the work in progress at high priority, with the oldest releases simply listed vulnerable. Red Hat Enterprise Linux 8, 9, and 10 were affected with no release date at first, though RHEL 7 was never affected. Several SUSE enterprise builds were still in testing. So the honest status when this broke was that the patch existed but had not reached everyone, which is the dangerous window for any disclosed flaw.

The severity scores also disagreed, and the disagreement is informative rather than sloppy. The kernel CVE team rated it 9.8, treating the attack as low complexity. Red Hat initially called it moderate at 5.9, arguing a race condition like this is genuinely hard to win, so a crash is more likely than a clean takeover. Red Hat then raised its own advisory to important at 8.1 on 29 October, acknowledging the real confidentiality and integrity impact. Oracle and SUSE landed at 8.1 too, and Amazon rated it 7.0. The number you believe depends on how likely you think an attacker is to win the race reliably, and reasonable security teams disagreed on that.

Same bug, different scores. The kernel team and the distributions did not agree on how dangerous it is. Source: vendor advisories, Oct 2026

The part that actually matters, an AI did this

On 27 October 2026 Anthropic’s Frontier Red Team published a report describing how one of its AI models found serious vulnerabilities across real, security critical software, and in several cases built working exploits for them. Anthropic did not name the model publicly, describing it only as an unreleased, internal research model. That detail matters, because it means the capability on display here is ahead of anything you can currently use yourself. Linux was one target. The others included Google Chrome, Apple Safari, Android, and Windows.

On Chrome, the model chained bugs to escape the browser sandbox and pop a calculator on the host machine, the classic proof that you have won code execution. That work alone produced 62 CVEs that were assigned and patched by Chrome 156, including 13 sandbox escapes and 21 flaws that could have compromised the renderer. On Safari, it bypassed the same origin protection to read cookies, history, and session data from any site. On Android, it pulled photos and personal files off a locked Pixel 9 over a USB connection. On Windows, it found a remotely triggerable kernel bug in the HTTP/3 code that could crash servers, tracked as CVE-2026–33096. The Linux bug is the one covered here, a zero click path to remote root on an MPTCP listener.

The timing is the detail I keep coming back to. For the Linux exploit, Anthropic reported that the model took about 48 minutes to leak a kernel address and defeat the memory randomization defense, then about 5 more minutes to reach command execution. Call it 53 minutes from flaw to working root exploit. A human expert can do this kind of work, but it takes days to weeks, and there are not many humans who can do it at all.

The exploit step, which has always been the slow and expensive part, took under an hour. Source: Anthropic Frontier Red Team, Oct 2026

Why 53 minutes changes the threat model

Security has always run on an asymmetry of effort. Finding a deep memory corruption bug and turning it into a reliable exploit is slow, specialized, expensive work, which is the main reason most disclosed vulnerabilities never become real attacks. The exploit is harder to build than the bug is to find, and that gap is a lot of what has kept defenders alive.

An AI that can do the exploit step in under an hour compresses that gap. It does not make impossible attacks possible, since a skilled human could already do this. It makes expensive attacks cheap, and it makes rare expertise common. The same capability cuts both ways. Anthropic used it to find and responsibly disclose these flaws, giving vendors 90 days to patch before any detail went public and a further 45 days after that. A different operator with the same kind of capability and no disclosure ethics is the threat this foreshadows.

I do not think this means the sky is falling. The flaws found here got fixed, and defenders get to use the same tools to find bugs before attackers do. What changes is the clock. The window between a bug existing and a working exploit existing used to be the defender’s friend. It is shrinking, and the practical response is boring and correct. Patch faster, reduce what you expose to the internet, and stop treating a race condition as too hard to exploit just because it was hard last year.

This is a trend, not a one off

It would be easy to read this as a single dramatic demo from one lab, and miss that it is part of a line. In November 2024 Google’s Big Sleep agent found a real zero day in SQLite, a widely used database engine, which was reported at the time as the first instance of an AI finding a previously unknown exploitable memory safety bug in real world code. Since then the results have gotten steadily more serious, and this Anthropic report, with working exploits across 5 major platforms and dozens of patched CVEs, is the current high water mark rather than an outlier.

The direction is clear enough. AI systems are getting good at the two hardest parts of offensive security at once, spotting a subtle bug in a huge codebase and then proving it is exploitable. Both of those used to be gated by scarce human expertise. Neither is anymore, or at least not to the degree it was. The defensive side gets the same tools, which is the only reason this is survivable, but the people who patch slowly and the software nobody has audited in years are now exposed to a kind of scrutiny they never faced before. Some of that scrutiny will come from defenders and some from attackers, and the software does not get to choose which arrives first.

What to actually do

If you run Linux servers, update to the patched kernel your distribution ships as soon as it is available, and watch your vendor’s security advisory if it is not out yet. If you cannot patch immediately and you do not need multipath TCP, disabling that feature closes the demonstrated attack path for now. Do not hand apply the 2 line kernel change on your own, because the kernel team specifically advised against it.

If you run a normal desktop, check whether MPTCP is enabled, which it probably is not, and otherwise keep your system updated the way you should anyway. The bug is severe, the fix exists, and the only thing standing between the two for most people is the time it takes a vendor to ship a package and an admin to install it.