Critical Remote Code Execution Vulnerability in the Linux Kernel TCP Stack (CVE-2026-98432)

Executive Summary

On October 15th, 2026, the Linux kernel CVE team published a critical vulnerability in the kernel's IPv4 TCP connection handling. Tracked as CVE-2026-98432, the flaw is a use-after-free that an unauthenticated, remote attacker can trigger during a TCP handshake to leak or corrupt kernel memory. On October 27th, 2026, Anthropic's Frontier Red Team disclosed a working exploit that turns the flaw into remote command execution as root on servers with a Multipath TCP (MPTCP) listener. The exploit requires no credentials and no user interaction.

The Linux kernel underpins most server, cloud, and appliance infrastructure. The vulnerable code has been present since Linux 4.4, so nearly every maintained distribution kernel is affected. The upstream fix has been backported to all maintained stable kernel branches, but distribution packages have not been universally patched as of publication. Debian, Oracle Linux, and some SUSE and Amazon Linux kernels are fixed. Ubuntu and Red Hat Enterprise Linux had not released fixed kernels at the time of writing. Vendors also present differences on severity.

Active exploitation has not been reported at the time of writing, and the demonstrated exploit has not been published. A third-party research group has, however, released a root cause analysis and a lab reproduction environment. Remote kernel memory corruption flaws have historically drawn rapid attacker interest after disclosure. Beazley Security recommends affected organizations apply fixed distribution kernels as soon as they are available and apply the interim mitigations below on systems that cannot yet be patched.

Affected Systems or Products

The flaw was introduced in Linux 4.4. Upstream fixes are available in the following stable releases:

Distribution status as of October 29th, 2026:

Mitigations / Workarounds

It's advisable that organizations running a linux distribution with a released update should install a fixed distribution kernel and reboot. A kernel update takes effect only once the new kernel is running, and uname -r confirms the active version. Organizations that build their own kernels should move to the latest stable release in their branch. The kernel CVE team does not support cherry-picking individual fixes.

Where no fixed kernel is available yet or updates are not immediately viable the following steps reduce exposure:

Disable MPTCP system-wide with sysctl -w net.mptcp.enabled=0, and persist the setting in a file under /etc/sysctl.d/. Applications that depend on MPTCP lose that capability, and running Go programs may see errors on new connections until restarted.

For Go services, set GODEBUG=multipathtcp=0 in the service environment, or add godebug multipathtcp=0 to the main module's go.mod. Go 1.24 and later enable MPTCP on listening sockets by default, so Go-based network services can expose an MPTCP listener without any explicit configuration.

Confirm net.ipv4.tcp_migrate_req remains at its default of 0 and that no BPF reuseport migration program is in use. Request socket migration provides a second path to the same flaw.

Treat these mitigations as risk reduction rather than remediation, and prioritize updating to releases as they are published. The demonstrated exploit targets MPTCP listeners, but the Go security team notes the underlying bug is not specific to MPTCP.

Red Hat states that no available mitigation meets its standards for ease of deployment and stability.

Patches

The upstream fix is available in all maintained stable kernel branches. Most organizations receive it through their distribution's kernel package. Debian, Oracle Linux, and some SUSE and Amazon Linux kernels have released fixes.

Ubuntu and Red Hat have not yet announced release dates, and administrators should track the distribution security trackers listed in Sources.

Technical Details

The vulnerability sits in the code that completes an IPv4 TCP handshake. When the kernel creates a socket for an accepted connection, it hands over IP options stored with the pending request instead of copying them. The kernel processes these pending requests without holding the listener lock. A second CPU answering a retransmitted SYN can therefore still be reading those options if the socket is being destroyed and its memory freed. This time difference can be levered if an attacker drives both sides of the race by sending multiple connection requests that carry IPv4 Record Route or Timestamp options and then resending them. Request socket migration opens a second path to the same condition.

IPv6 is not affected by the main race because it copies the options rather than storing them within the request.

Anthropic researcher Xinyang Ge reported the flaw, and Eric Dumazet authored the fix, which defers freeing the options until concurrent readers finish. Anthropic's exploit works in two stages. It first "wins" the race repeatedly until the kernel returns extra kernel memory in its replies. This memory can leak a pointer that allows an attacker to reveal memory that the kernel address space layout randomization (KASLR) is intended to obfuscate. Then continuing to target the same memory leak to overwrite a callback pointer and run an attacker commands as root.

A" lost" race fails only that connection attempt, and does not necessarily crash the host or cause a panic, so an attacker can retry indefinitely on specific configurations with specific requests. In Anthropic's test, the memory leak took about 48 minutes, and code execution took about five more minutes. Anthropic has not published the exploit code nor the tested configuration, and has not stated whether hosts without an MPTCP listener can be compromised the same way.

How Beazley Security is responding

Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.

Sources

• 

  https://nvd.nist.gov/vuln/detail/CVE-2026-98432

• 

  https://security-tracker.debian.org/tracker/CVE-2026-98432

• 

  https://access.redhat.com/security/cve/cve-2026-98432

• 

  https://bugzilla.redhat.com/show_bug.cgi?id=2553390

• 

  https://www.suse.com/security/cve/CVE-2026-98432.html

• 

  https://ubuntu.com/security/cve-2026-98432

• 

  https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-98432

• 

  https://seclists.org/oss-sec/2026/q4/437

• 

  https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html

• 

  https://www.anthropic.com/research/discovering-vulnerabilities-with-claude