Linux kernel CVE-2026-98432 scores 9.8, but the known root exploit needs one thing: an MPTCP listener

On October 15, 2026 the Linux kernel team published CVE-2026-98432, a use-after-free in the IPv4 TCP handshake code. Within two weeks the Go security team, Red Hat and Anthropic's researchers all weighed in, and the story picked up two claims that the primary sources do not fully support: that every Linux server is one packet from remote root, and that a harmless-looking list of IPv4 options is the trigger. Here is what the sources actually say, who has to act, and how to check a machine in a minute.

What is actually broken

When a client retransmits its first TCP packet (a SYN) while the server is still setting up the connection, two CPUs can work on the same half-open connection at once. One of them frees the connection's IPv4 options with a plain kfree(); the other is still reading those options to build the reply, a use-after-free in ip_options_build(). The fix by Eric Dumazet makes the free wait for an RCU grace period (kfree_rcu()), and was committed to mainline on October 5, 2026 (mainline commit). A second, similar path exists when connection requests are migrated between listener sockets (net.ipv4.tcp_migrate_req=1 or a BPF reuseport program), added to the kernel in 2021. The report credits Xinyang Ge of Anthropic.

IPv6 is not affected by the first issue because the IPv6 path copies the options. No account, token or user action is needed; the attacker only needs to reach an open IPv4 TCP port. Red Hat's own description is cautious about the outcome: the flaw "primarily results in a system crash" or memory corruption, and reliable code execution "would require precise heap control" (Red Hat).

Why MPTCP is the detail that matters

Anthropic describes a proof of concept that lets a remote attacker "run arbitrary commands as root" against "Linux servers with a multipath TCP listener" (Anthropic, Oct 27). The Go team, which flagged the issue to Go developers, says the same: the exploit requires an MPTCP listener, the bug itself "is not specific to MPTCP", and it is unknown whether a path to code execution exists without one (Go issue 82717). A maintainer on the Multipath TCP side argued in the same thread that the lab reproducer was noisy and unlikely to work outside a lab; that is an opinion, not a measurement.

Why this reaches more machines than it sounds: since Go 1.24, Go programs enable MPTCP by default on Linux listening sockets (oss-security). A Go service you forgot about can be the one listener that turns a crash bug into a root exploit. What we conclude: do not read "needs MPTCP" as "safe without it"; read it as the way to rank your hosts.

Fact check: what the viral summary got right and wrong

Who is affected

• Any Linux host with an IPv4 TCP port reachable by an attacker and a kernel without the fix: web servers, load balancers, SSH bastions, Kubernetes nodes, containers sharing the host kernel. Containers do not have their own kernel; patch the host.
• Highest priority: hosts with an MPTCP listener, including any Go 1.24+ service that listens on a public port.
• Not affected: hosts that never accept IPv4 TCP connections. Ubuntu 14.04 is listed as not affected.
• Distro state (Nov 2, 2026): Debian fixed in bookworm 6.1.190-1 and trixie 6.12.113-1 (tracker). SUSE has fixed kernels for SLES 15 SP4–SP6 and 16.0 and is still working on others (SUSE). Red Hat rates it Critical and is "expediting" fixes for RHEL 8, 9 and 10 (RHSB-2026-016). Ubuntu 22.04 to 26.10 are vulnerable with fixes in progress; 20.04 and older list no fix (Ubuntu).

How to check your system

• Kernel version: uname -r, then look for the CVE in your distro's changelog: apt changelog linux-image-$(uname -r) | grep CVE-2026-98432 on Debian and Ubuntu, rpm -q --changelog kernel | grep CVE-2026-98432 on RHEL and SUSE. No match means no fix yet. A running kernel is only the patched one after a reboot.
• MPTCP: sysctl net.mptcp.enabled. 1 means the kernel accepts MPTCP; whether a service actually listens with it depends on the program (Go 1.24+ does by default).
• What is exposed from outside: a list of your internet-facing hosts and open IPv4 TCP ports is the real starting point, because you patch the exposed ones first.

What to do

1. Patch the kernel and reboot (or apply the vendor's live patch where offered). Red Hat: "Applying kernel security updates as they become available is the only complete solution." Order: internet-facing hosts with MPTCP listeners, then other internet-facing hosts, then internal ones.
2. If you cannot patch yet, Red Hat publishes an nftables rule that drops incoming IPv4 TCP packets that carry IP options (ip protocol tcp ip hdrlength > 5 counter drop). Red Hat says it "cannot fully prevent" the attack; test it first. Remove it after patching (sudo nft delete table inet cve_2026_98432).
3. Disable MPTCP system-wide with sysctl -w net.mptcp.enabled=0 (oss-security). It breaks programs that need MPTCP, and long-running Go programs may see errors on new connections. For Go services, GODEBUG=multipathtcp=0 also turns it off, but the Go team calls this "fragile" and notes it "does not disable the underlying kernel use-after-free".
4. Do not rely on the mitigations alone. All of them reduce the known exploit path; only the fixed kernel removes the bug.

What we do not know

• Whether remote code execution is possible without an MPTCP listener. The Go team says it does not know and advises against assuming it is not.
• Whether exploit code is public. Anthropic describes a proof of concept; we found no public exploit linked to the CVE.
• Whether anyone is exploiting it. No source reports attacks, and it is not in CISA KEV. Check the KEV catalog and our radar rather than waiting for a headline.
• Fix dates for RHEL 8, 9 and 10 and for older Ubuntu releases.

Data as of 2026-11-02live record →

Sources: NVD entry for CVE-2026-98432, mainline fix commit e3f33b0a1d89, Red Hat CVE page, Red Hat bulletin RHSB-2026-016, SUSE, Debian security tracker, Ubuntu, Go issue 82717, Anthropic research, oss-security, Go team notice, Oct 29, oss-security, Oct 30, CISA KEV catalog. Statistics: CVE Tools index, Nov 2, 2026.