Anthropic Claude Finds Linux Kernel Bug That Gives Root Access

Direct answer: Anthropic has disclosed that an unreleased Claude research model wrote a working exploit for a critical Linux kernel flaw, tracked as CVE-2026-98432, that can let a remote attacker run commands as root on a Linux server with a multipath TCP listener, without a login and without any user interaction. The underlying kernel bug is real, it has been fixed upstream and backported to maintained kernel branches, and the most important question for a small business is a simple one: has your hosting provider applied that fix yet?

What happened

On 27 October 2026, Anthropic’s Frontier Red Team published a research post titled, in essence, “Discovering and exploiting vulnerabilities in critical, real-world software with Claude.” The headline claim was striking: after initial prompting from a researcher, an unreleased internal Claude model wrote five working exploit chains, with little to no further human interaction, against widely used software. The five targets were Chrome, Safari, Android, Windows and Linux.

The Linux chain is the one that matters most for businesses, because it is the most severe and the most directly relevant to the servers that run websites, online shops, booking systems and back-office tools. According to Anthropic, the model produced a zero-click exploit: an attacker sends network packets to a Linux server running a multipath TCP (MPTCP) listener and ends up able to run arbitrary commands as root, the highest privilege level on the machine. No password, no phishing email, no clicked link and no logged-in user are needed in that scenario.

Coverage of the disclosure followed over the next few days, with CSO Online reporting the story on 30 October and The Hacker News covering the kernel flaw and Anthropic’s exploit claim in detail. That coverage is what brings the story to a wider business audience now, and it is also what lets us separate the parts that are independently documented from the parts that currently rest on Anthropic’s word alone. That distinction matters, and this article keeps it visible throughout.

The vulnerability itself was not discovered on 27 October. The Linux kernel’s CVE team published CVE-2026-98432 on 15 October 2026, and on 24 October it assigned the flaw a CVSS 3.1 score of 9.8 out of 10, which is the critical band. The fix was already in place upstream: kernel developers had corrected the code on 5 October, before the CVE was published, and the fix was then backported to every maintained stable kernel branch. Anthropic’s researcher Xinyang Ge is credited in the fix commit as the person who reported the bug, which independently ties Anthropic’s research to the real flaw even though the exploit code itself was not released.

How the flaw actually works

To understand why this bug scored so highly, it helps to understand what happens when a computer connects to a Linux server. Every time a device opens a connection, the server’s kernel, the core of the operating system, has to set that connection up. In this case the flaw sits in the code that handles IPv4 TCP connection establishment, specifically in how the kernel manages IP options during that handshake. IP options are extra fields that can be attached to packets, including options such as Record Route and Timestamp that record the path a packet takes.

The bug is a race condition. That is a class of flaw where two parts of a program run at the same time and the outcome depends on which one finishes first. Here, the kernel could free, or release, the memory holding the connection’s IP options while another processor was still reading that same memory. When software later uses memory after it has been freed, that is called a use-after-free bug, and it is dangerous because the freed memory can be reused for something else, letting an attacker steer what the kernel reads or runs.

Anthropic’s exploit, as described by the company, works in two stages. In the first stage, the attacker abuses the race so that the kernel sends back extra bytes in its replies. If one of those replies happens to contain a kernel memory address, the attacker learns where the kernel’s code sits in memory. That defeats a protection called Kernel Address Space Layout Randomization, or KASLR, which works by hiding those addresses so that an attacker cannot reliably aim an attack. In the second stage, the same bug is used to overwrite a callback pointer, a stored address the kernel calls when something happens, with the address of a payload the attacker had already placed in kernel memory. When the kernel calls that pointer, the payload runs, and in Anthropic’s proof of concept it ran a shell command of the attacker’s choice as root.

Two details make this chain unusually practical in a lab setting. First, losing the race does not crash the server. It only fails that one connection attempt, so an attacker can simply try again and again until the timing lines up. Second, the whole proof of concept was fast by human standards: Anthropic says leaking a kernel address took about 48 minutes, and reaching command execution took about five more minutes, for a total of roughly 53 minutes from the first leak to root. That is not instant, but it is a task a patient automated attacker could run in the background.

There is also an important wrinkle that honest reporting has to include. The CVE record and the kernel fix do not mention multipath TCP. The link between this CVE and servers running an MPTCP listener comes from Anthropic’s own post. Multipath TCP is an extension of ordinary TCP that lets a device use several network interfaces at once within a single connection, for example combining Wi-Fi and mobile data. It is plausible that Anthropic’s exploit path needs that listener, but the public record does not confirm it, and Anthropic’s post does not say whether servers without an MPTCP listener can be taken over in the same way. Until another team reproduces the chain, the exact attack path should be treated as Anthropic’s claim, while the underlying kernel bug and its fix are independently documented facts.

The wider disclosure: five exploit chains, not one

The Linux chain did not arrive alone. Anthropic says the same research model produced five exploit chains in total, covering Chrome, Safari, Android, Windows and Linux, and that every bug was reported to the relevant vendor and is now patched. The Windows chain, for example, is tracked as CVE-2026-33096 and is described as a remote crash of Windows machines that answer HTTP/3 using the built-in implementation. Microsoft lists that CVE as not exploited, according to independent summaries of the disclosure.

That broader picture is what makes the announcement significant beyond a single kernel bug. Anthropic’s argument is that frontier AI models can now find vulnerabilities and combine several smaller weaknesses into a working attack with relatively little human help. If that is right, the balance between attackers and defenders shifts in a specific way: finding a bug is no longer purely a human craft measured in days of expert labour, and the window between a flaw becoming known and someone building a working exploit for it may shrink. Anthropic has paired the disclosure with an expanded Cyber Verification Program for approved security staff, which suggests the company itself expects this capability to be handled carefully rather than handed out freely.

At the same time, it is worth keeping the claim in proportion. Anthropic did not publish the exploit code, the exact kernel version or the configuration it tested. No outside team has publicly confirmed the full chain end to end. And the vulnerabilities themselves were, in each case, real bugs that human researchers could also have found: the model accelerated the work, it did not invent a new law of physics. The sensible reading is that AI-assisted vulnerability research is now a serious factor in security planning, not that every system is suddenly defenceless.

Why a kernel bug matters more than an app bug

Most small businesses never think about the Linux kernel, and that is exactly why a kernel flaw deserves attention. The kernel sits underneath everything else on a server: the web server software, the database, the content management system, the shop platform and the security tools themselves all run on top of it. A flaw in an application usually gives an attacker access to that application. A flaw in the kernel can give an attacker control of the whole machine, including the ability to read data belonging to other applications, install persistent access, or use the server to attack others.

That is also why the 9.8 score, while genuinely high, needs context. The kernel CVE team’s score reflects a specific attack scenario: network-reachable, no credentials, no user interaction. Some vendors scored the same flaw lower, between 5.9 and 8.1, including Red Hat, Amazon, Oracle and SUSE, according to The Hacker News. Vendors often score a flaw for their own default configurations and mitigations, while the kernel team scores the flaw itself. Neither number is “wrong” on its own, but the gap is a useful reminder that a CVSS score is a starting point for prioritisation, not a verdict on your particular server. Your provider’s assessment of your configuration is what counts.

The other reason kernel bugs matter is their reach. The flaw affects code dating back to Linux 4.4, which means it has been present in kernels for a very long time and across many distributions. Fixed releases include 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7, according to CSO Online’s summary of the upstream fixes. In practice, most businesses will not install those kernels themselves: their hosting provider, cloud platform or managed IT firm will roll out a patched kernel as part of routine updates. The patch exists. The question is whether it has reached your server yet.

The patch gap: fixed upstream, not yet everywhere

Here is the part of the story that should drive action. As of 29 and 30 October 2026, Ubuntu and Red Hat Enterprise Linux had not yet released patched kernels for this flaw, according to CSO Online and The Hacker News, although several other distributions had already shipped security updates. That gap is normal in the sense that distributions need time to test and package a kernel, but it is uncomfortable when the flaw is rated critical and an AI-written exploit for it has been publicly described, even without the code.

If your business runs on Ubuntu or RHEL servers, or on a hosting platform built on them, you are in a waiting position, and waiting positions need a plan rather than just patience. Ask your provider directly: does our kernel include the fix for CVE-2026-98432, and if not, when will it? Get the answer in writing, in a support ticket, so there is a record. If you run your own server, check your kernel version and watch your distribution’s security announcements for the fixed release, then schedule the update and the reboot it requires.

There is a related detail worth noting for businesses that run modern application stacks. The Go Security Team said on 29 October that Go 1.24 enables MPTCP by default for listening sockets. Go is a programming language used to build a great deal of server software, so a default change like that could quietly increase the number of services listening with MPTCP enabled. That does not mean every Go service is vulnerable, and it does not change the underlying advice, which is to patch the kernel. But it is one more reason to ask your provider or developer whether MPTCP is exposed on your systems and whether you actually need it.

What it means for UK small businesses

For a UK small business, this story is not really about Anthropic, and it is not really about artificial intelligence in the abstract. It is about a mundane operational truth: most small firms outsource their server security without realising it, and a critical kernel flaw is the moment that outsourcing gets tested.

Start with what you actually run. If your website is on shared hosting or a managed WordPress plan, your provider manages the kernel and the patch will arrive, or should arrive, without you doing anything. Your job is to confirm it, not to assume it. A short ticket, “Please confirm whether our servers include the fix for CVE-2026-98432, and when a patched kernel will be applied if not,” is a reasonable, professional request, and a good provider will answer it plainly. If a provider cannot answer, that tells you something about the provider.

If you run a virtual private server or a dedicated server, the responsibility may be yours, or shared with whoever manages it for you. Check who applies kernel updates under your contract. Many “unmanaged” VPS plans leave patching to the customer, and many small firms do not realise they bought one. If that is you, and you do not have the skills in-house, this is a good moment to buy a few hours of a managed service provider’s time rather than to learn kernel patching under pressure.

Next, think about exposure. A server that is reachable from the internet with unnecessary services exposed is a bigger target than a server that only exposes what it needs. This is a good week to review, with your provider, which ports and services are open, whether old test sites, staging copies or forgotten subdomains are still live, and whether administrative panels are restricted to known addresses or protected by more than a password. None of that replaces the kernel patch, but it reduces the number of ways an attacker can reach the vulnerable code in the first place.

Then think about data. A root-level compromise is serious precisely because it can expose customer data: names, addresses, order histories, enquiry messages and, in the worst cases, payment-adjacent information. Under UK GDPR, a personal data breach must be assessed and, where it poses a risk to people’s rights and freedoms, reported to the ICO within 72 hours of becoming aware of it. You do not need to panic about that today, and this flaw has not been reported as exploited in the wild. But you should know, before an incident, who your data protection contact is, where your backups live, and whether those backups are isolated from the server they protect. A backup stored on the same compromised machine is not a backup.

Finally, think about your customers. If you take orders, bookings or enquiries online, a security incident is also a trust incident. Having a short, honest holding statement ready, and knowing who would send it, is cheap insurance. You will probably never need it for this flaw. The firms that handle incidents well are the ones that prepared the boring parts in advance.

A practical checklist for the next seven days

The following steps are deliberately small. None of them requires buying a new product, and together they cover the gap between “fixed upstream” and “fixed on your server.”

First, raise a ticket with your hosting provider or managed IT firm asking for the CVE-2026-98432 patch status and an expected date. Keep the ticket number. Second, if you manage your own server, check your kernel with the command uname -r, compare it with your distribution’s fixed release, and schedule the update and reboot. Third, ask whether multipath TCP is enabled or exposed on your servers, and whether it can be disabled or restricted if you do not use it. Fourth, review exposed services and close anything you do not recognise or no longer need. Fifth, confirm that backups are current and stored separately from the live server, and that you can restore from them. Sixth, make sure administrative access uses strong, unique passwords plus a second factor wherever the platform supports it. Seventh, note the date you checked, so that if a provider later says a patch was applied, you can verify it rather than take it on trust.

For firms that use a website agency, as many WeblifyAI clients do, the agency is a natural first call: ask them to confirm the patch status of the servers your site runs on and to record it in your next report. That is a normal part of website care, not an imposition, and it creates the paper trail that matters if a client or insurer ever asks what you did and when.

Honest limits / what to watch

This story has been reported carefully by the security press, and the careful parts are worth repeating. No exploitation in the wild has been reported for CVE-2026-98432, and it was not in CISA’s Known Exploited Vulnerabilities catalogue as of late October. That could change, and the catalogue is a lagging indicator, not a guarantee. The sensible posture is “patch promptly, don’t panic.”

The second limit is the evidence gap already noted: the full exploit chain has not been independently reproduced in public, the exploit code was not released, and the CVE record does not mention multipath TCP. It is possible that the practical conditions for the attack are narrower than the headlines suggest, for example limited to servers with an MPTCP listener in a particular configuration. It is also possible that further research will show a wider reach. Either way, the patch advice does not change, because the kernel bug is real and the fix is available upstream.

The third limit is the vendor patch timeline. Ubuntu and RHEL users are waiting on distribution packages, and waiting is where small firms are most exposed, because attention moves on. Set a calendar reminder for a week from now to re-check the ticket if no patch has landed. If your provider has still not answered by then, escalate, and consider whether that silence is acceptable for a business that holds customer data.

What to watch next is straightforward. Watch for Ubuntu and Red Hat patched kernels and for your provider’s confirmation. Watch for any report of in-the-wild exploitation, which would raise the urgency sharply. Watch for further independent analysis of Anthropic’s five exploit chains, which will test whether AI-assisted vulnerability discovery is as general as the announcement suggests. And watch for the policy conversation that will follow: if frontier models can write working exploits after a short prompt, the question of who gets access to that capability, and under what safeguards, will move from research blogs into boardrooms and regulators’ inboxes. Anthropic’s own expanded verification programme is an early sign of that conversation.

The broader lesson for small businesses is not that AI has made security impossible. It is that the time between a flaw being understood and an exploit existing for it may be getting shorter, which makes the unglamorous disciplines, patching promptly, knowing who patches what, keeping backups separate, and reducing exposed services, more valuable, not less. Those disciplines are also the ones a small firm can actually control, and they are the ones that will still matter when the next critical kernel flaw arrives, whether it is found by a human, by a model, or by both working together.

Key facts

FAQs

What is CVE-2026-98432?

It is a race-condition flaw in the Linux kernel’s IPv4 TCP connection handling that can lead to a use-after-free bug. The Linux kernel’s own CVE team scored it 9.8 out of 10, critical, because it is reachable over the network and needs no login or user interaction in the described attack scenario.

Did Anthropic’s AI really hack a Linux server on its own?

Anthropic says that after initial prompting from a researcher, an unreleased Claude research model wrote a working exploit chain in its lab that ran commands as root on a Linux server with a multipath TCP listener. The exploit code itself was not published, and no outside team has publicly reproduced the full chain end to end.

Are Linux servers being attacked through this flaw right now?

As of late October 2026, no vendor, CERT or the kernel CVE team had reported exploitation in the wild, and the flaw was not listed in CISA’s Known Exploited Vulnerabilities catalogue. That is reassuring, but it is not a reason to delay patching once your provider offers a fixed kernel.

How do I know if my business is affected?

If your website, shop or systems run on Linux servers, ask your hosting provider or IT support whether your kernel includes the fix for CVE-2026-98432. Most small businesses do not manage kernels themselves, so the provider’s answer is the one that matters. Check your kernel version with uname -r if you do manage your own server.

What should a UK small business do first?

First, ask your host or managed IT provider for the patch status in writing. Second, apply the fixed kernel when it is offered and reboot in your maintenance window. Third, check whether you actually need multipath TCP exposed, and close or restrict any network services you do not use.

Does this mean AI can now find any vulnerability?

No. Anthropic’s result shows that a frontier model, given a research goal and prompting, can chain weaknesses into working exploits in a lab. It does not show that AI can walk up to an arbitrary patched system and break in. Defence, patching and good configuration still decide most real-world outcomes.

Sources and further reading

This article is based on Anthropic’s Frontier Red Team disclosure of 27 October 2026, CSO Online’s reporting on 30 October 2026, and The Hacker News’ analysis of CVE-2026-98432. The kernel CVE record and the upstream fix commit provide the independently documented facts about the flaw and its fixed releases. Where Anthropic’s account goes beyond the public record, notably the multipath TCP condition, this article says so.

For related reading on this site, see our coverage of Mistral’s open-weights cyber-defence model and Anthropic’s AI safety bill and model-blocking debate.

Get a Free AI Consultation