Linux TCP use-after-free (CVE-2026-98432): Anthropic’s exploit, vendor status, and what admins should do

A serious race-condition bug in the Linux kernel’s IPv4 TCP path, tracked as CVE-2026-98432, has drawn attention because the kernel team rated it 9.8/10 on the CVSS scale and because Anthropic says its AI model wrote an exploit that achieved root command execution against servers running a multipath TCP (MPTCP) listener. Vendors and distributions have diverging severity scores and staggered patch timelines, leaving many administrators deciding whether to wait for vendor kernels or apply upstream fixes directly.

What happened

The flaw is a use-after-free in the code that sets up new IPv4 TCP connections: the kernel hands IP options from a pending connection request to a newly created socket without copying them. If the socket is destroyed while another CPU is still reading those options for a resent connection, the kernel can read memory that has already been freed. That race condition can cause memory corruption or allow an attacker to read kernel memory.

Anthropic reported that its AI model (Claude) generated an exploit in two stages: first leaking kernel addresses (bypassing KASLR) by repeatedly inducing the race until a reply contained a kernel pointer; second, using a buffer overflow enabled by the same bug to overwrite a callback pointer with an attacker-supplied payload so that the kernel executes a shell command as root. In Anthropic’s tests, leaking a kernel address took roughly 48 minutes and reaching command execution took about five more minutes. The company’s post does not include exploit code, the specific kernel version or full configuration used, and it states the exploit targeted servers with an MPTCP listener.

Which Distributions Have a Fix

Why vendors’ CVSS scores differ

The kernel team added a 9.8 score to the CVE record; that score assumes an attacker can send IPv4 TCP Record Route or Timestamp options, then repeatedly resend to win the race and extract kernel memory, potentially leading to memory corruption or arbitrary code execution. The kernel team rated attack complexity low because the race is attacker-induced on both sides.

Several vendors assign lower severity because they assess the race as harder to win in real-world conditions or because demonstrated impacts differ. Red Hat’s CVE page initially rated the flaw Moderate (5.9), arguing the race is difficult to win and most likely outcomes are crashes rather than confidentiality or integrity loss; Red Hat’s machine-readable advisory later listed the flaw as Important (8.1). Oracle, SUSE and others also score it 8.1; Amazon assigned 7.0. Differences hinge largely on the perceived attack complexity and the likelihood of achieving exploitation versus causing a crash.

Technical detail: how the bug works

• The race occurs during the TCP handshake when IP options attached to a pending request are handed to the new socket without being copied.
• If another CPU is concurrently reading those options while the socket is freed, the kernel can read memory that has been freed (use-after-free).
• IPv6 is not affected because the kernel copies IPv6 options.
• The bug was introduced in Linux 4.4; kernel developers applied a fix (making the kernel wait until other CPUs complete reads before freeing the options) prior to the CVE publication.

Anthropic’s exploit and limitations reported

Anthropic reports the exploit chain requires an MPTCP listener in the scenarios it tested; the CVE record and the kernel fix itself do not reference MPTCP. Anthropic’s write-up does not disclose the exact exploit code, the kernel version tested, or full configuration details that would let others reproduce the results. As of the last reporting date, there have been no confirmed in-the-wild attacks reported by vendor advisories, the CVE entry, or CISA’s Known Exploited Vulnerabilities catalog.

What administrators should do now

• If your distribution has released a fixed kernel package, install it. Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixes for at least some kernels; the table above lists the specific packages and advisories where available.
• If you build kernels yourself, apply the upstream fix or upgrade to a patched stable kernel. The kernel fix is present in versions including 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel team recommends updating to the latest stable kernel instead of cherry-picking individual commits.
• For distributions without an available vendor fix (notably some Ubuntu and RHEL kernels as of the reporting date), monitor vendor advisories closely. There are no widely available, easy-to-deploy mitigations listed by vendors, and Red Hat has stated no mitigation meets its standards for broad deployment and stability.
• If your environment exposes multipath TCP listeners or accepts IPv4 IP options such as Record Route or Timestamp, prioritize patching public-facing systems once fixes are available. Vendor advisories and Anthropic’s post do not state whether disabling MPTCP or blocking incoming packets with IP options measurably lowers risk; treat such configuration changes as potential mitigations that require testing.

Final thoughts

CVE-2026-98432 is a high-impact kernel race that demonstrates how subtle concurrency issues in core networking code can lead to serious consequences. The divergence between the kernel team’s 9.8 score and some vendors’ lower scores reflects differing judgments about how practical exploitation is in real-world deployments. Where vendors have shipped patched kernels, apply them; where fixes are pending, follow vendor guidance and prepare to update promptly once vendor-supplied packages are available.

Licensed under CC BY-ND 4.0 International