CVE-2026-98432 is a CVSS 9.8 Linux kernel vulnerability, a use-after-free in the IPv4 TCP handshake code that an unauthenticated attacker can reach by connecting to any listening IPv4 TCP port. It has been in the kernel since Linux 4.4 in January 2016, it was fixed upstream in early October 2026, and on 27 October Anthropic said an unreleased internal research model had built a working remote root exploit against servers with a Multipath TCP (MPTCP) listener. The news this week is that someone appears to be looking for those servers. On 2 November, researcher Marcus Hutchins (MalwareTech) reported residential proxies and Russia-based VPN servers scanning port 443 across the internet with MPTCP-enabled connections that send no HTTP data, and his own scan on 30 October found about 2.1 million servers reachable over MPTCP on that port alone. There is still no public remote code execution exploit and no confirmed exploitation, but there are several public denial-of-service proofs of concept, and the gap between “crash” and “root” is exactly what well-funded attackers are good at closing.<\/p>\n
This post is three things. First, a plain-English explanation of the bug built from the kernel’s own CVE record, including the part most coverage gets wrong: the flaw is in ordinary IPv4 TCP, not in MPTCP, so turning MPTCP off shrinks the target list without fixing anything. Second, a detection kit that is honest about what the network can tell you: an authenticated Nuclei template that reads the running kernel over SSH and returns a patched, affected or unknown verdict per distribution, plus a script that measures MPTCP exposure the same way the internet-wide survey did. Third, a way to find every affected host across an attack surface, including the Go service someone deployed last year that opened an MPTCP listener without anyone deciding it should. The kernel fix is credited to the upstream networking maintainers; the exploit claim is Anthropic’s Frontier Red Team’s; the scanning data in this post is Marcus Hutchins’, and we quote it rather than repeat it as our own.<\/p>\n
CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:H\/I:H\/A:H<\/code> (kernel CNA). Red Hat now rates it Critical 9.8 too, after starting at Moderate 5.9 and moving to Important 8.1 on 29 October. Other vendors score it lower, mainly by rating attack complexity high.<\/li>\n- Affected<\/strong>: Linux 4.4 and later (introduced by commit
079096f103fa<\/code>). That covers every supported Debian, Ubuntu, RHEL, Rocky, AlmaLinux, SUSE and Amazon Linux kernel.<\/li>\n- Fixed upstream<\/strong>: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3 (mainline commit
e3f33b0a1d89<\/code>, 7.3-rc7).<\/li>\n- Exploitation status (3 November 2026)<\/strong>: no public RCE exploit, several public DoS proofs of concept, suspected threat-actor MPTCP scanning since 2 November. Not in CISA KEV. EPSS 0.76%.<\/li>\n
- Fix now<\/strong>: install your distribution’s fixed kernel and reboot<\/strong>. Until you can, apply Red Hat’s nftables rule that drops inbound IPv4 TCP packets carrying IP options.<\/li>\n<\/ul>\n
What is CVE-2026-98432?<\/h2>\n
Every IPv4 header can carry options. Two old ones, Record Route and Timestamp, ask routers along the path to stamp their address or the time into the packet. Almost nobody uses them, many networks drop them, but nothing stops a client from putting them in a SYN. When a Linux server receives such a SYN on a listening socket, it saves the options in the request socket (ireq->ireq_opt<\/code>) so it can echo them correctly in its SYNACK.<\/p>\nThe bug is about who owns that saved buffer. When the handshake completes, tcp_v4_syn_recv_sock()<\/code> hands the pointer to the new child socket (newinet->inet_opt<\/code>) without copying it. Meanwhile, another CPU can be handling a retransmitted SYN for the same request and building a SYNACK from the same options in tcp_v4_send_synack()<\/code> and ip_options_build()<\/code>. Those readers only hold rcu_read_lock()<\/code>, which promises that the memory survives until an RCU grace period ends. But when the child socket is torn down, inet_sock_destruct()<\/code> frees the options with a plain kfree()<\/code>, not kfree_rcu()<\/code>. If the connection completes and dies while the retransmit is mid-flight, the SYNACK is built from freed memory.<\/p>\nThe record names a second path. With request socket migration enabled (net.ipv4.tcp_migrate_req=1<\/code>, or a BPF SK_REUSEPORT_SELECT_OR_MIGRATE<\/code> program), a cloned request socket and its original share one options buffer, and tcp_v4_reqsk_destructor()<\/code> frees it the same unsafe way. The fix is two lines in spirit: use kfree_rcu()<\/code> in both destructors. IPv6 is not affected by the first path because tcp_v6_syn_recv_sock()<\/code> duplicates the options; its migration path only matters with CALIPSO labelling and is being fixed separately.<\/p>\nThe kernel CNA attached unusually detailed scoring notes to its CVSS vector, and they explain why this is rated 9.8 rather than “just a crash.” If an attacker reclaims the freed buffer, a stale length makes ip_options_build()<\/code> copy adjacent kernel heap into the SYNACK and send it back to the peer: a remote memory disclosure. Stale offsets steer writes, which is a path to control-flow corruption. And a bad length can push the packet past its headroom and panic the kernel. Read together, that is the outline of a two-stage remote exploit: leak, then write. It matches Anthropic’s claim, which it described as 48 minutes to leak a kernel pointer and five more to run commands as root.<\/p>\nWhere MPTCP comes in, and where it does not<\/h3>\n
Neither the CVE record nor the patch mentions Multipath TCP. MPTCP entered the story through Anthropic’s announcement, whose demonstrated exploit targeted servers with an MPTCP listener, and Anthropic has not said why that listener helps. Red Hat’s bulletin is blunt: MPTCP “is not a required condition for this flaw,” and RHEL nodes in their default configuration, where MPTCP is off, are still affected. The Go security team’s advisory makes the same point from the other side: the demonstrated exploit needs an MPTCP listener, but the underlying bug is not specific to MPTCP, and Go’s Damien Neil has said that nobody knows whether a viable RCE path exists without one.<\/p>\n
So the defensible reading is this. Every unpatched kernel with a reachable IPv4 TCP listener can be crashed, and may be exploitable by a technique nobody has shown yet. Hosts with an MPTCP listener are the ones where root has actually been demonstrated. That makes MPTCP exposure the right way to prioritize, and the wrong way to decide whether to patch.<\/p>\n
Why so many servers have an MPTCP listener<\/h2>\n
Most people would guess MPTCP listeners are rare. Two defaults make them common.<\/p>\n
Some distributions enable MPTCP in the kernel by default.<\/strong> Debian and Ubuntu ship with net.mptcp.enabled=1<\/code>. The RHEL family (RHEL, Rocky, AlmaLinux, CloudLinux) ships with it off.<\/p>\nGo 1.24 and later ask for MPTCP on every listening socket on Linux.<\/strong> The Go runtime’s multipathtcp<\/code> setting defaults to 2, “MPTCP on listeners only,” so any Go 1.24+ server on a kernel that allows MPTCP opens an MPTCP listener without a line of code asking for it. That includes Caddy, and potentially every other Go 1.24+ service you run that has not opted out, down to the internal tools your developers built last quarter. We found one on our own workstation while writing this post: the metrics endpoint of a Nuclei process, which is a Go binary, was listening on MPTCP. It was bound to loopback and harmless, but nobody had chosen to open it.<\/p>\nThat is why the survey numbers are larger than expected. Marcus Hutchins reported that his preliminary internet-wide scan of port 443 on 30 October found approximately 2,102,043<\/strong> servers reachable over an MPTCP connection, and a deeper scan that negotiated a full TLS session over MPTCP returned about 762,774<\/strong>. As he notes, neither number says anything about patch state; they measure exposure. And because exploitation does not need a valid HTTP or TLS exchange, he argues the real attack surface is closer to the 2.1 million figure. That is one port. SSH on 22, admin consoles and APIs on other ports add to it.<\/p>\nIs CVE-2026-98432 being exploited? The scanning activity<\/h2>\n
As of 2 November, Hutchins reports picking up several residential proxies and VPN exit nodes scanning port 443 with MPTCP-enabled connections and sending no data to the HTTP server behind it. His reasoning for calling it CVE-2026-98432 reconnaissance is sound: ordinary scanners do not negotiate MPTCP, and a probe that completes an MPTCP handshake and then says nothing is checking exactly one thing. The use of residential proxies and Russia-based VPNs suggests a threat actor rather than a research project, which typically scans from attributable ranges and publishes its scanner IPs.<\/p>\n
What this is not: confirmed exploitation. AWS said it had no evidence of exploitation, Red Hat’s bulletin reports none, and as of 3 November the CVE is not in CISA’s Known Exploited Vulnerabilities catalog. What it is: someone building a target list for a bug that already has public crash code. Building a reliable remote kernel exploit for a timing-dependent use-after-free is reported to be extremely difficult. It is also exactly the kind of work state-sponsored teams fund, and the existence of a working exploit, even an unpublished one, proves it can be done.<\/p>\n
Affected and fixed versions<\/h2>\n
Upstream stable kernels, from the kernel CNA record:<\/p>\n