The Linux kernel flaw tracked as CVE-2026-98432 carries a 9.8 out of 10 CVSS score from the kernel's own CVE team, but major distribution vendors differ sharply on whether it really enables remote root takeover and when patches will arrive.
The bug: an IPv4 TCP handshake use-after-free
The bug is a race in the code that sets up new IPv4 TCP connections. When a connection completes, the kernel hands the IP options attached to the pending request to the new socket without copying them. If that socket is destroyed while another CPU is still using the options to answer a resent connection request, the kernel can read memory it has already freed — a classic use-after-free.
IPv6 is not affected because the kernel copies the options for IPv6 connections. Kernel developers applied a fix on October 5 that makes the kernel wait until other CPUs finish reading the options before freeing them; that fix was applied "ten days before the CVE was published," according to the published record.
Anthropic's post: Claude wrote an exploit and linked the bug to MPTCP
Anthropic said on October 27 that its AI model, Claude, wrote an exploit that uses the flaw to let a remote attacker with no credentials run commands as root on Linux servers with a multipath TCP (MPTCP) listener. The kernel fix and the CVE record do not mention MPTCP; the connection between the feature and the bug comes from Anthropic's post.
Anthropic described the exploit as two-stage. First, the race can cause the kernel to send extra bytes back to the attacker; once a reply contains a kernel address, the attacker can bypass KASLR (the kernel's memory address randomization). Second, the exploit overflows a buffer and overwrites a callback pointer with an address of attacker-supplied payload in kernel memory; when the kernel later invokes that pointer, the payload executes a shell command as root.
Anthropic reported that in its test leaking a kernel address took 48 minutes and reaching command execution took an additional 5 minutes. The company did not publish the exploit code, the kernel version, or the test configuration. Anthropic's post links the working root exploit specifically to systems running a multipath TCP listener; it does not say whether servers without one can be taken over the same way.

Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogDistribution patch status as of October 29
Upstream developers say the flaw "was patched upstream and backported to all maintained stable kernel branches." For distribution users, that upstream fix reaches them only when each vendor ships an updated kernel package.
Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixed packages for at least some kernel releases. Ubuntu and Red Hat Enterprise Linux (RHEL) had not released a fixed kernel as of October 29. Ubuntu also lists its cloud, FIPS, and real-time kernels as vulnerable or work in progress. Red Hat says its fixes are "currently deferred to a future update" and gives no release date.
If you build your own kernel, the fix is present in Linux 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's CVE team recommends updating to the latest stable kernel and says the kernel community does not support cherry-picking individual fixes.
Why severity scores diverge: 9.8 from the kernel team versus lower vendor ratings
The kernel's CVE team added its 9.8 score to the CVE record on October 24. That score assumes an attacker who sends a TCP connection request carrying IPv4 Record Route or Timestamp options, then resends the request to try to win the race; the team rated attack complexity low, describing both sides of the race as "attacker-induced." Under that scenario, the team says the bug could leak nearby kernel memory, corrupt kernel memory, or crash the system.
Vendors have produced different assessments. As of October 28 the National Vulnerability Database had not yet added its own score and showed the kernel team's 9.8; Ubuntu's page also shows 9.8. Red Hat's human-readable CVE page rated the flaw Moderate, scoring it 5.9 because the race is hard to win and the most likely result is a kernel crash, with memory corruption possible "in theory" and "no confidentiality or integrity impact has been demonstrated." Separately, Red Hat's machine-readable advisory file (updated October 29) lists the impact as Important and scores the flaw 8.1; Red Hat's bug tracker changed the issue severity from medium to high on the same day.
Oracle and SUSE score the flaw 8.1, matching the kernel team's metrics except for attack complexity, which the vendors rate high. Amazon's score is 7.0. Those variations turn on whether vendors view the race as practical for attackers to induce and on differing judgments about confidentiality and integrity impact.
Practical steps and the current operational picture
Where a distribution has released a fixed kernel, install it. Where you build your own kernel, use one of the fixed upstream versions listed above or update to the latest stable kernel as recommended by the kernel CVE team. Red Hat has said no available mitigation meets its standards for being easy to deploy, suitable for most installations and stable; none of the other advisories lists a mitigant that vendors endorse.
As of October 29, none of the vendor advisories, the CVE record, or Anthropic's post reports active exploitation in the wild. The flaw does not appear in a copy of CISA's Known Exploited Vulnerabilities catalog that Luxembourg's CIRCL last updated on October 28.
The record is clear on one point: upstream applied a fix, and distributions have moved at different speeds to deliver it. Whether systems without MPTCP listeners are practically exploitable the same way, and whether simple configuration changes (for example, disabling MPTCP or blocking IP options) materially lower risk, remain points the published advisories and Anthropic's post do not settle. Administrators must therefore balance patch availability for their kernels against the differing vendor risk assessments until all affected distributions ship updated packages.




