Login
You're viewing the mastodonapp.uk public feed.
  • Nov 3, 2026, 6:44 AM

    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.

    💬 23🔄 328⭐ 322

Replies

  • 💬 0🔄 0⭐ 6
  • Nov 3, 2026, 7:29 AM

    @malwaretech Syncthing also listens on MPTCP sockets (port *:22000 by default), so don't limit scans to the obvious (443, 8080,...)

    💬 1🔄 1⭐ 5
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 3
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 4
  • Nov 3, 2026, 8:32 AM

    @malwaretech thanks for reminding me to check on this. Worth mentioning that NixOS enables MPTCP by default. My kernel versions were new enough to not be affected since I patch regularly, but I have nevertheless disabled MPTCP fleet-wide in an attempt at attack surface reduction.

    💬 1🔄 0⭐ 2
  • 💬 0🔄 0⭐ 0
  • Nov 3, 2026, 8:39 AM

    @malwaretech FWIW the popular Prometheus node_exporter is GO-based and seems to open MPTCP by default.

    💬 1🔄 0⭐ 1
  • Nov 3, 2026, 8:47 AM

    @malwaretech found more processes with MLTCP, that might be in many o11y related hosts: VictoriaMetrics, VictoriaLogs, vmAlert, SNMP-Exporter, Grafana. Probably more…

    💬 0🔄 0⭐ 0
  • 💬 0🔄 1⭐ 0
  • Nov 3, 2026, 9:05 AM

    @malwaretech is MPTCP mandatory? genuine question. Anthropic paper says it uses mptcp to exploit, but the patch is for TCP itself.

    💬 1🔄 0⭐ 1
  • 💬 0🔄 0⭐ 0
  • panushadowdancer@mstdn.social
    Nov 3, 2026, 9:46 AM

    @malwaretech
    Just updated my internet-facing router. I don't think it has MPTCP enabled, but just in case.

    💬 0🔄 0⭐ 0
  • 💬 1🔄 2⭐ 2
  • 💬 0🔄 1⭐ 1
  • Nov 3, 2026, 10:18 AM

    @malwaretech I was surprised to find that my servers run Go via Anubis. I suppose it could be a good target because a lot of websites run it in front of every page!

    💬 0🔄 0⭐ 1
  • Nov 3, 2026, 10:52 AM

    @malwaretech 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.

    💬 0🔄 0⭐ 3
  • Nov 3, 2026, 10:54 AM

    @malwaretech

    Oops, just discovered that my Forgejo is listening on a potentially compromisable MPTCP port, per:

    sudo ss -Mlnp

    Now to figure out how to disable MPTCP on Ubuntu server…

    (Hmmm… It’s front-ended by nginx, and the port isn’t publicly accessible… does that mean I’m safe?)

    💬 1🔄 0⭐ 0
  • Nov 3, 2026, 11:14 AM

    So this seems to do it for new connections:

    sudo sysctl -w net.mptcp.enabled=0

    But still leaves active sockets using MPTCP. In my setup, this works:

    sudo systemctl restart forgejo

    💬 1🔄 0⭐ 1
  • 💬 0🔄 1⭐ 1
  • Nov 3, 2026, 11:58 AM

    @malwaretech just here with the other commenters to suggest updating the language about MPTCP being required. The original research makes it clear that it is not, as have a number of subsequent analyses.

    💬 0🔄 0⭐ 2
  • Nov 3, 2026, 1:44 PM

    @malwaretech 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)

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 1
  • 💬 0🔄 0⭐ 3
  • Nov 3, 2026, 2:36 PM

    @malwaretech 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.

    💬 1🔄 0⭐ 1
  • Nov 3, 2026, 9:43 PM

    @JezCaudle @malwaretech, sounds like old(ish) iproute2 there, definitely older than 6.15.0 if it's not properly documenting -M – that's the version in Devuan stable (inherited from Debian), and it does document that option in both places. (And it's probably not the oldest version to do so.)

    💬 0🔄 0⭐ 0
  • Nov 3, 2026, 2:40 PM

    @malwaretech thanks! Found some many docker processes listening with mctcp.

    Does the net.mptcp.enable=0 survives reboot?

    💬 1🔄 0⭐ 0
  • Nov 3, 2026, 3:10 PM

    @dacmot It does not. For persistent changes, edit a file in /lib/sysctl.d/ such as, on Fedora or Debian, /lib/sysctl.d/50-default.conf to add "net.mptcp.enable = 0"

    💬 1🔄 1⭐ 1
  • Nov 3, 2026, 9:48 PM

    @rose @dacmot, actually, no. That's the wrong place: it'll be overwritten when linux-sysctl-defaults (or its Fedora equivalent) is updated. Put that line in a file in /etc/sysctl.d.

    (Also, it's actually /usr/lib/sysctl.d/50-default.conf; you just found it via /lib because of the usr-merge shenanigans.)

    💬 1🔄 0⭐ 2
  • Nov 4, 2026, 12:51 AM

    @lp0_on_fire @dacmot Thanks. I actually experienced that overwriting today when I upgraded Fedora 44 => 45. It makes sense not to edit files in [/usr]/lib/.

    💬 0🔄 0⭐ 0
  • Nov 3, 2026, 3:16 PM

    @malwaretech
    What about turning off MTCP with modprobe? Or is it not implemented as a regular kernel module?

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Nov 3, 2026, 6:50 PM

    @malwaretech 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

    💬 0🔄 0⭐ 0
  • Nazonazokiyoubinbou@urusai.social
    Nov 3, 2026, 6:58 PM

    @malwaretech 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.

    💬 0🔄 0⭐ 0