# CVE-2026-98432: Fears mount over Linux kernel networking bug. Are they justified? > Source: > Published: 2026-11-03 12:21:09+00:00 Infosec’s chatterati have their knickers in a tight twist (that’s ‘panties in a bunch’, for our American friends) over yet another celebrity CVE that may or may not be deeply worrying. We are referring, of course, to [__CVE-2026-98432__](https://nvd.nist.gov/vuln/detail/cve-2026-98432?ref=thestack.technology) – a vulnerability in the Linux kernel's IPv4 networking subsystem publicly disclosed by Anthropic on Oct. 27. Aikido security says that "Any Linux host running kernel 4.4 or later with an IPv4 TCP port an attacker can reach" is affected. (IPv6 is not affected.) On AWS, that potentially exposes "self-managed EC2 and Lightsail instances, ECS on EC2 container instances and EKS nodes" to active scanning by threat actors – which appears to be starting; read on. ### Is CVE-2026-98432 a real issue? Anthropic [__says__](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude?ref=thestack.technology) it has developed an exploit that under certain conditions gives a remote attacker root on a Linux server with a multipath TCP (MPTCP) listener; it says this is possible with no credentials and no user interaction. Using it as a route to remote code execution (RCE) requires an attacker to win a race condition and Red Hat, for example, initially deemed it “important” but not critical in its advisory. AWS says it is "applying updates to the underlying infrastructure" of its WAF and load balancers – and that they "do not receive TCP connections from untrusted sources directly when following best practices." On November 2, however, Red Hat updated the severity of its [__security advisory__](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016?ref=thestack.technology) from CVSS 8.8 to CVSS 9.8 and admitted that Red Hat Enterprise Linux (RHEL) 8, 9, 10, and its OpenShift Container Platform are “directly affected” – saying “the affected surface is broad. Systems accepting inbound TCP connections are most directly exposed.” An apparently initially sceptical Ubuntu [__said__](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432?utm_source=twitter&utm_medium=organic+social) on November 2 “our team is currently working on testing the fixes for CVE-2026-98432 for Ubuntu 22.04 LTS and newer.” It added that “to ensure stability across a wide ecosystem we perform extensive tests on more than 2,000 certified servers and devices. We will release the fixes in the updates pocket of the Ubuntu archive as soon as those tests are complete.” AWS has its advisory [__here__](https://aws.amazon.com/security/security-bulletins/2026-160-aws/?ref=thestack.technology) and notes, among its guidance, that “customers running ECS on EC2 should update the kernel on their container instances and reboot, or replace them with instances launched from the latest ECS-optimized AMI.” #### **What Anthropic says about the bug** **What Anthropic says about the bug** Anthropic says: "*The underlying vulnerability is a race condition-induced UAF bug in the kernel networking stack. The full exploitation has two key stages:* - *In the first stage, the attacker defeats KASLR remotely. It exploits the race to make the kernel read an attacker-controlled length field to copy extra bytes and send them back to the attacker, and as long as one such overread contains a kernel pointer in the reply, the attacker learns the kernel address space layout.* - *In the second stage, the attacker hijacks the control flow. It exploits the same UAF bug to overflow a buffer and overwrite a callback pointer with the address of a payload the attacker has already staged in kernel memory via an ordinary protocol feature. When the kernel invokes the callback, the payload chains a series of calls to existing kernel functions. ending with an attacker-chosen shell command running as root.* *An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution.* Red Hat commented: “Although reliably executing arbitrary code through this timing-sensitive use-after-free scenario requires precise heap control, the lack of network prerequisites and the potential for severe system instability elevate the impact above Important.”  Nobody else appears to have a working proof-of-concept yet and it has not been exploited in the wild, as *The Stack* published on November 3. The vulnerability is a prime example of the challenge for defenders and upstream software maintenance teams alike: The sheer wall of noise they face and volume of CVEs* coming through, makes it hard to separate signal from noise, and risk from bluster – not least given the implicit motivation for frontier labs to suggest that they are finding scary, novel vulnerabilities in the software ecosystem using their models. (*The Stack* does not dispute that they are; but their assessment of risk and that of an enterprise CISO with a layered defense and minimal exposure of operating systems, firewall control planes et al. to the public internet often diverge significantly.) ### **See also:** [**__Pentesters’ AI-found VMware 0days exploited__**](https://www.thestack.technology/the-pentesters-0day-vcenter-vulnerability-llm/) __Pentesters’ AI-found VMware 0days exploited__ Threat actors appear to be working on developing exploits. Security researcher Marcus Hutchins, of Wannacry kill switch fame, commented: “We've detected what appears to be a threat actor activity scanning the entire internet for exposed affected systems. He added: “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.” Confusion appears to abound about the **precise** exploit mechanism. Challengingly for defenders, without an actual POC it’s harder than ever (given the complexity of some exploits being created by frontier models) to understand the real attack path and defend against/mitigate it. Red Hat, for example, states (contrary to initial industry belief) that “multipath TCP is not a required condition for this flaw… neither the upstream fix nor the CVE record identifies it as one, and nodes in their default configuration, where MPTCP is disabled, remain affected.” Anthropic would arguably be wise to share more details for defenders. Hutchins said: “You can check if your server is running any MPTCP listeners with the following command: **sudo ss -Mlnp**” and added that a “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.” As of November 2 he said his team had seen 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.” *Working on understanding this vulnerability in more depth? We're interested in your analysis and views.* *Email ed@thestack.technology / Signal @Targett.11*