A critical vulnerability in the Linux kernel could allow unauthenticated remote attackers to execute commands with root privileges on servers running Multipath TCP, or MPTCP, listeners. The flaw is tracked as CVE-2026-98432 and has received a severity score of 9.8 out of 10 from the Linux kernel CVE team. Researchers at Anthropic have demonstrated that the vulnerability can be turned into remote code execution under specific conditions, significantly raising the stakes beyond the denial-of-service impact initially associated with the bug.
The vulnerability also affects ordinary TCP connections, although researchers have not publicly demonstrated remote code execution against servers without an active MPTCP listener. Linux systems dating back to kernel version 4.4 are potentially affected, including deployments based on Ubuntu, Red Hat Enterprise Linux, Rocky Linux and several other widely used distributions.
What Is Multipath TCP?
Multipath TCP extends traditional TCP by allowing a single connection to use several network paths simultaneously. A device with both Wi-Fi and cellular connectivity, for example, can potentially use both paths as part of the same connection, improving resilience and performance when one connection becomes unreliable.
MPTCP is particularly useful on devices or servers where maintaining connectivity is important despite changes in network conditions. Although it is not necessarily enabled by every application, some software can activate it automatically when the underlying Linux kernel supports the feature.
That automatic behaviour becomes especially important in the context of CVE-2026-98432 because administrators may not always realise that an application is creating MPTCP-enabled TCP listeners.
CVE-2026-98432 Is A Use-After-Free Vulnerability
The underlying flaw is a use-after-free vulnerability in the Linux kernel's IPv4 TCP networking implementation. Use-after-free bugs occur when software continues using memory after that memory has already been released, creating an opportunity for corruption, crashes and potentially arbitrary code execution.
In this case, the problem is associated with a race condition involving TCP connection requests. Two CPU cores can process related networking activity at almost the same time, causing one part of the kernel to access information that another part has already transferred or released.
The timing requirements make exploitation more complicated than simply sending one malformed packet, but Anthropic's research shows that the race can nevertheless be exploited under the right circumstances.
The Race Condition Occurs During TCP Connection Handling
The Linux kernel advisory explains that ownership of certain connection-request information can be transferred to a newly created child socket without first creating a separate copy. At the same time, another CPU may process a retransmitted SYN packet belonging to the same request.
This can lead different parts of the networking stack to access the same option data while its ownership is changing. Several kernel functions can then read information from memory that is no longer valid.
Race-condition vulnerabilities can be particularly difficult to reproduce consistently because exploitation depends on precise timing between competing operations. That complexity is one reason different vendors have assessed the practical severity differently.
TCP Request Migration Can Trigger A Similar Problem
The same underlying vulnerability can also occur when Linux migrates TCP request sockets between listeners. This behaviour may be present when net.ipv4.tcp_migrate_req is enabled or when applications use a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program.
That means the flaw is not limited exclusively to one narrow MPTCP configuration. MPTCP currently provides the strongest publicly demonstrated path towards remote code execution, but the vulnerable TCP processing logic exists more broadly.
Administrators therefore should not assume they are completely safe simply because they have disabled MPTCP.
Linux Kernel CVE Team Rates The Flaw Critical
The Linux kernel CVE team has assigned CVE-2026-98432 a score of 9.8, placing it in the critical category. The high rating reflects the potential for unauthenticated remote exploitation with serious consequences.
An attacker does not need an existing user account or valid credentials before attempting to trigger the vulnerability. Network reachability to a vulnerable service can potentially be enough to begin the attack.
A remotely reachable kernel vulnerability is especially serious because compromising the kernel can give an attacker the highest level of control available on the operating system.
Red Hat Gives It A Lower Severity Rating
Red Hat has taken a more conservative view of the vulnerability and currently classifies it primarily as a potential denial-of-service issue. The company has assigned a score of 5.9, reflecting the complexity involved in reliably triggering the race condition.
From Red Hat's perspective, the most obvious practical outcome is a kernel crash caused by memory corruption. An attacker could potentially use repeated exploitation attempts to disrupt the availability of an affected server.
Anthropic's work, however, demonstrates that the bug can be pushed considerably further under certain configurations.
Anthropic Researchers Achieved Remote Root Code Execution
Anthropic researchers developed an exploit capable of turning CVE-2026-98432 into remote code execution against a Linux server running an MPTCP listener. The exploit reportedly allowed arbitrary commands to execute with root privileges, effectively giving the attacker complete control of the target machine.
This changes the security conversation considerably. A denial-of-service vulnerability is serious because it can knock systems offline, but a root-level remote code execution vulnerability can potentially expose data, install malware, establish persistence and use the compromised server as a starting point for further attacks.
The demonstration therefore helps explain why the Linux kernel CVE team considers the vulnerability critical.
An Unreleased Claude Model Developed The Exploit
One particularly interesting aspect of the research is that Anthropic says an unreleased Claude AI model developed the working exploit. The model reportedly produced an attack capable of overcoming several protections and eventually gaining root-level command execution on the vulnerable Linux server.
The result demonstrates how increasingly capable AI systems can assist with sophisticated vulnerability research. Developing a reliable kernel exploit usually requires substantial knowledge of memory corruption, operating-system internals and exploitation mitigations.
AI models being able to perform more of that work could accelerate both defensive vulnerability research and the speed at which serious flaws become weaponised.
The Exploit Bypassed KASLR
The exploit reportedly bypassed Kernel Address Space Layout Randomization, commonly known as KASLR. KASLR is designed to make exploitation harder by randomising where important kernel structures and code are placed in memory.
Attackers normally need to know or infer those locations before reliably redirecting execution. Bypassing KASLR therefore represents an important step in transforming a memory corruption vulnerability into practical remote code execution.
The fact that the exploit could overcome this protection demonstrates that CVE-2026-98432 is more than a theoretical kernel crash.
Remote Root Access Was Achieved In About 53 Minutes
According to Anthropic, the AI-assisted exploitation process achieved remote root code execution in approximately 53 minutes. That does not mean every attacker can compromise any vulnerable server within the same amount of time, because exploitation depends heavily on configuration, environment and reliability.
However, the result demonstrates that the vulnerability can be developed into a serious exploit without requiring an impossibly long research process. Once one working exploitation technique is understood, future attackers may also be able to reproduce or improve it.
That makes patching particularly important before detailed exploitation techniques become more widely available.
MPTCP May Be Enabled Without Administrators Realising It
Multipath TCP is not necessarily something administrators deliberately configure on every Linux service. However, some applications and development frameworks can enable it automatically when the operating system supports it.
This creates the possibility that a server may expose an MPTCP listener even though the system administrator never intentionally deployed an MPTCP service. Application behaviour therefore matters just as much as the kernel configuration itself.
Auditing exposed services is important for determining whether a system matches the conditions Anthropic used to achieve remote code execution.
Go 1.24 Enables MPTCP By Default For Linux TCP Listeners
One particularly important example involves the Go programming language. Beginning with Go 1.24, MPTCP is enabled by default for TCP listeners on Linux when the kernel supports the technology.
As a result, network applications written in recent versions of Go could potentially create MPTCP listeners without their administrators explicitly configuring Multipath TCP. That could make some Go-based services more exposed to the exploitation scenario demonstrated by Anthropic.
Organisations running Go network services should therefore check both their Go versions and the behaviour of their listening sockets rather than assuming MPTCP is disabled.
Ubuntu Systems Remain Affected While Fixes Are Prepared
The upstream Linux kernel vulnerability has already been fixed, and patches have been backported to maintained kernel branches. Distribution availability, however, varies because individual Linux vendors need to package, test and release their own kernel updates.
As of 30 October, Canonical's security information indicated that Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 remained affected while fixes were still being prepared.
Ubuntu administrators should monitor the distribution's security updates and install the corrected kernel as soon as it becomes available for their specific release.
RHEL 8, 9 And 10 Are Affected
Red Hat lists RHEL 8, RHEL 9 and RHEL 10 as affected by CVE-2026-98432. Corrected kernels are expected through future updates.
Interestingly, RHEL 7 is not affected because its older kernel does not contain the vulnerable code path. This is one of those unusual cases where an older release avoids a particular vulnerability simply because the affected functionality was introduced later.
That does not mean RHEL 7 is generally more secure, only that this specific vulnerability does not apply.
Rocky Linux 8, 9 And 10 Are Also Vulnerable
Rocky Linux deployments based on versions 8, 9 and 10 are also affected. CIQ, which provides support and services around Rocky Linux, has published mitigation advice for organisations that cannot immediately install a patched kernel.
The temporary guidance focuses on reducing exposure before vulnerable TCP traffic reaches the affected kernel code. These mitigations can be useful for internet-facing systems while administrators wait for official kernel packages.
They should still be treated as temporary protections rather than substitutes for applying the permanent fix.
Debian Has Already Released Corrected Kernels
Debian has moved more quickly for supported releases. According to its security tracking information, Debian 12 Bookworm received the fix in kernel package 6.1.190-1, while Debian 13 Trixie received the correction in 6.12.113-1.
Corrected packages are also available for Debian's testing and unstable branches. Administrators using Debian should check the installed kernel package and reboot after applying the update so the machine actually begins running the fixed kernel.
Installing a new kernel without restarting leaves the vulnerable kernel active until the next boot.
Oracle Linux, Amazon Linux And SUSE Are Also Releasing Fixes
Other major Linux vendors have also started distributing corrections for affected kernel versions. These include Oracle Linux, Amazon Linux and SUSE.
Availability may differ between releases and kernel streams, so administrators should not assume that installing routine package updates automatically means the fix is already present. Checking each vendor's advisory and confirming the active kernel version remains the safest approach.
Large organisations with mixed Linux environments may need to track several different patch schedules simultaneously.
macOS Is Not Affected
The vulnerability does not affect macOS because Apple's operating system does not use the Linux kernel. macOS is built on Apple's XNU kernel, which has a completely different networking implementation.
The flaw is specifically associated with Linux TCP processing, so Apple computers are outside the affected scope.
Similarly, the vulnerability should not be interpreted as a generic TCP protocol flaw affecting every operating system. It is an implementation bug within the Linux kernel.
Administrators Should Patch As Soon As Updates Become Available
The most effective solution is installing the fixed kernel provided by the relevant Linux distribution. Kernel security updates normally require a reboot before the corrected code becomes active.
For critical internet-facing servers, administrators should consider scheduling emergency maintenance rather than waiting for the next routine patch window. This becomes especially important when MPTCP listeners are present or when Go-based services could have enabled them automatically.
The existence of a demonstrated root-level exploit significantly increases the potential consequences of delaying remediation.
Restricting Network Access Can Reduce Immediate Risk
Where patches are not yet available, one temporary defence is limiting access to vulnerable services. Firewalls can restrict connections so that only trusted networks or approved IP addresses can reach the server.
This does not remove the underlying bug, but it reduces the number of potential attackers capable of attempting exploitation. Internal services that do not genuinely need public exposure should not remain reachable from the internet.
Network restrictions are especially useful while waiting for a distribution vendor to publish updated kernel packages.
CIQ Recommends Blocking Certain IPv4 TCP Traffic
CIQ has also recommended temporarily blocking IPv4 TCP packets containing IP options before the packets reach the vulnerable TCP processing path. The organisation has provided examples using nftables that administrators can adapt for affected environments.
This mitigation targets traffic involved in triggering the vulnerable behaviour rather than simply blocking MPTCP itself. However, filtering IP options may affect legitimate network functionality depending on how the environment is configured.
Any mitigation should therefore be tested carefully before being applied widely across production infrastructure.
Disabling MPTCP Alone Is Not Enough
One of the most important details is that simply turning off Multipath TCP does not fully resolve the problem. The underlying vulnerability exists within ordinary Linux TCP processing as well.
Anthropic's public remote-code-execution demonstration currently focuses on an MPTCP listener, but the vulnerable code can still be reached through regular TCP under certain circumstances. Administrators should therefore avoid treating MPTCP disablement as a complete security fix.
Applying the patched kernel remains the correct long-term remediation.
Ordinary TCP Servers Still Need Attention
The absence of a public remote-root exploit for ordinary TCP should not be interpreted as proof that such exploitation is impossible. It simply means the publicly described successful attack used an MPTCP configuration.
Security research often progresses after a vulnerability becomes widely known. Techniques originally requiring one configuration can sometimes be adapted to broader targets later.
Any server running an affected Linux kernel should therefore be considered for patching, regardless of whether MPTCP is intentionally used.
Kernel Vulnerabilities Carry Particularly High Risk
Application vulnerabilities generally compromise one service or account. Kernel vulnerabilities can potentially compromise the entire operating system.
The Linux kernel controls memory, networking, processes and hardware access. Gaining arbitrary kernel-level execution effectively allows an attacker to bypass normal user permissions and security boundaries.
That is why remote kernel vulnerabilities capable of root access receive such high severity ratings.
Use-After-Free Bugs Can Be Extremely Powerful
Use-after-free vulnerabilities are especially valuable to attackers because they can sometimes manipulate released memory before the vulnerable code accesses it again.
If the attacker can control what replaces the original object, the program may begin interpreting malicious data as legitimate kernel structures.
Turning that primitive into code execution can be complex, especially in modern kernels containing protections such as KASLR. Anthropic's demonstration shows that those protections do not make exploitation impossible.
The exact techniques used remain important to understanding how broadly the attack can eventually be applied.
Race Conditions Make Exploitation Harder But Not Safe
Red Hat's lower rating reflects the fact that race conditions can be difficult to exploit consistently. Triggering two operations in exactly the required order often takes repeated attempts and careful timing.
However, difficulty should not be confused with safety. Automated attackers can repeat exploitation attempts thousands of times if necessary, particularly against internet-facing systems.
Once researchers develop reliable timing strategies, a vulnerability that initially appears impractical can become considerably easier to weaponise.
AI-Assisted Exploit Development Changes The Timeline
Anthropic's experiment also raises a broader cybersecurity concern beyond CVE-2026-98432 itself. If increasingly capable AI models can develop complex kernel exploits in less than an hour, the period between vulnerability disclosure and practical exploitation could shrink considerably.
Traditionally, difficult kernel vulnerabilities might require highly specialised researchers to spend days or weeks developing reliable exploit chains. AI could help automate portions of that process.
Defenders may therefore have less time to patch serious vulnerabilities before working exploit techniques become available.
The Same Technology Can Help Defenders
The development is not exclusively negative. AI models can also assist defensive researchers in analysing kernel patches, reproducing vulnerabilities and testing whether fixes are effective.
Linux vendors and security teams could use similar capabilities to identify exploitable conditions before attackers do. Automated exploit development could even become part of vulnerability prioritisation, helping organisations distinguish bugs that are theoretically dangerous from those that are practically weaponisable.
The challenge is that attackers potentially gain access to similar capabilities as the technology becomes more widely available.
Internet-Facing Linux Servers Deserve Priority
Organisations should prioritise machines that expose TCP services directly to the internet. Web infrastructure, APIs, VPN gateways, proxies and application servers may all fall into this category.
Systems running recent Go-based applications deserve additional attention because of the possibility of automatically enabled MPTCP listeners.
Internal machines should still be patched, but public services provide attackers with a much easier path to interact with the vulnerable networking code.
Risk-based prioritisation can help organisations protect the most exposed systems while distribution updates are still arriving.
Check The Running Kernel, Not Just Installed Packages
Administrators should remember that updating a kernel package does not automatically mean the running system is protected.
Linux normally continues using the kernel loaded at boot until the machine restarts. Package managers can therefore show a patched kernel as installed while the server remains actively running the vulnerable version.
Commands such as uname -r can help administrators confirm which kernel is actually running after maintenance.
A reboot is generally necessary unless the environment uses a supported live-kernel-patching mechanism covering this vulnerability.
Production Environments Should Inventory MPTCP Use
Organisations should also determine whether MPTCP is present anywhere in their infrastructure rather than assuming it is not used.
Checking listening sockets, application frameworks and kernel configuration can reveal services using the feature unexpectedly.
Development teams should be asked whether recent Go services or other frameworks automatically enable Multipath TCP.
The most dangerous exposure can sometimes come from functionality administrators did not realise had been activated.
Temporary Firewall Rules Need Careful Testing
Emergency firewall mitigations are useful but can introduce operational problems if applied without testing.
Blocking all TCP packets containing IP options may interfere with specialised networking environments that legitimately depend on those fields. Production networks should therefore evaluate the impact before enforcing broad filters.
A targeted restriction applied only to vulnerable public services may be safer than a blanket policy across every system.
Once the corrected kernel is installed, temporary controls can be reviewed or removed according to operational requirements.
There Are No Confirmed Attacks In The Wild Yet
Despite the seriousness of the vulnerability and Anthropic's successful exploit, there are currently no confirmed reports of CVE-2026-98432 being exploited in real-world attacks.
That gives administrators an important opportunity to patch before widespread exploitation begins.
However, the existence of a working research exploit means defenders should not become complacent. The technical feasibility of remote root compromise has already been demonstrated under at least one realistic configuration.
The safest assumption is that attackers will eventually investigate the same path.
Final Thoughts
CVE-2026-98432 is one of the more serious Linux kernel vulnerabilities disclosed recently because it combines unauthenticated network access with the demonstrated possibility of remote root code execution. The use-after-free flaw affects Linux kernels dating back to version 4.4 and sits inside the IPv4 TCP networking implementation, placing a very large number of servers potentially within scope.
Anthropic researchers demonstrated the most severe scenario against a server running an MPTCP listener, where an unreleased Claude model reportedly developed an exploit capable of bypassing KASLR and executing arbitrary commands as root in around 53 minutes. That considerably raises the impact beyond the denial-of-service behaviour some Linux vendors initially emphasised.
Administrators should also pay particular attention to Go-based services because Go 1.24 can enable MPTCP automatically for Linux TCP listeners when the kernel supports it. However, simply disabling MPTCP is not enough because the underlying vulnerability can still be triggered through ordinary TCP processing.
Linux vendors are already releasing patched kernels, although availability differs between distributions. Debian has published fixes, while affected Ubuntu, RHEL and Rocky Linux branches require administrators to follow their respective vendor advisories as updates become available.
Until systems are patched, reducing network exposure and applying appropriate firewall protections can lower immediate risk. The permanent solution, however, is to install a corrected kernel and ensure the server actually reboots into it.
There may be no confirmed exploitation in the wild today, but a working remote-root technique already exists in a research environment. For organisations running internet-facing Linux infrastructure, that makes CVE-2026-98432 a vulnerability worth addressing before attackers turn the demonstration into something much less experimental.
Comments 0