A critical vulnerability in the Linux kernel has prompted warnings after Anthropic demonstrated an attack that allows an unauthenticated remote adversary to execute commands with root privileges on servers exposing a Multipath TCP listener.
Tracked asCVE-2026-98432, the flaw affects memory handling in the kernel’s IPv4 TCP implementation. Ubuntu’s advisory lists a CVSS score of9.8, placing it in the critical category, and assigns it a high remediation priority. Because the vulnerability sits in the operating system’s networking code, assessing exposure requires examining the running kernel and network configuration, rather than simply checking application versions.
The central concern extends beyond the specific configuration used in the demonstration. TheGo security team’s advisorywarns that although the published exploit description requires an MPTCP listener, the underlying vulnerability is not specific to MPTCP. Systems without such listeners could potentially be vulnerable to other exploitation methods.
How the Flaw Occurs During TCP Connection Handling
TheLinux kernel security announcementdescribes a race condition involving IPv4 options used while establishing TCP connections.
When the kernel creates a new connection socket, it transfers ownership of those options from the pending connection request to the new socket. At the same time, another processor can be handling a retransmitted connection request and reading the same options while preparing a response.
If the newly created socket is destroyed before that parallel operation finishes, the options can be freed while they remain in use. The result is ause-after-free vulnerability: kernel code continues accessing memory after its lifetime has ended.
The fix changes how the affected memory is released. It uses a read-copy-update, or RCU, grace period so that existing readers have time to finish before the memory is reclaimed. The announcement traces the issue to a change introduced in Linux 4.4.
The vulnerability record also identifies a related race during request-socket migration. This reinforces why exposure cannot safely be assessed solely by asking whether an administrator deliberately enabled multipath networking.
Anthropic Demonstrates Root-Level Command Execution
In itsresearch disclosure, published on 27 October, Anthropic said an unreleased internal Claude research model produced an exploit after initial prompting.
The demonstration first disclosed kernel memory information to defeat Kernel Address Space Layout Randomization, or KASLR. It then used the vulnerability to redirect kernel execution and run an attacker-selected shell command as root.
Anthropic reported that its proof of concept took approximately48 minutes to obtain a kernel pointer and a further five minutes to reach command execution. These figures describe the exploit’s execution in its test environment; they are not a measurement of how long the model took to discover the vulnerability or develop the exploit.
The company also said unsuccessful attempts at the race could fail the handshake without crashing the system, allowing repeated attempts. Those results establish demonstrated exploitability under the tested conditions, rather than a guarantee that every affected server can be compromised in the same way or within the same time.
Why Go Applications Deserve Particular Attention
MPTCP allows a connection to use multiple network paths. Its relevance here is that the demonstrated attack targets a server with an MPTCP listening socket.
Administrators should not assume those sockets exist only on systems explicitly configured for specialist networking. TheGo 1.24 release notesstate that ListenConfig uses MPTCP by default where supported, which at the time of that change meant Linux.
Consequently, reviewing Go-based services is a sensible part of exposure assessment. A service may use MPTCP because of its runtime’s networking defaults, even when its operators have never deliberately deployed multipath networking. Actual behaviour still depends on the application, operating-system support and configuration.
Go provides a GODEBUG=multipathtcp=0 setting that disables MPTCP by default for diallers and listeners. However, application code can explicitly override the default through the networking API. A configuration change therefore needs verification against the service’s actual behaviour.
More fundamentally, the Go security team describes disabling MPTCP program by program as fragile: one overlooked listener could preserve exposure, and the approach assumes every viable exploit depends on MPTCP. Its recommended fix is a patched kernel.
Patch Availability Differs Across Linux Distributions
Upstream remediation and distribution-level availability must be treated separately. Organisations should check the advisory for their exact kernel package and release channel, including cloud-specific and extended-support variants.
As checked on30 October 2026, the available vendor information showed differing levels of remediation.
Debian
TheDebian security trackerlists fixes in the security repositories for:
- Debian 12 “bookworm”:linux version 6.1.190-1.
- Debian 13 “trixie”:linux version 6.12.113-1.
- Bookworm’s linux-6.12 package:6.12.113-1~deb12u1.
The tracker distinguishes vulnerable packages in the main release from corrected packages in the security repository. Administrators should verify that the appropriate security update has actually been deployed.
Ubuntu
TheUbuntu advisory, updated on 30 October, continued to mark the main linux packages for Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 as vulnerable, with fixes in progress.
A version appearing alongside “work in progress” should not be interpreted as a released security update. Ubuntu maintains separate entries for numerous kernel variants, so the status of one package cannot be applied automatically to every Ubuntu installation.
Amazon Linux
TheAmazon Linux advisorylists Amazon Linux 2023’s kernel6.12 and kernel6.18 packages as fixed, with advisory release dates of 29 October and 24 October respectively.
Other listed streams, including Amazon Linux 2 variants and Amazon Linux 2023’s kernel package, remained marked as pending a fix. This is a practical example of why identifying the operating-system family alone is insufficient: different kernel streams within the same distribution can have different remediation states.
Red Hat
The currentRed Hat CVE pagerates the vulnerability asCriticalfor Red Hat Enterprise Linux. It highlights unauthenticated access to the affected processing paths over standard IPv4 TCP traffic and the potential for kernel memory corruption or a system crash.
Red Hat directs customers tosecurity bulletin RHSB-2026-016for mitigation procedures. Customers should use the current bulletin and product-specific errata when planning their response, rather than relying on older summaries of the vendor’s assessment.
Demonstrated Exploitation Is Different From Confirmed Attacks
The primary disclosures reviewed establish a working research demonstration. They do not establish an active criminal campaign exploiting this vulnerability.
That distinction matters when communicating risk. A successful proof of concept supports urgent remediation, but claims of widespread compromise, ransomware deployment or exploitation by a named threat actor require separate evidence.
There is also no basis in these disclosures for assigning a universal compromise time. Hardware, kernel builds, network conditions and system configuration can affect whether a particular exploitation technique succeeds.
Defenders should therefore prioritise the verified facts: a remotely reachable kernel memory-safety flaw, demonstrated root-level impact in an MPTCP configuration, and incomplete patch availability across some distribution streams.
What Security Teams Should Do Now
Administrators should identify affected Linux systems, prioritising internet-facing and critical servers, applying vendor updates and verifying that the corrected kernel is running.
For enterprise teams, that translates into a coordinated response across vulnerability management, infrastructure operations and service owners:
- Establish exposure:Identify running kernels, relevant vendor packages and reachable TCP services.
- Prioritise remediation:Address exposed and business-critical systems first, with particular attention to MPTCP listeners.
- Activate the fix:Follow vendor instructions, including rebooting where required, and confirm that the updated kernel is active.
- Reduce unnecessary access:Restrict reachable services through firewall rules and access controls while awaiting patches.
- Investigate suspicious behaviour:Review unexpected kernel crashes, unusual network activity and unauthorised privileged commands.
These monitoring signals are investigative leads, not definitive indicators of this specific exploit. Likewise, network restrictions reduce exposure but do not repair the underlying memory-handling flaw.
A Reminder to Verify Remediation at the Kernel Layer
CVE-2026-98432presents a challenge that application-focused patching programmes can miss: the vulnerable component is the kernel processing incoming connections.
The operational priority is to establish which systems have received a vendor-supported fix and which are actually running it. Distribution backports also mean that a kernel’s apparent upstream version is not, by itself, reliable proof of vulnerability or remediation; package-specific vendor guidance remains essential.
For systems awaiting updates, exposure reduction should be tracked as a temporary measure with a named owner and a follow-up patching action. The Go security team’s warning captures the key limitation: removing the demonstrated MPTCP attack path does not establish that the underlying TCP vulnerability is no longer exploitable
