Back

04/11/2026

CVE-2026-98432: Linux TCP Use-After-Free, AI-Assisted Remote Root via MPTCP, and Enterprise Linux Defenses

A race in Linux IPv4 TCP handling, a demonstrated MPTCP remote root, and the vendor fixes and mitigations for RHEL, Ubuntu, Oracle Linux and Debian.

Information verified: November 3, 2026 | LOGIQ Technical Analysis

In October 2026, a use-after-free (UAF) vulnerability, CVE-2026-98432, was disclosed in Linux kernel IPv4 TCP connection handling. The Linux kernel CVE team issued its notice on October 15. On October 27, Anthropic reported that an unreleased internal research model demonstrated unauthenticated remote command execution with root privileges against a Linux server with an MPTCP (Multipath TCP) listener. Crucially, the specific exploit conditions should not be conflated with the broader vulnerability and denial-of-service risks affecting ordinary IPv4 TCP services.

Key takeaways

  • The flaw is a race in ordinary IPv4 TCP connection-request handling, present since Linux 4.4. MPTCP is not required for the bug itself.
  • Anthropic’s remote-root demonstration targeted a server with an MPTCP listener; other TCP services still face crashes, denial of service and memory corruption.
  • Red Hat rates the issue Critical (CVSS v3.1 9.8) and released fixed kernels for RHEL 8, 9 and 10 on November 1. Ubuntu fixes were still in progress on November 3.
  • Install a vendor-approved fixed kernel, reboot, and confirm the running kernel. Mitigations reduce exposure but do not replace the patch.

Where the race occurs

The issue involves the IPv4 TCP three-way handshake. IP options held by a request socket (ireq->ireq_opt) can be transferred into the child socket’s inet_opt during tcp_v4_syn_recv_sock() without being copied. If another CPU is processing a retransmitted SYN and constructing a SYN/ACK while the child socket is destroyed, the option memory can be released while still in use. Subsequent access by functions such as ip_options_build() can trigger a UAF.

A related race exists in request-socket migration via net.ipv4.tcp_migrate_req=1 or BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, where option data can be shared between the original and cloned request sockets. The vulnerable behavior dates to Linux 4.4, but actual exposure must be assessed per vendor kernel, including backports.

Upstream fix commit e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) changes immediate deallocation in inet_sock_destruct() and tcp_v4_reqsk_destructor() to RCU-deferred deallocation through kfree_rcu(). The Linux CVE notice identifies fixes in kernel versions 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. The initial IPv6 path is not the same vulnerability, although an IPv6 migration path involving CALIPSO is addressed by a separate patch.

Do not confuse demonstrated remote root access with general exposure

Anthropic’s proof of concept targeted a server with an MPTCP listener and combined a kernel address information leak with control-flow hijacking. The reported experiment took approximately 48 minutes to obtain the information leak and another five minutes to achieve command execution. Because a lost race only fails the handshake rather than crashing the system, an attacker can keep retrying. The underlying UAF, however, is in ordinary IPv4 TCP connection-request handling, not exclusively MPTCP code.

The same remote-root exploit technique has not been demonstrated for every conventional TCP service without MPTCP. Nevertheless, it is also incorrect to assume that disabling MPTCP makes a system fully safe. Red Hat states that MPTCP is not a required condition, that systems with MPTCP disabled (the default) remain affected, and warns of unauthenticated remote crashes, denial of service and memory corruption in standard IPv4 TCP services.

Primary vendor assessments: severity and fix status

Status as checked on November 3, 2026. Vendor pages change; always check the current entry before acting.

VendorSeverityFix status
Red HatCritical, CVSS v3.1 9.8Fixed kernels released November 1: RHEL 8 (RHSA-2026:93414; kernel-rt for NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). RHEL 9 kernel-rt and OpenShift (RHCOS) still listed as Affected. RHEL 6 and 7 not affected.
UbuntuPriority High; CVSS 9.8linux for 26.10, 26.04, 24.04 and 22.04: Vulnerable, work in progress. 20.04, 18.04 and 16.04: Vulnerable. No fixed package released yet.
Oracle LinuxImportant; provisional CVSS 8.1UEK errata dated October 16 (ELSA-2026-500397, -500398, -500399) for OL7 to OL10. RHCK errata dated November 2 for OL8 (ELSA-2026-93414) and OL10 (ELSA-2026-93413); no RHCK erratum listed for OL9 yet.
Debian(Security Tracker)Fixed in bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1), and trixie 6.12.113-1 (DSA-6568-1); forky and sid fixed.

Red Hat (assessment revised October 30; bulletin last updated November 2). The official CVE page rates the issue Critical, CVSS v3.1 9.8, because an unauthenticated remote attacker can corrupt kernel memory or crash a system over ordinary IPv4 TCP traffic. RHEL 8, 9, 10 and OpenShift are listed as affected; the RHEL 7 kernel is listed as not affected because the relevant code is absent. Since November 1, Red Hat’s CVE data lists fixed kernels: kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) and kernel-6.12.0-211.72.1.el10_2 (RHEL 10). Security bulletin RHSB-2026-016 was still marked as ongoing and is the place for the mitigation procedure. Do not present older secondary-source scores such as 5.9 or 8.1 as the current Red Hat assessment.

Ubuntu (official table last updated October 30). CVE CVSS 9.8, while Ubuntu’s own priority is High. Standard linux packages for Ubuntu 26.10, 26.04, 24.04 and 22.04 are marked “Vulnerable, work in progress”, with the planned fix versions shown on the page; 20.04 is marked Vulnerable, among other statuses. AWS, Azure, HWE, RT and other kernel flavors must be evaluated individually. “Work in progress” does not mean a fix has been released.

Oracle Linux. Oracle’s own assessment is Important, with a provisional CVSS score of 8.1. UEK errata for OL7, OL8, OL9 and OL10 are dated October 16, and RHCK errata for OL8 and OL10 followed on November 2. Fixes in UEK must not be generalized to RHCK or every minor release; assess the installed kernel and exact errata.

Debian. The official Security Tracker marks bookworm-security 6.1.190-1 and trixie-security 6.12.113-1, among others, as fixed. Verify both installed package versions and the running kernel following reboot.

CVSS results can differ between the CNA and vendors because of distribution-specific configurations and fixes, and assessments may change. Always record the verification date and link to each official source.

Defensive actions: mitigation is not a substitute for a patch

The first priority is to install a vendor-approved fixed kernel and verify the running version after reboot. Where a fix is not yet available, consider closing unnecessary public TCP services, restricting allowed source networks, and prioritizing monitoring on exposed hosts.

Red Hat’s bulletin describes an nftables mitigation that drops incoming IPv4 TCP packets carrying IP options in the IPv4 header:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

It is not complete protection, may disrupt workloads that rely on IP options, and must be tested for business-traffic impact before deployment. Ordinary TCP options in the TCP header remain permitted; this is not about blocking the TCP Options field. On OpenShift, node-level rules do not filter pod-to-pod traffic inside the cluster network, so filtering at the network boundary matters there. Remove the table once the fixed kernel is running.

Tip: After patching, compare uname -r with the fixed version in your vendor’s erratum, and keep that output with the change record. An installed package that is not yet booted does not close the vulnerability.

On Linux, the Go net package in Go 1.24 and later enables MPTCP for listeners by default. The Go team documents GODEBUG=multipathtcp=0 as a way to disable it (also available as a godebug line in go.mod). A proposal to change the default is still under discussion, and the Go maintainers point to a patched kernel as the real fix. The setting can reduce exposure to the MPTCP-dependent attack path demonstrated by Anthropic, but it does not fix the kernel UAF itself. Review MPTCP usage service by service.

LOGIQ perspective

Enterprise Linux maintenance cannot determine safety from a public CVSS number or uname -r alone. Assess the OS release, kernel family (UEK versus RHCK, for example), package release, currently booted kernel, network exposure, MPTCP settings, vendor errata and reboot evidence together. Track the entire chain from impact assessment and validation through deployment and operational monitoring.

Where vendor fixes are pending, document residual risk from temporary mitigations and reevaluate those mitigations after patches arrive. As AI increases the practical exploitability of vulnerabilities, enterprise maintenance must cover the full lifecycle: detection, verification, remediation, and evidence of healthy operation.

Primary sources and references