Linux Kernel TCP/IP RCE: Internet-Wide Scanning for CVE-2026-98432

The Linux kernel has a critical remote code execution flaw in the IPv4 TCP connection path, tracked as CVE-2026-98432. It is a race condition that causes a use-after-free while the kernel prepares a SYN-ACK response, and the Linux kernel CVE team rates it 9.8 under CVSS v3.1. No credentials or user interaction are required.

The fix is available in every maintained stable kernel branch. The complication is reachability: the exploit that has been demonstrated publicly requires an exposed Multipath TCP (MPTCP) listener, and MPTCP is not as rare as the flaw’s early description suggested. It is enabled by default on several distributions, including Debian, and Go 1.24 and later create MPTCP listeners by default when the kernel supports it.

That changes the exposure picture materially. Our own internet-wide measurements found approximately 2.1 million servers on port 443 reachable over MPTCP. A stricter test that completed a full TLS handshake over MPTCP found about 763,000. Neither figure proves that those hosts run vulnerable kernels, but they are exposed to the condition used in the working exploit. Threat actors are already scanning the internet for exactly these systems.

What to do, in order

1. Inventory every internet-facing Linux host and its kernel version. Start with servers that accept direct IPv4 TCP connections, then include edge appliances, container hosts, Kubernetes nodes, VPN and proxy gateways, and appliances that embed Linux.
2. Install a patched kernel and reboot. The upstream fix is in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Use your distribution’s security package where one is available. Verify the running kernel with uname -r after the reboot; installing a package is not enough.
3. Check for exposed MPTCP listeners. Run sudo ss -Mlnp. On systems where MPTCP is not required, set net.mptcp.enabled=0 and restart every application that already owns an MPTCP socket. The sysctl stops new MPTCP sockets from being created, but it does not close existing listeners.
4. If you cannot patch immediately, apply the temporary nftables mitigation that drops inbound IPv4 TCP packets carrying IP options. It blocks the demonstrated trigger but is not a fix, and it can be bypassed by traffic between containers on the same host.
5. Review logs and host state for the detection signs below, especially where an MPTCP listener was exposed before patching.

The vulnerability

How the bug works. When an IPv4 SYN carries options such as Record Route or Timestamp, the kernel copies them into an object associated with the pending connection so it can echo them in the SYN-ACK. When the handshake completes, ownership of that object moves to the new socket without copying it. A retransmitted SYN can make another CPU process the same request socket and begin building a SYN-ACK at the same time. Because request sockets are processed without the listener lock, the child socket can be created and freed while the SYN-ACK is still using the options. The options object was freed with an immediate kfree(), so the response path can read and write reclaimed kernel memory.

The upstream fix waits for an RCU grace period before freeing the options in both the child-socket and request-socket destruction paths. IPv6 is not affected by the main issue because its handshake path duplicates the options. A separate migration path in IPv6, involving CALIPSO labels, is outside the scope of this CVE.

The race is exploitable without unusual application behaviour: the attacker sends the initial SYN, retransmits it, and lets the handshake or teardown race the SYN-ACK construction. A lost race usually breaks the handshake rather than crashing the host, so an attacker can retry until the race is won.

Who is exposed

The kernel bug is not specific to MPTCP. The working exploit uses an MPTCP listener, but the vulnerable code is the ordinary IPv4 TCP path. The Go Security Team notes that systems without MPTCP listeners may still be vulnerable to similar attacks, and a kernel maintainer reviewing interim mitigations made the same point: disabling MPTCP alone is not sufficient because the bug is reachable in plain IPv4 TCP.

For the purposes of prioritization, however, MPTCP listeners are the confirmed high-value exposure. They turn a difficult kernel race into a demonstrated root-level exploit.

MPTCP is easy to miss. The Go Security Team says Go 1.24 and later enable MPTCP by default for listen sockets on Linux, and that the default can be changed with GODEBUG=multipathtcp=0 or godebug multipathtcp=0 in the main module’s go.mod. Programmatic calls to net.Dialer.SetMultipathTCP and net.ListenConfig.SetMultipathTCP override that setting. Because the behaviour is automatic, a service team may not know that its process owns an MPTCP socket.

At the system level, MPTCP availability depends on both the kernel setting and the application. Several distributions, including Debian, enable net.mptcp.enabled by default. AlmaLinux ships with it off, so the demonstrated exploit does not apply out of the box there; the ordinary IPv4 TCP flaw still does.

Internet-wide exposure and active scanning

The belief that MPTCP listeners would be rare proved wrong in practice.

A preliminary internet-wide scan of port 443 on 30 October 2026 found approximately 2,102,043 servers that completed an MPTCP connection. A deeper scan that connected to each endpoint and negotiated a full TLS session over MPTCP returned about 762,774 systems.

These are exposure measurements, not vulnerability counts. Neither scan established whether any of those hosts runs an unpatched kernel, so the numbers must not be read as “2.1 million confirmed vulnerable servers”. They do establish that the precondition for the demonstrated exploit is present on far more systems than expected.

The practical attack surface is probably closer to the larger number. A valid HTTP request is not needed to reach the vulnerable path: the trigger happens during the TCP handshake, before the application accepts the connection or parses any HTTP data. The smaller TLS-based figure measures servers that also negotiate a working encrypted session over MPTCP, which is not a requirement for the exploit.

Threat actors are already looking. By 2 November 2026, we had observed residential proxies and VPN endpoints, including servers in Russia, scanning port 443 with MPTCP-enabled connections. The scanning pattern does not send application data over port 443. Ordinary scanners do not negotiate MPTCP by default, and the traffic does not match normal HTTP or TLS client behaviour. We therefore assess this as deliberate reconnaissance for CVE-2026-98432 rather than routine inventory work.

The absence of data at the HTTP layer is a strong signal. If your proxy, WAF or network sensor records MPTCP handshakes followed by no application traffic, treat that as a high-priority lead.

Exploitation status

As of 3 November 2026:

• A working RCE exploit has been demonstrated publicly. Anthropic’s Frontier Red Team published the exploit chain with its research on 27 October. It sends packets to a Linux server with an MPTCP listener and runs arbitrary commands as root, without credentials or user interaction.
• The exploit is deliberately hard, but repeatable. The first stage uses the race to defeat KASLR by leaking a kernel pointer through an overread returned in the SYN-ACK. The second uses the same use-after-free to overflow a buffer, overwrite a callback pointer and chain existing kernel functions into a command execution primitive. Anthropic’s proof of concept took about 48 minutes to leak a kernel pointer and five more minutes to reach command execution. Because a lost race does not crash the host, an attacker can keep retrying.
• Public denial-of-service proof-of-concept code exists. It gives attackers a starting point, even where the full RCE chain is not yet available to them.
• No publicly confirmed, in-the-wild compromise. We are not aware of a published successful intrusion using this CVE. That is different from saying exploitation has not been attempted: the scanning we observed is reconnaissance for it.
• Exploit development remains demanding. The exploit must win a kernel race, defeat KASLR and build a control-flow hijack. Well-resourced adversaries have the engineering capacity to do this, and the existence of public denial-of-service code shortens the distance to a weaponised chain.

Our assessment: treat this as an emergency kernel update across internet-facing Linux hosts, not only those running MPTCP. The public exploit works against a condition that is widespread, the vulnerability is reachable during the TCP handshake, and adversaries are already enumerating targets. Hosts with exposed MPTCP listeners should be first.

If you cannot patch today

There are two useful temporary measures. Neither replaces the patched kernel.

Drop inbound IPv4 TCP packets that carry IP options

The demonstrated trigger requires a SYN with IPv4 options such as Record Route or Timestamp. Normal Internet traffic rarely uses these options. This nftables rule, published by AlmaLinux and also recommended by Ubuntu’s security team, drops those packets while leaving ordinary connections, TCP options such as timestamps and window scaling, and IPv6 traffic alone:

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Check that it is active and review the counter:

sudo nft list table ip cve_2026_98432

Important limits:

• The rule is not persistent. Make it part of your firewall configuration if you rely on it across reboots.
• Same-host container traffic can bypass it. Apply the rule in each relevant network namespace or at the container network layer.
• Do not use it where the network depends on CIPSO/NetLabel. IPv4 security labels are carried in IPv4 options, and the kernel can add them itself, in which case the rule does not cover the traffic.
• It reduces risk; it does not eliminate the flaw. It targets the demonstrated trigger, not every possible variant.

Disable MPTCP

If MPTCP is not required, turn it off:

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

This is an effective brake on the confirmed exploit path, but it comes with three caveats:

1. Existing sockets survive. The setting prevents new MPTCP sockets from being created. Restart every service that already owns one.
2. The underlying bug is in plain IPv4 TCP. Treat this as exposure reduction, not remediation.
3. Some applications need it. Verify that nothing depends on multipath operation before disabling it.

What not to rely on

The init_on_free=1 kernel boot parameter was proposed on oss-security as an additional interim measure. A kernel maintainer reviewing it concluded that it does not meaningfully mitigate this CVE: it zeroes freed slab objects, but the attacker can leak a pointer from a live neighbouring allocation rather than from the freed object’s old contents. The setting may have other hardening value, but it should not be treated as protection against CVE-2026-98432, and the same reviewer warned against carrying that claim in advisories.

Detection and verification

Find the MPTCP listeners. Run this on every internet-facing host:

sudo ss -Mlnp

The output lists listening MPTCP sockets and the processes that own them. Restart or reconfigure each service that appears if you disable MPTCP. Check containers and network namespaces separately; a process in a container can have an MPTCP listener that is invisible in the host’s default namespace.

Check the kernel and the running version. uname -r reports the kernel actually running, and the package manager may report a newer kernel that has not been booted. Compare the running version with your distribution’s fixed package. The upstream fixes are:

Distribution packages backport fixes without changing upstream version numbers, so use the vendor’s advisory as the source of truth. Debian fixed the issue in bookworm with 6.1.190-1 and trixie with 6.12.113-1; Ubuntu’s security page tracks fixes across release and flavour kernels; AlmaLinux shipped fixed builds for versions 8, 9 and 10 in its regular repositories on 2 November.

Look for the scanning and attack traffic. The most distinctive signal is a TCP handshake that negotiates MPTCP and then stops:

• MPTCP connections with no application payload. On port 443, a completed MPTCP handshake followed by no HTTP request and no TLS ClientHello is unusual and matches the reconnaissance we observed.
• SYN packets carrying IPv4 options. The trigger uses Record Route or Timestamp options in the IP header. Ordinary clients rarely send these. If your sensor can decode IP options, alert on them for inbound TCP SYN packets to listening ports.
• Repeated SYN retransmissions to the same port. The exploit races a retransmitted SYN against the handshake and teardown. A high rate of retransmissions from one source to one port, with no completed application session, deserves investigation.
• Kernel oopses, warnings and crashes. Out-of-bounds writes in ip_options_build() and ip_build_and_send_pkt() can produce a kernel oops or panic. Correlate host logs with inbound traffic to the exposed port.
• Unexpected process changes after a crash. Review child processes, new files, modified cron entries and outbound connections on any host that experienced a kernel fault around the first exposure.

Verify from outside. An MPTCP connection is observable from the network, which is what makes internet-wide scanning possible. Check whether your perimeter inventory records MPTCP capability, not only open ports and service banners. A host that looks like a normal HTTPS server from outside may be one of the reachable MPTCP endpoints.

Why the score alone will not rank this

The 9.8 score records that the impact is severe and that the attack is remote, unauthenticated and requires no user interaction. It does not tell you which of your hosts are reachable with MPTCP, which Go services opened the socket without anyone asking, or that the known exploit’s precondition is common on the public Internet.

Ranked by CVSS, every vulnerable Linux server lands in the same bucket. Ranked by exposure, kernel version and listener type, the work separates cleanly: exposed MPTCP listeners first, then every other internet-facing IPv4 Linux host, then internal systems and IPv6-only services. Our CVSS vs EPSS page develops that argument in general.

Panop’s discovery starts from a company name, finds the services you expose and fingerprints what they run. For this advisory, that turns the first step into a filter on an inventory you already have, rather than a search under time pressure. Request a scan to see where Linux servers answer on your perimeter.

Timeline

This advisory reflects public information as of 3 November 2026.