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.

Machine Speed is a lie: stop trying to fight AI with AI

Marketing departments are screaming that attackers are moving at "machine speed" and only AI-powered defenses can stop them. But cyberattacks have always been automated, and proactive defense beats reactive AI.

https://malwaretech.com/2026/09/machine-speed-is-a-lie-stop-trying-to-fight-ai-with-ai.html?a=1

Found an interesting new malware loader which creates a fake Windows lock screen to phish the user's system login password. The fully-modular loader also bridges multitude different programming languages, including: Python, C#, C++, and PowerShell.

This extensive use of cross-language components, along with shipping an entire runtime environment, lead to us dubbing it SynkLoader (Sink Loader), because it brings everything but the kitchen sink.

While the original loader runs all of its modules in memory only, we were able to collect them by reverse engineering the command-and-control protocol, then building our own version of the loader which logs everything to disk.

Additionally, we were able to to lure the operator into thinking they had a reverse shell on our honeypot system. This allowed us to watch as they attempted to execute PowerShell commands, which were being printed to our system's console instead of being run.

Full analysis: https://expel.com/blog/synkloader-when-you-throw-in-everything-but-the-kitchen-sink/