Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

CVE-2026-98432: Linux Kernel TCP Flaw Enables Remote Root on MPTCP Servers

A critical use-after-free in the Linux kernel's TCP stack has been shown to give unauthenticated attackers root on servers with MPTCP listeners. Patches are still landing unevenly across distributions — here's what is affected and what to do now.

4T4Tify Team4Tify
Oct 31, 2026·5 min read
CVE-2026-98432: Linux Kernel TCP Flaw Enables Remote Root on MPTCP Servers

CVE-2026-98432: Linux Kernel TCP Flaw Opens the Door to Remote Root on MPTCP Servers

A critical use-after-free in the Linux kernel's IPv4 TCP stack, tracked as CVE-2026-98432, can be turned into unauthenticated remote code execution as root on servers that accept Multipath TCP (MPTCP) connections. A working exploit has already been demonstrated, and patches are still rolling out unevenly across major distributions.

What happened

The bug is a race condition in how the kernel processes incoming TCP connection requests. While a connection is being promoted from a pending request to a full socket, the kernel hands the IP options buffer over to the new socket without making its own copy. If a retransmitted SYN for the same request is being handled on another CPU core at the same moment, that second code path can keep reading memory that has already changed hands — a classic use-after-free. A similar window exists during request-socket migration, when net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in use.

Key facts:

  • Affected: Linux kernels from 4.4 onward, including Ubuntu, Red Hat Enterprise Linux and Rocky Linux builds.
  • Severity: rated 9.8/10 by the Linux kernel CVE team. Red Hat scores it lower, at 5.9, treating it mainly as a kernel-crash (denial-of-service) risk because winning the race is difficult.
  • Proven RCE: a demonstration exploit — produced by a not-yet-released AI model — defeated kernel address space layout randomization (KASLR) and ran arbitrary commands as root on a server with an MPTCP listener, under specific conditions, in roughly 53 minutes.
  • Plain TCP is affected too, although remote code execution has not been publicly shown against servers without an MPTCP listener.
  • No confirmed in-the-wild exploitation at the time of writing.
  • Not affected: macOS (different kernel) and RHEL 7 (the vulnerable code isn't present).

Why it matters

MPTCP lets one connection spread across several network paths at once — Wi-Fi and cellular, for example — and is usually off unless an application asks for it. The catch: since Go 1.24, TCP listeners on Linux opt into MPTCP by default whenever the kernel supports it. Any Go-based service could therefore be exposing an MPTCP listener without its operators ever having switched it on.

The gap between the two severity scores is also worth noting. A difficult race is not an impossible one, and a public demonstration that turns a "crash bug" into remote root inside an hour shows how quickly exploitation timelines are shrinking — especially as AI-assisted exploit development matures.

Patch status (as of 30 October 2026)

  • Upstream kernel: fixed and backported to maintained stable branches.
  • Debian: fixed in kernel 6.1.190-1 (Debian 12 "Bookworm") and 6.12.113-1 (Debian 13 "Trixie"); testing and unstable are also fixed.
  • Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 still vulnerable, with kernel fixes in progress.
  • RHEL 8, 9, 10 / Rocky Linux 8, 9, 10: affected; fixes are planned for upcoming updates.
  • Oracle Linux, Amazon Linux, SUSE: fixes available for some kernel versions.

What to do

  1. Patch first. Track your distribution's security advisories and install updated kernel packages as soon as they land — then reboot, or confirm your live-patching covers this CVE.
  2. Find your MPTCP exposure. Run ss -Mtln to list MPTCP listeners and check sysctl net.mptcp.enabled. Pay particular attention to services built with Go 1.24 or later.
  3. Don't rely on disabling MPTCP alone. The underlying flaw can still be reached over ordinary TCP, so turning MPTCP off reduces the proven RCE path but does not close the bug.
  4. Filter where you can't patch yet. Restrict exposed services to trusted networks or IP ranges. As a temporary measure, drop inbound IPv4 TCP packets that carry IP options at the host or perimeter firewall (for example with nftables) — legitimate traffic almost never uses them. Test before rolling out broadly.
  5. Review migration settings. If you don't need it, leave net.ipv4.tcp_migrate_req disabled and audit any reuseport BPF programs.
  6. Watch for crashes. Unexplained kernel panics or oops messages in TCP code on internet-facing hosts deserve investigation, not just a reboot.

Knowing which of your internet-facing hosts still run a vulnerable kernel — and which quietly expose services you didn't expect — is exactly the kind of gap our vulnerability scanning service is built to surface, so patching effort goes where the real exposure is.

SHARE