CVE-2026-98432 Checker

How to use

1. Read the first two sections below to understand what the bug is and which servers can be reached by it.
2. On the server, run the five read-only commands next to the box (or copy them all at once) and paste the output.
3. Read the verdict: Exposed, Vulnerable, Patched kernel or Not affected. The table under it shows what the checker found.
4. Install the fixed kernel if your distribution has one and reboot. Until it does, turn off multipath TCP and request migration with the commands under the result.

What causes CVE-2026-98432, in plain words

Every TCP connection starts with a three-step handshake: the client sends SYN, the server answers SYN-ACK, the client replies ACK. Between the SYN and the final ACK the kernel keeps a small placeholder for the half-open connection, called a request socket. If the client's SYN carried IPv4 options (extra fields such as Record Route or Timestamp), the kernel stores a copy of them with that placeholder, because the SYN-ACK has to echo them back.

When the ACK arrives, the kernel turns the placeholder into a full connection, tcp_v4_syn_recv_sock() in the source. The bug: it hands the full connection the same block of option memory instead of its own copy. Two objects now point at one block. When the full connection is closed, inet_sock_destruct() frees the block at once with a plain kfree().

Freeing would be harmless if nobody else could still be reading the block. But the placeholder lives in a shared lookup table that other CPU cores read without taking a lock. If the client resends its SYN at just the wrong moment, another core is busy resending the SYN-ACK and reads the options inside ip_options_build() exactly while the block is being freed. That is a use-after-free: the kernel reads, and may write, memory that already belongs to something else.

Think of a coat check that gives the same ticket to two people. When one of them leaves, the attendant throws the ticket away, while the other is still walking to the counter with it.

Why it is rated so high

Three things make this worse than a typical kernel bug. It is reached from the network, before any login: the attacker only has to open TCP connections to a listening port. A lost race does not crash the server, it only fails that one handshake, so an attacker can retry for as long as it takes; Anthropic's proof of concept needed 48 minutes of retries to leak a kernel address and five more to run a command as root. And the code has been there since 2015, so almost every Linux server in use carries it.

Scores differ because winning the race takes timing. The kernel's own CVE team rates it 9.8 (attack complexity low). Red Hat rates it 8.1, scoring the complexity as high, and Ubuntu lists it as High priority. Every scorer agrees on remote, no login, no user action.

Where MPTCP comes in

Multipath TCP (MPTCP) lets one connection use several network paths at once, for example Wi-Fi and mobile data. On Linux it is opt-in: a program has to ask for an MPTCP socket, and ss -Mltn lists the ones listening. Anthropic's Frontier Red Team wrote on October 27, 2026 that its exploit lets a remote attacker run commands as root on Linux servers with a multipath TCP listener, without any credentials or user interaction.

The bug itself is in plain IPv4 TCP code. Neither the CVE record nor the fix mentions MPTCP, and Anthropic has not said whether servers without an MPTCP listener can be taken over. So read it this way: an MPTCP listener is the proven path to root, and every unpatched server still runs the faulty code.

Who is affected

Linux kernels from 4.4 (2015) until the fix. The flaw came with commit 079096f103fa, which put half-open connections into the shared lookup table. IPv6 handshakes are not affected by the main issue, because tcp_v6_syn_recv_sock() copies the options. A second path to the same memory exists when request migration is on (net.ipv4.tcp_migrate_req=1, or a BPF reuseport program that migrates requests).

Desktops and laptops run the same kernel code, but the risk is for machines that accept connections from untrusted networks: web servers, load balancers, VPN and mail gateways, and anything with an open port on the internet. Containers share the host kernel, so patch the host, not the image.

Ways to protect a server

Patch: the only real fix is a kernel with the change "ipv4: free inet_opt and ireq_opt after an RCU grace period". It frees the option memory with kfree_rcu(), which waits until every core has finished reading before the memory is reused. Install it and reboot; a kernel that is installed but not running protects nothing. Livepatch services can apply it without a reboot once they cover this CVE.

Remove the proven path: set net.mptcp.enabled to 0 so programs can no longer open MPTCP sockets, then restart any service that was listening with MPTCP. Most programs fall back to plain TCP. Set net.ipv4.tcp_migrate_req to 0 (the default) to close the second path.

Shrink who can reach you: an attacker needs to complete many handshakes against an open port. Ports that only partners or your office use should be allowed only from their addresses. Per-source limits on new connections slow a retry-heavy attack down, though they do not stop it.

Watch for it: a won race usually leaves no trace, but a crash does. Kernel log lines naming ip_options_build or ip_build_and_send_pkt (journalctl -k), or a burst of SYNs with IPv4 options from one source, deserve a closer look. None of these steps replace the patch, and no vendor has confirmed them as a full workaround.

Timeline

Frequently asked questions