Update on the 9.8 CVSS TCP/IP RCE in the Linux kernel (CVE-2026-98432): we've detected what appears to be a threat actor activity scanning the entire internet for exposed affected systems. Our own scanning also suggests that the number of potential targets is high, therefore there is an increased likelihood of threat actors attempting to develop exploits for the vulnerability.
while CVE-2026-98432 is believed to require MPTCP to be enabled in the kernel, as well as a listening app/service which binds an MPTCP socket, which many have suggested should be rare, several kernels including Debian enable MPTCP by default.
Additionally, Go 1.24+ binds MPTCP sockets by default if the option is enabled in the kernel, so anything built on top of Go (including Caddy) will create the required MPTCP listener.
The mitigation of setting net.mptcp.enabled=0 disabled MPTCP, but does not apply to existing sockets, so any applications that have bound MPTCP sockets need to be restarted, otherwise the system remains exploitable.
You can check if your server is running any MPTCP listeners with the following command: sudo ss -Mlnp
On 2026-10-30 our preliminary internet-wide scan of port 443 confirmed that there are approximately 2,102,043 servers that are successfully reachable via an MPTCP connection. A deeper scan which attempts to connect to each endpoint on port 443 and negotiate a full TLS connection with MPTCP enabled returned about 762,774 systems.
Neither scan can confirm that these are unpatched kernels, just total exposure, but it's a lot more systems than expected. Since a valid HTTP connection is not required to exploit the vulnerability, the total attack surface is likely closer to the 2.1 million number than the 763k one.
As of today (2026-11-02), we've picked up several residential proxies and VPNs scanning the internet on port 443 using MPTCP-enabled connections. Since regular scanners do not negotiate MPTCP by default, and no data is being sent to the HTTP server over 443, we strongly suspect this activity is scanning for CVE-2026-98432 specifically. The use of residential proxies and RU-based VPN servers suggests that this is likely threat actor scanning, rather than security researchers.
Currently there are no known publicly available remote code execution exploits, but there are several denial of service proof-of-concepts floating around. This code gives threat actors a starting point to begin attempting to weaponize the vulnerability. Building exploits for the vulnerability is reported to be extremely difficult, but several state-sponsored threat actors likely have the resources required to succeed.
Ikkqqstudio likes this.
reshared this
Eric de Redelijkheid, Florian Schmidt, L'égrégore André ꕭꕬ, fhekland, Stullekovski pumkinpunk 🎃, Alanna, Lenz Grimmer, sjar@itsmesjarlie 🌻, Trendy Toots, hex, Eloy, no longer at eth0, F4GRX Sébastien ⸚, Marcus 🦀 Borkenhagen, jwz, Piiieps & Brummm, Ally Miller, Stuart Longland (VK4MSL), NormanDunbar, Jules 🍺, Ikkqqstudio, Colin M, young man yells at the cloud, Rita, Matt Edwards 🚴♂️, BrianKrebs, Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸, Marcos Dione, Aaron, Ben Griffith, Eoin Prout, pallas, Cat 🐈🥗 (D.Burch), Nazo, Matrixes, Lord Caramac the Clueless, KSC and Atomic Orbitals reshared this.
hambier
in reply to Marcus Hutchins • • •Old Byte
in reply to Marcus Hutchins • • •Old Byte
in reply to Old Byte • • •Alice Pea (she/her) 🏳️⚧️
in reply to Marcus Hutchins • • •Got it. Disabled MPTCP on my main servers.
This is some scary shit, NGL. I mean, an RCE vulnerability in the TCP/IP stack of all places?
x123
in reply to Marcus Hutchins • • •timov
in reply to Marcus Hutchins • • •Mitex Leo
in reply to Marcus Hutchins • • •HolgerH 霍尔格 reshared this.
Clathetic
in reply to Marcus Hutchins • • •panu
in reply to Marcus Hutchins • • •chx
in reply to Marcus Hutchins • • •Lily Cohen reshared this.
Die Banane
in reply to Marcus Hutchins • • •Matthieu Baerts
in reply to Marcus Hutchins • • •hey, just a reminder that blocking MPTCP is not the proper fix: MPTCP has the vulnerability because it is on top of TCP which has the bug. And it happened Anthropic used MPTCP because it "only" took them 50+ minutes in a lab to attack a remote host.
The proper workaround is to block IPv4 options, which are certainly already blocked in many places for years.
social.kernel.org/notice/BBxO9…
BTW, researchers showed that some firewalls (e.g. China) are replying with the same TCP options.
Multipath TCP (@mptcp@social.kernel.org)
social.kernel.orgrdeaton
in reply to Marcus Hutchins • • •guenther
in reply to Marcus Hutchins • • •Does the Go thing only apply to apps that use Go's http server or also scenarios where you have docker exposing public ports?
And does the Go app need to be the listener on an exposed port or is it enough that there is one go app running on the system listening to some (local) socket? (e.g. behind a reverse proxy)
Sam Bryan
in reply to Marcus Hutchins • • •I was wondering when the patched Ubuntu kernels would be out. TL;DR - the fixes are available now in the -proposed pocket, and will make it into the regular updates when testing is complete.
ubuntu.com/blog/fixes-availabl…
Fixes available in -proposed pocket for CVE-2026-98432 | Ubuntu
Luci Stanescu (Ubuntu)S1m
in reply to Marcus Hutchins • • •access.redhat.com/security/vul…
RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432) | Red Hat Customer Portal
Red Hat Customer PortalJez Caudle
in reply to Marcus Hutchins • • •Looked up the man page for ss on Ubuntu to see what the switches did. No mention of -M.
ss -h DOES reveal what the -M flag is for. As do other man pages ont’Internet.
Poor. Very poor.
Unlike your post. Champion.
Phracker
in reply to Marcus Hutchins • • •Nazo
in reply to Phracker • • •wall-e
in reply to Marcus Hutchins • • •if you happen to have a non-Linux TCP terminating proxy in your network path, you should be safe though.
Something like an F5 BigIP (data plane TCP stack goes through a custom micro kernel) in full proxy mode with MPTCP disabled (default) should protect backends behind it*, because it handles a Client <-> F5 TCP connection and establishes its own TCP handshake with backend systems.
* caveat: as far as I know, F5 haven't explicitly said their microkernel is safe against this CVE
Nazo
in reply to Marcus Hutchins • • •I truly truly can't believe that Ubuntu still has not fixed this despite it being such a critical security issue. Everything else I had was already fixed by the time I saw it. Ironically I put a server on Ubuntu (many years ago) because I thought it would offer better long term security support. Hah... Starting to regret that now.
If I was a big business I'd potentially consider suing Canonical for just sitting on their duffs for this.