Anthropic Says Its AI Turned a Linux Flaw Into a Root Shell

A flaw in the part of Linux that sets up internet connections has been scored 9.8 out of 10 for severity, and Anthropic says its Claude model turned it into a working attack that gives a remote intruder full control.

The bug is tracked as CVE-2026-98432 ^[2]. A CVE is simply a public ID number for a known security flaw, so that everyone talks about the same thing. This one is a use-after-free bug in the Linux kernel ^[2], the core of the operating system that runs much of the world's servers. Kernel developers applied a fix on October 5, the kernel's CVE team published the record on October 15 and added the 9.8 score on October 24, according to The Hacker News ^[2]. On October 27, Anthropic described its exploit publicly ^[1].

A score like that makes headlines. It does not tell you whether your machine is in danger.

What does a 9.8 actually measure?

The score comes from CVSS, an open framework maintained by the security group FIRST for describing how severe a vulnerability is ^[3]. The Base score, the one you see in headlines, rests on the flaw's own technical traits and on a reasonable worst case across environments ^[3].

The kernel team's 9.8 assumes the attacker comes over the network, needs no special skill beyond a low level of complexity, holds no account or privileges, and needs no one to click anything ^[2]. It then assumes the damage could be high on three counts: secrets could be read (confidentiality), data or code could be changed (integrity), and the machine could be knocked out (availability) ^[2]. The team's rationale says the attacker can induce both sides of the timing problem at the heart of the bug ^[2].

So 9.8 is a statement about the ceiling. It is not a 98 percent chance that your server gets attacked. A hurricane category rates the wind, not whether your street floods.

FIRST says this itself. Its guidance is that the Base score is not, by itself, a risk assessment, and that users should weigh their own environment and exposure ^[6]. The framework has Temporal metrics for conditions that change, such as whether a fix or a public exploit exists, and Environmental metrics for local context ^[3]. Most headlines quote only the Base number.

What is a use-after-free bug?

A program needs memory to hold its working data, so it asks the system for a block. When it is done, it hands the block back. A use-after-free happens when the program keeps its note of where the block was and uses it anyway ^[2].

Think of a locker key. You return the locker, but you keep the key, and a few minutes later you open the locker without checking whose things are inside. If the system has meanwhile given that locker to someone else, you are now reading or changing a stranger's belongings. The program is not lying. It simply remembers a place that no longer belongs to it.

A crash is the mildest outcome, and it is the likely result of this flaw in Red Hat's assessment ^[2]. But if an attacker can control what gets put into that reused space, and can steer how the stale reference is used, the mistake can become a way to run the attacker's instructions. That is why the bug class has a long record as a source of serious exploits, and also why a bug is not the same as an attack.

Here the trigger is a race condition, which means two operations happen at nearly the same moment and the result depends on which finishes first. In this flaw the race can make the kernel read memory after it has been freed. The documented effects are leaked or corrupted kernel memory ^[2]. The fix delays freeing that memory until the kernel's other processors are done with it ^[2].

How did a bug become a root shell?

Here Anthropic's account matters, and so does a caution. Anthropic is both the researcher and a company selling the cyber skills of its models, so its performance claims are its own.

The company said an unreleased internal Claude research model wrote the exploit after initial prompting ^[1]. The exploit works in two stages. First, the race makes the kernel return extra bytes that can disclose a kernel memory address, which the attacker needs in order to aim the second stage. Second, the exploit uses the same bug to overwrite a callback pointer, a stored instruction saying where to jump next, and redirects execution to a payload, the attacker's own code, already placed in kernel memory ^[1].

The result in Anthropic's test was an attacker-chosen command run as root, the all-powerful account on a Linux machine, with no credentials and no user action. Anthropic said it took 48 minutes to obtain a kernel address and five more minutes to reach command execution ^[1].

Those numbers are less alarming than they sound, and more. A failed race, Anthropic said, only disrupts that one connection attempt, so the exploit can keep retrying ^[1].

Patience is cheap for software. Forty-eight minutes is nothing for a machine that never gets bored.

But the demonstration has a specific setting. It targeted a Linux server with a Multipath TCP listener ^[1]. Anthropic's post did not give the exact kernel build and configuration it tested, and it is not established that the root chain works against every server, or that systems without that listener are safe from related attacks ^[1][2].

Why does a bug in a core protocol matter more than one in an app?

TCP is the everyday way computers exchange data reliably over the internet. A flaw in one application affects the people who run that application. A flaw in the kernel's handling of new IPv4 TCP connections sits underneath everything on the machine that talks over the network, and it sits in code shared across Linux systems ^[2]. One mistake there can show up in many products at once.

Yet shared code does not mean universally reachable. This is where Multipath TCP comes in. MPTCP is an extension that lets one connection use several network paths, for instance to combine capacity or to switch when one path fails ^[5]. Linux documentation says applications normally request it explicitly, though tools can make applications use it ^[5].

The Hacker News adds that Go's security team said Go programs have used MPTCP by default for listening sockets since Go 1.24 ^[2]. That is a claim attributed to Go's team, and it covers Go programs. It is no reason to assume every server is exposed.

So the honest question for an administrator is not "do I run Linux?" but "does any service on my machine listen using MPTCP, and is that service reachable from outside?"

Why do the scores disagree?

The 9.8 is the kernel team's judgment. Others looked at the same flaw and counted differently. Red Hat's CVE page rated it 5.9, citing how hard it is to win the race and saying the likely result is a kernel crash, with memory corruption possible in theory and no demonstrated effect on confidentiality or integrity. Its machine-readable advisory listed 8.1 instead. Oracle and SUSE also scored it 8.1, and Amazon scored it 7.0 ^[2].

Those gaps are the lesson of the case. A score is an assessor's opinion about how easy the attack is and how bad the result could be. The kernel team assumed the attacker can induce both sides of the race, and in its assessment the outcomes were severe.

Red Hat stressed the difficulty and the lack of demonstrated impact, at least on one of its pages. Anthropic's demonstration, which came three days after the kernel team's score, is evidence for the worse reading in at least one configuration ^[1][2].

When you read an advisory, do not stop at the headline number. Read the vector, the short code string listing each assumption, and the rationale. Ask what the attack requires and what the assessor believes has been shown.

So how worried should you be?

Three questions hide inside that one number. How bad could it be? The 9.8 answers that. How reachable is it on my system?

That depends on kernel version, configuration and whether the exposed service uses MPTCP. Is anyone actually using it? As of the October 29 reporting, no vendor advisory, the CVE record, or Anthropic's post reported attacks exploiting this flaw in the wild ^[2]. A high score and a lab exploit are not evidence of real-world attacks.

Then comes the practical matter of fixes, and here the picture is uneven. The upstream fix, the one written for the main kernel, has also been copied back into older kernel versions that are still maintained, which developers call backporting. It is available in stable versions including 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10 ^[1][2][4].

But most people do not run a raw upstream kernel. They run what their distribution ships, on the distribution's schedule. As of October 29, Debian, Oracle Linux, SUSE and some Amazon Linux packages had fixed releases, while Ubuntu and Red Hat had not released fixed kernels and had given no date ^[2].

One hosting company, SiteGround, said on October 30 that it applied its own live patch across its servers without restarting them ^[4]. That is its account of its own systems and says nothing about anyone else's.

Whether you can reduce exposure in the meantime, for instance by switching off Multipath TCP (MPTCP), is not established by the advisories seen so far ^[2]. Check your vendor's own notice rather than a forum tip.

My view is that this flaw deserves attention, not panic, and the reason is the combination. A kernel networking bug rated critical by the people who maintain the kernel, plus a vendor demonstration that reached root in one setting, plus two big distributions still without a fix, makes this a patch-soon item for anyone running a public-facing Linux server. The missing ingredients for panic are real too: a specific configuration, no reported attacks, and rival scores as low as 5.9.

Watch two things next. One is when Ubuntu and Red Hat ship fixed kernels. The other is whether anyone independent reproduces Anthropic's exploit, and whether it turns out to need that MPTCP listener or something broader.