A Linux update can be installed on disk while the vulnerable kernel is still running in memory. CVE-2026-98432 makes that familiar reboot gap unusually important: a remote attacker can reach the bug through IPv4 TCP, and Anthropic demonstrated a path from a Multipath TCP listener to commands running as root.

The useful response is not to panic over a 9.8 score or assume every Linux machine is already compromised. Identify exposed systems, install the kernel supplied by the distribution, reboot into it, and verify the kernel that is actually running.

TL;DR

  • CVE-2026-98432 is a use-after-free race in the Linux kernel’s IPv4 TCP connection handling.
  • A remote attacker does not need an account, but must be able to reach a listening TCP service and win a timing race with specially crafted traffic.
  • Anthropic demonstrated root command execution against a server with a Multipath TCP (MPTCP) listener. Vendors also warn about crashes and possible memory corruption; public evidence does not show that every ordinary TCP service is equally exploitable for root access.
  • Upstream stable kernels contain the fix, but distribution users should install their vendor’s package rather than compare version numbers or patch the kernel manually.
  • Installing the package is not enough. Reboot, confirm the running kernel, and investigate unexpected crashes or network activity on exposed systems.

What the Bug Means in Plain Language

When a client starts a TCP connection, the Linux kernel temporarily stores information needed to finish the handshake. Two CPU cores can process related parts of that connection at nearly the same time. In the vulnerable path, one core can free stored IPv4 options while another core is still reading them.

That is a use-after-free: the kernel continues using a piece of memory after declaring it available for reuse. The immediate result may be a failed connection or kernel crash. If an attacker can carefully control what replaces the freed memory, the same mistake can become an information leak, memory corruption, or code execution.

Anthropic’s proof of concept used the race twice. It first leaked a kernel address to defeat address randomization, then redirected kernel control flow to execute a chosen shell command as root. The test took about 48 minutes to obtain the address and another five minutes to reach command execution. Losing the race generally failed only that connection attempt, so the attacker could keep trying.

This distinction matters: the root exploit is real, but its published precondition was an MPTCP listener. The underlying kernel bug is in IPv4 TCP and is not described by the kernel project as MPTCP-only. Treat MPTCP as a demonstrated exploit route, not as the entire vulnerable population.

Which Systems Deserve Priority

Prioritize systems that accept untrusted IPv4 TCP connections: public web servers, reverse proxies, VPN gateways, load balancers, Kubernetes nodes, exposed application servers, and any host running Go network services that may use MPTCP.

MPTCP allows one logical connection to use more than one network path. Recent Go releases may request it automatically for listeners when the operating system supports it. An administrator may therefore have an MPTCP listener without deliberately designing an MPTCP service.

Useful inventory commands are:

Terminal window
uname -r
ss -ltnp
ss -M -ltnp
sysctl net.mptcp.enabled

uname -r reports the kernel currently in memory. The first ss command lists ordinary TCP listeners; the MPTCP form asks a recent iproute2 build for MPTCP sockets. The sysctl value shows whether MPTCP is enabled, but an enabled feature alone does not prove that a vulnerable listener exists. Run socket inventory with the privileges your monitoring process normally has; otherwise process names may be hidden.

Do not use a public exploit to “test” production. A failed attempt can still crash a kernel, and successful exploitation crosses into full host compromise.

Why Version Checks Are Easy to Misread

The fix is present upstream in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3, and later releases on those branches. Those numbers help people building upstream kernels, but they are not a universal pass/fail test.

Enterprise distributions often backport a security fix while retaining an older-looking kernel version. Conversely, a package manager can show a fixed package installed while uname -r still reports the vulnerable kernel loaded before the reboot. Use the advisory and package status from the distribution that built the kernel.

As of October 30, Debian has fixed packages for supported Debian 12 and 13 kernels. Arch’s standard linux package is newer than the fixed 7.2.10 upstream release. Ubuntu still lists several supported kernels as vulnerable or work in progress. Vendor status can change quickly, so verify it again immediately before deployment.

What You Can Do Today

  1. Build an exposure list. Record the running kernel, distribution package, public IPv4 listeners, MPTCP status, workload owner, and whether the host can be rebooted promptly. Start with internet-facing and privileged infrastructure.

  2. Use the distribution’s normal full-update path. On Arch or CachyOS, sudo pacman -Syu keeps kernel, modules, and user-space packages in a supported combination. On Debian or Ubuntu, use the normal APT security-update process; on RHEL-family systems, use the vendor-supported DNF or lifecycle tooling. Do not cherry-pick one upstream commit into a production distribution kernel unless your organization already maintains and tests its own kernels.

  3. Reboot and verify. After the approved maintenance window, run:

    Terminal window
    uname -r
    systemctl --failed
    journalctl -k -b -p warning

    The first command confirms the kernel that booted. The next two reveal failed services and kernel warnings from the current boot. Compare the result with the distribution advisory, not only the upstream version table.

  4. Reduce reachability while a fix is unavailable. Place unnecessary listeners behind a VPN, firewall, or trusted load balancer; remove abandoned services; and restrict management interfaces to known networks. This reduces who can send attack traffic but does not repair the kernel.

  5. Treat MPTCP disabling as a temporary, incomplete measure. The Go team documents GODEBUG=multipathtcp=0 for disabling Go’s default MPTCP behavior per program. It can reduce the demonstrated route, but one overlooked listener remains exposed and the underlying bug is not MPTCP-specific. Test the setting and keep the kernel upgrade as the closure condition.

  6. Investigate suspicious hosts before returning them to service. Repeated kernel crashes, unexplained listener failures, unusual inbound traffic carrying IPv4 options, or subsequent root-level processes justify isolation and evidence preservation. A clean reboot after patching prevents another trigger; it does not remove persistence or stolen credentials from an earlier compromise.

The closure metric is simple: every in-scope system is running a vendor-confirmed fixed kernel, and the highest-risk listeners have been checked for signs of prior exploitation.

Sources