Where ‘2.1 million unpatched servers’ came from: CVE-2026-98432 scans and patch streams

The 2.1 million figure for CVE-2026-98432 measures MPTCP reachability. It does not establish an unpatched population or identify every endpoint as Ubuntu. The preceding article missed released fixes; this follow-up checks the original account and explains what disabling MPTCP can establish.

What the scan counted

Marcus Hutchins’s original post reports approximately 2,102,043 endpoints reachable over MPTCP on port 443 in his team’s 30 October scan. A deeper measurement requiring a complete TLS connection returned about 762,774. His qualification is explicit: “Neither scan can confirm that these are unpatched kernels”. Adding the figures or deriving a patching rate from their difference would exceed the evidence.

The identical Mastodon post was published at 14:44 Taipei time on 3 November. It dates the suspected scanning activity to 2 November and the team’s own measurement to 30 October. These are Hutchins’s reported figures, without an accompanying dataset or independent reproduction here, and they are not a fresh count for 5 November.

Where MPTCP must be enabled

The MPTCP project’s build documentation names Debian, Ubuntu, Red Hat and Fedora as distributions compiling in support. Published CentOS Stream 9 and Stream 10 configurations explicitly contain CONFIG_MPTCP=y. That establishes kernel capability.

The upstream sysctl documentation gives net.mptcp.enabled a default of 1, allowing socket creation separately in each network namespace. RHEL’s product documentation instead says MPTCP is disabled by default. Whether Debian overrides that default with its own sysctl setting could not be confirmed from a readable package source, so Hutchins’s Debian claim holds at the compiled-capability level and no further. I found no first-party evidence of the shipped default for Ubuntu or Fedora either, nor enough configuration detail for SUSE, Amazon Linux or Alpine. Check the installed kernel package and the relevant namespace rather than inferring a host setting from its distribution name.

Go 1.24 changed ListenConfig to prefer MPTCP on Linux when the kernel supports and permits it. The GODEBUG documentation specifies multipathtcp=2, enabling listeners only; dialers retain their previous default. GODEBUG=multipathtcp=0 disables the default, while a main module declaring an older Go version can retain older behaviour. The Go security team also identifies net.ListenConfig.SetMultipathTCP and net.Dialer.SetMultipathTCP as explicit per-socket overrides. A new compiler alone does not establish what a running service binds.

The net package documentation describes fallback to TCP when MPTCP is unavailable on the host or unsupported by the peer. Per-socket selection remains subject to kernel support. A sysctl value of 1 permits socket creation; it does not prove that an application requested MPTCP or currently has a listener.

Caddy v2.11.7’s module declares go 1.26.0. Its proposal to disable the default was closed without merging, and a maintainer’s response leaves configuration to system administrators. These facts justify inspecting deployed listeners; they do not establish exploitability for every Caddy instance.

Hutchins describes exploitation as “believed to require MPTCP”, while Red Hat’s RHSB says RHEL remains affected with MPTCP disabled by default. Read these at their respective levels: the demonstrated exploitation conditions and the underlying vulnerability. This article does not adjudicate between them or treat the demonstrated conditions as an exhaustive exposure test.

The same RHSB explicitly says net.mptcp.enabled=0 governs subsequent socket creation. Existing sockets survive, so services using them need restarting; the kernel still needs patching. According to the ss manual, ss -Mlnp lists MPTCP listeners and available process information in the current network namespace. It cannot establish external reachability, patch status or successful exploitation. An empty list does not establish safety, and diagnostic support in the tool and kernel must also be checked. Here -M selects MPTCP, -l selects listening sockets, -n suppresses name resolution and -p requests process information. Other container namespaces are not automatically included.

What changed in the retelling

International Cyber Digest presented suspected scanning as attacker activity. HKEPC’s subsequent post quotes that account. Hutchins describes observed traffic from residential proxies and VPNs, but attribution to threat actors remains his inference. That qualification should survive retelling. Four claims warrant qualification:

Its description of 2.1 million machines exposed without protection appears in a passage about Ubuntu. This changes both the measured population and the meaning of the count; the original supports MPTCP reachability.
Its blanket claim that Ubuntu had released no official patch omits 26.10’s published packages, while some LTS fixes remained in testing.
Its claim that triggering the flaw during the TCP handshake suffices for root access omits exploitation conditions. Anthropic’s demonstration used hosts with an MPTCP listener; it does not establish that outcome for every handshake.
Its claim that weaponisation is easy lacks support in the cited account. Hutchins reports considerable difficulty. His suggestion that state-sponsored actors probably have sufficient resources is speculation, without evidence of successful exploitation by those actors.

Match a patch to its stream

Red Hat’s security data API lists these mainline advisories dated 1 November. Package names omit epoch and architecture.

Stream	Fixed package	Advisory
RHEL 8.10	`kernel-4.18.0-553.182.1.el8_10`	RHSA-2026:93414
RHEL 9.8	`kernel-5.14.0-687.64.1.el9_8`	RHSA-2026:93412
RHEL 10.2	`kernel-6.12.0-211.72.1.el10_2`	RHSA-2026:93413

RHSA-2026:94996, dated 4 November, covers particular RHEL 8.6 extended-support streams with kernel-4.18.0-372.227.1.el8_6. The listed OpenShift 4 and 5 RHCOS entries remain affected. Neither advisory covers every product stream.

Canonical identifies Ubuntu 26.10’s 7.3.0-10.10 as fixed, and Launchpad source and generic binary records establish publication in Updates and Security. The corresponding linux fixes for 22.04, 24.04 and 26.04 remain in Proposed only, excluded from default upgrades. Other kernel flavours require separate checks.

The Ubuntu CVE tracker still labels 26.10 as work in progress. Source publication records instead place the package in Updates at 06:19 Taipei on 29 October and Security at 20:22 on 2 November. Preserve that discrepancy; a page’s update date alone cannot settle package availability.

These releases precede the earlier article’s cut-off of 01:18 Taipei on 4 November, making them omissions in the original check. Publication also says nothing about which kernel a customer has booted. After updating and rebooting, compare uname -r with the vendor’s fixed version.

Limits of mitigation and exploitation evidence

AWS’s IPv4-options filtering example needs saving to survive reboot. Network Firewall requires strict order, and stateless-pass traffic bypasses the rule. Container traffic needs assessment against the namespaces it traverses; the presence of a host rule alone is insufficient.

The same AWS bulletin makes its advice for ALB, CloudFront and NLB TLS conditional on backends not accepting untrusted TCP directly. It still recommends updating self-managed backends within 30 days. Separate public entry points require their own assessment.

Red Hat explains that node rules cover traffic traversing the host network namespace. It reports no available pod-to-pod mitigation, while applying rules within each pod leaves gaps during creation or rescheduling.

AWS still reports no evidence of exploitation. The retrieved CISA KEV catalogue, version 2026.11.03, contains 1,767 entries without this CVE. Neither observation excludes exploitation elsewhere. Hutchins reported DoS proofs of concept and no known public RCE exploit, a statement limited to his knowledge at that time.

Public projects include one whose author claims only to reproduce the UAF, and a tool checking packet filtering. This review read their descriptions without running them. Their existence establishes neither a complete public RCE chain nor a patched kernel.

Notes

Reachability counts cannot supply an unpatched-host total.
Compiled support, the sysctl and actual listeners are separate checks.
Disabling MPTCP requires attention to existing sockets and leaves patching necessary.
Match fixes to product streams and verify the running kernel.