---
title: "Linux Kernel TCP/IP RCE: Internet-Wide Scanning for CVE-2026-98432"
description: "CVE-2026-98432 is a critical use-after-free in the Linux kernel's IPv4 TCP path. Threat actors are already scanning for exposed MPTCP listeners."
url: https://panop.io/threat-intelligence/cve-2026-98432-linux-kernel-mptcp-rce/
---

Vulnerability advisory Severity: Critical 3 November 2026 [Panop Research](https://panop.io/company)

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

A race condition in the Linux kernel's IPv4 TCP handling can let a remote attacker run code as root without credentials. The working exploit needs an MPTCP listener, but MPTCP is enabled by default on several distributions and in Go 1.24 and later. Patched kernels are available: update every internet-facing Linux host now, and verify that no MPTCP listeners remain exposed.

CVE

[CVE-2026-98432](https://www.cve.org/CVERecord?id=CVE-2026-98432)

CVSS v4.0

9.8

Affected

Linux 4.4 through unpatched maintained kernels, especially servers exposing MPTCP listeners

Fixed in

5.10.272 · 5.15.223 · 6.1.190 · 6.6.159 · 6.12.113 · 6.18.56 · 7.2.10 · 7.3

Status

Patches available · active scanning detected

On this page

1. [What to do, in order](#what-to-do-in-order)
2. [The vulnerability](#the-vulnerability)
3. [Who is exposed](#who-is-exposed)
4. [Internet-wide exposure and active scanning](#internet-wide-exposure-and-active-scanning)
5. [Exploitation status](#exploitation-status)
6. [If you cannot patch today](#if-you-cannot-patch-today)
7. [Detection and verification](#detection-and-verification)
8. [Why the score alone will not rank this](#why-the-score-alone-will-not-rank-this)
9. [Timeline](#timeline)

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](#if-you-cannot-patch-today) 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](#detection-and-verification) below, especially where an MPTCP listener was exposed before patching.

## The vulnerability

|  | CVE-2026-98432 |
| --- | --- |
| **Class** | Race condition leading to a use-after-free in the IPv4 TCP path (CWE-416) |
| **Component** | `net/ipv4/af_inet.c` and `net/ipv4/tcp_ipv4.c` in the Linux kernel |
| **Trigger** | An IPv4 SYN carrying IP options, sent to a listening IPv4 TCP port, raced against a retransmitted SYN and socket teardown |
| **Impact** | Kernel heap information disclosure, out-of-bounds writes, denial of service and, as demonstrated, remote code execution as root |
| **CVSS v3.1** | 9.8 (Linux kernel CVE team) |
| **Upstream fix** | Commit `e3f33b0a1d89`, “ipv4: free inet\_opt and ireq\_opt after an RCU grace period” |
| **Fixed branches** | 5.10.272 · 5.15.223 · 6.1.190 · 6.6.159 · 6.12.113 · 6.18.56 · 7.2.10 · 7.3 |

**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.

| Stack or configuration | What is known | Priority |
| --- | --- | --- |
| **Linux with an exposed MPTCP listener** | Demonstrated remote code execution as root by Anthropic’s research team; the exploit defeats KASLR, then hijacks kernel control flow through the same use-after-free | Patch and remove the listener now |
| **Go 1.24 and later services** | Go enables MPTCP by default for listen sockets on Linux when the kernel has it enabled. This includes Caddy and many other Go-based servers and proxies | Patch; verify the listener inventory |
| **Debian and other distributions with MPTCP enabled by default** | The listener condition is much more common than early reporting suggested | Patch; disable MPTCP if unused |
| **Any Linux server accepting direct IPv4 TCP connections** | The underlying use-after-free is in the common IPv4 TCP path; exploit variants that do not require MPTCP are considered plausible | Patch all internet-facing hosts |
| **IPv6-only listeners** | The main issue does not affect IPv6, whose handshake path duplicates the options | Lower priority, but the host may also serve IPv4 |

**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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

| Branch | First fixed version |
| --- | --- |
| 5.10 LTS | 5.10.272 |
| 5.15 LTS | 5.15.223 |
| 6.1 LTS | 6.1.190 |
| 6.6 LTS | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 | 7.3 |

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](https://panop.io/cvss-vs-epss/) page develops that argument in general.

Panop’s [discovery](https://panop.io/discovery-product/) 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](https://panop.io/trial/) to see where Linux servers answer on your perimeter.

## Timeline

| Date | Event |
| --- | --- |
| 25 Sep 2026 | CVE-2026-98432 reserved. |
| 15 Oct 2026 | CVE published by the Linux kernel CVE team with a CVSS v3.1 score of 9.8. |
| 27 Oct 2026 | Anthropic publishes the remote code execution exploit chain for Linux servers with MPTCP listeners, including the KASLR-defeat and control-flow-hijack stages. |
| 29 Oct 2026 | The Go Security Team warns Go 1.24 and later programs about the default MPTCP listener behaviour and recommends upgrading the kernel. |
| 30 Oct 2026 | AlmaLinux publishes interim nftables and MPTCP mitigations, then releases patched kernels. Our preliminary internet-wide port 443 scan finds about 2.1 million MPTCP-reachable servers. |
| 31 Oct 2026 | `init_on_free=1` is proposed on oss-security as an additional interim mitigation; a kernel maintainer subsequently advises against treating it as protection for this CVE. |
| 2 Nov 2026 | AlmaLinux moves the fix into its regular production repositories. We observe residential proxies and VPN endpoints scanning port 443 with MPTCP connections and no application data. |
| 3 Nov 2026 | Panop Research publishes this advisory. |

This advisory reflects public information as of 3 November 2026.

## Sources

1. [CVE-2026-98432: free inet\_opt and ireq\_opt after an RCU grace period](https://www.cve.org/CVERecord?id=CVE-2026-98432) Linux kernel CVE team
2. [Discovering and exploiting vulnerabilities in critical, real-world software with Claude, 27 October 2026](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude) Anthropic Frontier Red Team
3. [CVE-2026-98432: Patched kernels released, 30 October 2026 (updated 2 November)](https://almalinux.org/blog/2026-10-30-cve-2026-98432/) AlmaLinux
4. [CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432) Ubuntu Security
5. [CVE-2026-98432](https://security-tracker.debian.org/tracker/CVE-2026-98432) Debian Security Tracker
6. [Protecting against CVE-2026-98432 when using Go programs, 29 October 2026](https://www.openwall.com/lists/oss-security/2026/10/30/1) Go Security Team
7. [CVE-2026-98432: init\_on\_free=1 as an additional interim mitigation, 31 October 2026](https://www.openwall.com/lists/oss-security/2026/10/31/5) oss-security
8. [Re: CVE-2026-98432: init\_on\_free=1 as an additional interim mitigation, 2 November 2026](https://www.openwall.com/lists/oss-security/2026/11/03/1) oss-security

About the author

[Panop Research](https://panop.io/company)

Security research team, Panop SA

Panop Research is the security research function of Panop SA, a Swiss exposure management company founded in July 2024 by three practitioners with nearly twenty years each inside large international organisations. It publishes analysis built on primary public datasets, with every figure attributed and linked to the publisher that produced it.

- [LinkedIn](https://www.linkedin.com/company/panop-io)

[← Back to threat intelligence](https://panop.io/threat-intelligence/)

Panop discovers your internet-facing services and fingerprints what they run. Find out where Linux servers answer on your perimeter.

[Request a scan](https://panop.io/trial)

[All advisories →](https://panop.io/threat-intelligence/)