Anthropic Says Claude Wrote a Remote Root Exploit for a Linux Kernel Bug That Two One-Line Changes Fix, and Red Hat and Ubuntu Have Yet to Ship the Patched Kernel

Anthropic says an unreleased Claude model wrote an exploit that gives a remote attacker a root shell on a Linux server with a multipath TCP (MPTCP) listener, using a kernel use-after-free tracked as CVE-2026-98432. The bug sits in the IPv4 TCP handshake code and dates from a commit made on October 2, 2015. The fix is two one-line changes, each swapping kfree for kfree_rcu, which Eric Dumazet dated October 1. It shipped in stable kernels 6.18.56 and 7.2.10 on October 11 and in the other stable branches that received it on October 15. When we checked at 10:27 UTC on October 31, 16 days after the CVE was published, Red Hat had released no patched kernel for RHEL 8, 9 or 10, and Ubuntu’s tracker showed the fix as pending for 22.04, 24.04, 26.04 and 26.10, with no security notice published.

The sources disagree about how much of this matters. Anthropic’s proof of concept needed 48 minutes to leak a kernel address and about five more to run a command as root, and it needed an MPTCP listener. The Go team and Red Hat say the flaw itself is in ordinary TCP, and a member of the Go team advises against hoping that no path exists without MPTCP. An MPTCP maintainer writes that it seems “very unlikely to have this attack working outside a lab”. Ratings run from 8.1 to 9.8. BleepingComputer reported a 5.9 denial-of-service rating from Red Hat, but we found no Red Hat page that shows it: archived copies show 8.1, and the live page now says Critical and 9.8, still marked preliminary. Below we set out the timeline, what the proof of concept requires, which servers are on that path, whether plain TCP is in scope, the ratings, where the patches stand, what to check now and what is still unknown.

What happened, in order

Times are UTC unless marked. Commit and release times come from GitHub’s API and the kernel.org change logs, record dates from the CVE record and its change history in the CVE Program’s GitHub repository, and weekdays and day counts are our arithmetic.

What Anthropic showed, and what its post leaves out

The Linux case is one of five attack chains in a post that Anthropic’s Frontier Red Team published on October 27. The others cover Chrome, Safari, Android and a Windows HTTP/3 crash, and we did not examine them. For Linux, the post says “After initial prompting, Claude wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction.” It describes two stages, first defeating kernel address randomization (KASLR) and then taking over control flow, and says a lost race “only fails the handshake without crashing the whole system”, so an attacker can retry until it works. In the proof of concept, “it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution”, a total of 53 minutes by our arithmetic and the figure BleepingComputer reports.

The post is short on conditions. It does not say how many connection attempts the 48 minutes involved, which kernel build or configuration the target ran, what network sat between the two machines, or whether the same chain works against a plain TCP listener. It publishes no exploit code. It does say the work used “an unreleased, internal research model”, and that Anthropic also found other remotely triggerable bugs in the kernel’s networking stack “which have since been patched upstream and publicly disclosed”, with this one given as the example. The kernel commit credits the report to Xinyang Ge, one of the seven contributors the post names, so the report reached the kernel project on or before October 1, 26 days before the post (our inference from the credit line and the commit date).

Which servers sit on the path Anthropic showed

The proof of concept needs an MPTCP listener, so the first question is whether anything on a server accepts MPTCP. Two defaults decide that. The kernel’s own documentation lists net.mptcp.enabled with a default of 1, but CIQ, which supports Rocky Linux, reports that MPTCP is “disabled by default on the tested kernels”, meaning the Rocky Linux and RLC Pro builds it tested. And Go’s networking package has accepted MPTCP on listeners by default since Go 1.24: the release notes say “ListenConfig now uses MPTCP by default on systems where it is supported (currently on Linux only)”, and the change that did it is dated August 28, 2024. A Go program built with 1.24 or newer, on a host where the kernel allows MPTCP, can therefore take MPTCP connections without anyone having chosen that.

The Go Security Team’s announcement, posted to golang-announce on October 29 and forwarded to the oss-security list, says the demonstrated exploit requires an MPTCP listener but “the underlying bug is not specific to MPTCP”. It tells Go users how to switch the default off, with GODEBUG=multipathtcp=0 in a program’s environment or a godebug multipathtcp=0 line in go.mod, and then calls that “a fragile mitigation”: “Accidentally leaving a single MPTCP listener exposed will still leave a system vulnerable.” The team’s first recommendation is a patched kernel, and it considers a change to Go’s default “premature”. The proposal to disable MPTCP by default, Go issue 82717, was opened a few hours before that announcement. It was still open, with eight comments, when we checked at 10:27 UTC on October 31.

Whether plain TCP is in scope

The CVE text describes the bug in the kernel’s TCP code, not in MPTCP: a freed IP-options buffer that a retransmitted connection request can still read while the kernel builds its reply. The kernel CNA’s scoring rationale, added to the record on October 24, rates attack complexity Low on the grounds that “Both racing sides are attacker-induced; multicore scheduling and heap grooming do not constitute conditions outside the attacker’s influence.” The fix’s commit message says IPv6 is not affected by this first issue because tcp_v6_syn_recv_sock() duplicates the options, and adds that a related IPv6 path, which only CALIPSO sets, “will be addressed in a separate patch”. We found no such commit touching net/ipv6/tcp_ipv6.c in the mainline repository through GitHub’s API on October 31.

Others read the same bug more broadly. In the Go issue, Damien Neil, who replied for the Go team, writes that the race “is not MPTCP-specific” and occurs “while handling TCP SYN packets containing IPv4 header options”, and that “nobody knows whether there is a viable path to RCE on a system which does not expose an MPTCP listener. Since the underlying race condition is not MPTCP-specific, I would recommend against hoping that there is not.” CIQ tested the narrower point: with net.mptcp.enabled=0 read back, “a plain TCP listener on every tested kernel still answered a SYN carrying a Record Route option and echoed the option in the SYN-ACK”. That shows the vulnerable code path is reachable over plain TCP. It is not an exploit, and CIQ does not claim one.

The sharpest dissent comes from Matthieu Baerts, whom the kernel’s MAINTAINERS file lists as an MPTCP maintainer, in the same thread. Baerts writes that Anthropic’s reproducer “was in a lab, sending a huge number of connections requests”. The comment says its writer is “pretty sure IPv4 options are already blocked in many networks by default for different security reasons” and concludes that “it seems very unlikely to have this attack working outside a lab”. It adds, “I have no idea how they got a 9.8 score in some places.” It also says the lab run used MPTCP because, by luck, it took only 48 minutes, “less than with TCP”. Read literally, that would mean a plain TCP listener can be attacked too, only more slowly, but the comment gives no source for the comparison and Anthropic’s post does not mention it. Anthropic’s post does not describe its lab, so the claim that the attack is lab-bound can be neither confirmed nor refuted from public material.

One bug, ratings from 8.1 to 9.8

The scores split on one metric. The kernel CNA scores attack complexity Low and gets 9.8. Red Hat’s earlier score, Amazon, Oracle and SUSE score it High and get 8.1. Every one of those vectors rates confidentiality, integrity and availability impact High, so none of these vendors scores this as a crash-only bug. Our reading is that the High group is scoring the race itself, while the CNA’s rationale, quoted above, is that the attacker controls both sides of it and can retry.

BleepingComputer writes that “Red Hat classifies the vulnerability as a potential denial-of-service issue that could cause a kernel crash, assigning it a lower severity score of 5.9 because exploitation is complex.” None of the Red Hat pages we could read says that. Both archived copies of its CVE page show 8.1 with confidentiality, integrity and availability impact all High, and the live page shows Critical and 9.8. The CVSS 3.1 formula gives 5.9 for that network, high-complexity vector when only availability is affected (our arithmetic), a vector no source we read uses. The Internet Archive holds only those two copies, so we cannot rule out that an earlier version of the page said 5.9. The denial-of-service wording does appear in Red Hat’s description, which says the issue “primarily results in a system crash leading to a Denial of Service (DoS) or potential memory corruption”, even though its score rates all three impacts High.

The bug is not in CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.30, released at 17:02 UTC on October 30), and FIRST’s EPSS gave it 0.445 percent, the 38.7th percentile, on October 30. BleepingComputer says there are no confirmed reports of exploitation in the wild, and we found none in the sources we read.

Where the patches stand

This is the state of each tracker at 10:27 UTC on October 31. BleepingComputer’s own patch-status paragraph matched what we found for Debian’s fixed versions, Ubuntu’s pending releases, Red Hat’s affected list and the Oracle, Amazon and SUSE fixes, so the one number we could not reproduce is the Red Hat score.

The upstream fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, plus mainline 7.3. The CVE record lists no fixed version below 5.10.

What to check now

Is the running kernel fixed?

Do not compare version numbers on a vendor kernel. Distributions backport fixes into kernels with other numbers, and Debian’s tracker shows the effect: its security build 6.12.113-1 is fixed while the older 6.12.107-1 is not. Use your distribution’s tracker or changelog. For RPM-based systems CIQ gives a changelog check with a control that must print more than zero, or the test proves nothing:

rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-20

The first number must be 0 until a fixed kernel is running, and the second must be above 0. CIQ adds that “A changelog result alone is not proof that a fix is present”, so confirm the version against your vendor’s advisory as well.

Does anything accept MPTCP?

Run sysctl net.mptcp.enabled. A 0 means MPTCP sockets cannot be created, and a 1 means listeners may negotiate it, which matters for Go programs built with 1.24 or newer. ss -Mltn lists MPTCP listeners: CIQ saw both tcp and mptcp rows for an MPTCP listener on RLC Pro LTS 9.6 and RLC Pro 10, but only the tcp row on RLC Pro LTS 8.10, so the sysctl is the check that works there. For a Go program, GODEBUG=multipathtcp=0 turns the default off, but the Go team calls that fragile and CIQ’s testing shows that “Disabling MPTCP is not enough.” We have no Linux host here and did not run these commands.

Can you filter IPv4 options until the patch arrives?

Red Hat’s bulletin and CIQ’s article both publish an nftables rule that drops IPv4 TCP packets whose header is longer than 20 bytes, which are the packets that carry IP options. Red Hat’s version, copied from its bulletin and spread over several lines:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Red Hat has administrators save it to a file, run sudo nft --check --file cve-2026-98432.nft, load it with sudo nft --file cve-2026-98432.nft, and remove it with sudo nft delete table inet cve_2026_98432 once the kernel is fixed. It says the rule “reduces exposure to this vulnerability but cannot fully prevent it” and tells readers to test it outside production first. CIQ reports that it tested Record Route and Timestamp options from a second host on the same network, and that IPv6, fragmented packets, other delivery paths and CPU cost were not tested. Neil wrote of this class of mitigation, “I have not confirmed this.” We could not test any of it.

Treat claimed exploit repositories as untrusted

Anthropic’s post publishes no exploit code. A GitHub search for the CVE number on October 31 returned 30 repositories, all created between October 29 and October 31, several of them described as proof-of-concept or trigger tooling, others as mitigation or detection scripts, and some with no description. We did not open, download or run any of them, and we do not link them. Code from an unvetted repository that claims to be a kernel exploit belongs only in a disposable lab.

What is still unknown

• Whether a plain TCP listener can be pushed to code execution. A member of the Go team says nobody knows, an MPTCP maintainer doubts it matters outside a lab, and Red Hat’s bulletin says the affected surface is broad.
• What the 48 minutes involved. The post gives no attempt count, kernel build or network conditions.
• When Red Hat and Ubuntu will ship. Red Hat’s score is still marked preliminary, and NVD has not scored the record.
• Whether anyone is exploiting it. No source we read reports exploitation, and CISA’s catalog does not list it.
• The IPv6 follow-up. The fix’s commit message promises a separate patch for a related IPv6 path, and we found none yet.

This is the latest in a run of Linux kernel stories here: see our posts on the Infinity Core kernel bugs, where Ubuntu and Amazon Linux lagged on a timer fix, and on the Zero Day Initiative kernel reports that reached public lists before a fix. For another bug found with an AI model, see the Brotli flaw found by OpenAI’s Codex Security.

Sources and method

We read Anthropic’s post, the CVE record and its change history in the CVE Program’s GitHub repository, the fix commit and its 2015 predecessor through GitHub’s API, the kernel.org change logs for 7.2.10 and the other six fixed releases, BleepingComputer’s report, the Go Security Team’s announcement, Go issue 82717 and the Go 1.24 release notes, Red Hat’s CVE page and bulletin together with Internet Archive copies of the CVE page from October 29 and October 30, CIQ’s article, and the trackers of Ubuntu, Debian, Amazon Linux, Oracle Linux and SUSE, as well as the NVD record, CISA’s catalog and FIRST’s EPSS data. The tracker data was queried between 10:00 and 10:30 UTC on October 31. The day counts, the 53-minute total and the 5.9 arithmetic are ours. We did not run or write any exploit code, we have no Linux host here to test the nftables rules or the commands above, and we did not open any third-party repository, so every statement about what the exploit does rests on Anthropic’s description of it.