CVE-2026-98432: Critical Linux Kernel TCP Flaw Enables Remote Code Execution

A critical vulnerability in the Linux kernel’s IPv4 TCP networking stack could allow an unauthenticated remote attacker to trigger memory corruption, crash vulnerable systems, and potentially execute arbitrary code with root privileges. Tracked as CVE-2026-98432, the flaw carries a CVSS 3.1 score of 9.8 and has existed in the Linux kernel since version 4.4.

The vulnerability stems from a race condition that can cause the kernel to access IP option data after the underlying memory has already been freed. An attacker capable of reaching an exposed IPv4 TCP service can attempt to trigger the condition using specially timed connection requests containing IPv4 options. No authentication, local privileges, or user interaction are required.

Security interest increased significantly after Anthropic disclosed that an internal Claude research model had developed a working exploit capable of achieving remote root command execution against a Linux server with a Multipath TCP (MPTCP) listener. The exploit first leaks a kernel pointer to bypass KASLR and then uses the same use-after-free condition to corrupt memory and redirect kernel control flow. Anthropic has not released the exploit code.

Importantly, the underlying vulnerability is not limited to MPTCP. Red Hat confirms that systems with ordinary IPv4 TCP networking remain vulnerable even when MPTCP is disabled, including default Red Hat Enterprise Linux configurations.

Contact Sales

As of November 4, 2026, no Linux vendor, CERT, or other reviewed source has reported confirmed exploitation of the flaw in real-world attacks. Public research code demonstrating portions of the vulnerability exists, but a publicly released exploit providing the full remote-root capability demonstrated by Anthropic has not been documented.

Security teams can use SOC Prime’s AI-Native Detection Intelligence Platform to strengthen their defenses against emerging vulnerability exploitation, operationalize threat intelligence, and accelerate threat hunting across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-98432 by monitoring unusual IPv4 TCP traffic containing IP options, repeated connection attempts designed to trigger race conditions, kernel crashes or memory-corruption events, and suspicious activity that could indicate successful post-exploitation.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-98432 analysis

CVE-2026-98432 affects the IPv4 TCP connection-handling code in Linux kernels containing the vulnerable implementation introduced in Linux 4.4. The Linux kernel CVE team classifies the issue as critical with a CVSS 3.1 score of 9.8 and the vector AV/AC/PR/UI/S/C/I/A.

The vulnerability is a use-after-free condition caused by a race during concurrent TCP connection processing. When an IPv4 TCP connection is established, tcp_v4_syn_recv_sock() transfers IP options associated with the pending request to the newly created socket without making a separate copy.

Another CPU can simultaneously process a retransmitted SYN associated with the same request socket. During that process, functions responsible for generating the SYN-ACK continue reading the IP options while protected by an RCU read-side critical section.

However, the child socket can be destroyed while that operation is still underway. The kernel then frees the associated inet_opt structure using kfree(), leaving another CPU potentially accessing memory that has already been released. The resulting stale reference creates a use-after-free condition in ip_options_build().

A similar race exists during request socket migration, including configurations using net.ipv4.tcp_migrate_req=1 or BPF-based SK_REUSEPORT_SELECT_OR_MIGRATE. The upstream fix replaces the unsafe memory release with RCU-aware freeing, ensuring readers have finished accessing the object before its memory can be reclaimed.

The first issue specifically affects IPv4. The kernel advisory states that IPv6 is not vulnerable to that particular race because tcp_v6_syn_recv_sock() duplicates the relevant options instead of transferring them in the same manner.

Remote exploitation requires specially constructed network traffic and precise manipulation of the race condition. Red Hat notes that the likely outcomes can include a kernel crash, memory corruption, and potentially remote code execution. The lack of authentication and user interaction substantially increases the risk for systems exposing TCP services to untrusted networks.

Anthropic demonstrated that the vulnerability can be transformed into a full remote-root exploit. Its research model targeted a Linux server accepting Multipath TCP connections and used two stages to achieve command execution.

During the first stage, the exploit repeatedly triggers the race and manipulates a length value so the kernel returns additional adjacent memory in a network response. Eventually, one of these responses contains a kernel pointer. That disclosure reveals information about the kernel memory layout and allows the exploit to defeat Kernel Address Space Layout Randomization (KASLR).

During the second stage, the exploit uses the same vulnerability to cause a buffer overflow and overwrite a callback pointer. The pointer is redirected toward a payload previously placed in kernel memory using legitimate protocol functionality. When the kernel invokes the modified callback, existing kernel functions are chained together until an attacker-selected shell command is executed as root.

A particularly important characteristic of the exploit is that losing the race does not necessarily crash the server. Instead, the connection attempt can simply fail, allowing the attacker to retry repeatedly. In Anthropic’s test environment, obtaining a useful kernel pointer took approximately 48 minutes, followed by another five minutes to achieve root command execution.

This demonstration should not be interpreted to mean that MPTCP is required for exploitation. Anthropic demonstrated one successful exploit path involving an MPTCP listener, but the vulnerable code resides in ordinary IPv4 TCP handling. Red Hat explicitly warns that disabling MPTCP does not fully address the vulnerability and that default RHEL installations remain affected even though MPTCP is disabled by default.

The CVE-2026-98432 PoC situation is also important to distinguish from the existence of a complete weaponized exploit. Anthropic developed a functioning remote-root proof of concept internally but has not published it. Public code reported by security researchers can demonstrate or detect aspects of the underlying race and memory disclosure, but the reviewed sources do not document publicly released code reproducing Anthropic’s complete remote code execution chain.

The vulnerability was reported by Anthropic researcher Xinyang Ge. The upstream Linux fix was applied on October 5, 2026, while the Linux kernel CVE record was published on October 15. Anthropic publicly described its full exploitation research on October 27.

The Linux kernel project identifies the following upstream fixed versions:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

The kernel team recommends upgrading to the latest stable kernel rather than cherry-picking individual commits.

Distribution-specific exposure and remediation differ because Linux vendors maintain their own kernels and backport security fixes. Red Hat currently rates the issue Critical at 9.8 and has released fixes for multiple RHEL 8, 9, and 10 streams. OpenShift and layered products that depend on affected RHEL kernels also require attention.

Ubuntu likewise rates the vulnerability Critical at 9.8. Ubuntu 26.10 has received a fixed generic kernel, while fixes for Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS were available in the -proposed testing pocket as of early November, with additional supported releases awaiting fixes. Administrators should use Canonical’s CVE page rather than relying solely on upstream kernel version numbers.

For CVE-2026-98432 detection, security teams should combine network and host telemetry. Potential network-level hunting signals include unusual inbound IPv4 TCP packets carrying IP options, especially repeated connection attempts containing Record Route or Timestamp options and abnormal patterns of SYN retransmission. The presence of such traffic alone does not confirm exploitation, but it provides a useful hunting pivot when correlated with vulnerable systems.

Host-level monitoring should include Linux kernel crashes, kernel warnings, memory-corruption indicators, unexpected service restarts, and anomalous activity immediately following suspicious network traffic. Because successful exploitation could theoretically provide root code execution, defenders should also monitor for unexpected privileged processes, newly created files, configuration changes, persistence mechanisms, and unexplained outbound connections.

There are currently no attacker-specific CVE-2026-98432 IOCs such as confirmed malicious IP addresses, domains, or malware hashes because the reviewed sources have not reported real-world exploitation. Defenders should therefore prioritize behavior-based detection and exposure assessment rather than relying on static indicators.

CVE-2026-98432 Mitigation

The definitive remediation is to install a vendor-provided kernel containing the security fix. The Linux kernel CVE team recommends moving to the latest supported stable kernel, while Linux distribution users should install packages supplied specifically by their vendor because fixes are commonly backported without changing to an upstream kernel version.

Administrators should prioritize internet-facing Linux servers and other systems accepting inbound IPv4 TCP connections. The attack surface is broad because the vulnerability exists in the kernel networking stack rather than in an individual application or server product.

Organizations should take the following steps:

1. Inventory Linux servers and identify the running kernel with tools such as uname -r.
2. Check the relevant Linux distribution’s security advisory rather than determining exposure solely from the upstream version number.
3. Install the vendor-provided fixed kernel as soon as it becomes available.
4. Reboot affected systems after installing the updated kernel to ensure the patched kernel is running.
5. Prioritize internet-facing servers and infrastructure accepting inbound IPv4 TCP traffic.
6. Review externally exposed TCP services and limit unnecessary network accessibility.
7. Continue monitoring vendor advisories because fix availability differs across Linux distributions, kernel variants, cloud kernels, and support channels.

Red Hat and Ubuntu have also documented an interim packet-filtering approach that drops incoming IPv4 TCP packets containing IP options. The recommended nftables condition checks for an IPv4 header length greater than five and drops matching TCP packets before they reach the vulnerable socket-handling path.

This measure can reduce exposure because the known exploitation path requires IPv4 options. However, both vendors warn that packet filtering is not a complete replacement for installing the corrected kernel. It can also interfere with workloads that legitimately depend on IPv4 options and therefore should be tested before production deployment.

Disabling MPTCP alone should not be treated as sufficient protection. Although Anthropic’s working exploit targeted an MPTCP listener, the underlying vulnerability is in normal IPv4 TCP handling. Red Hat specifically notes that RHEL remains vulnerable in its default configuration even though MPTCP is disabled.

For environments using Go applications, disabling automatic MPTCP behavior can reduce exposure to the specific exploit demonstrated by Anthropic, but this remains an incomplete risk-reduction measure. Systems without an MPTCP listener should not automatically be considered safe because other exploitation techniques may target the same underlying race.

Because no real-world compromise campaign has been confirmed, incident-response guidance should currently focus on identifying potentially vulnerable systems and suspicious exploitation behavior rather than searching for a known attacker infrastructure set. Organizations that observe unusual TCP traffic followed by kernel instability or unexpected privileged execution should treat the activity as potentially malicious and preserve network and host telemetry for investigation.