Linux kernel TCP use-after-free CVE-2026-98432 threatens unauthenticated remote takeover

A use-after-free in the TCP handshake

Linux distributors are urging operators to patch a use-after-free vulnerability in the kernel's IPv4 TCP connection setup. Tracked as CVE-2026-98432, the flaw can be triggered by a remote attacker with no credentials, and vendors say it can lead to remote code execution, according to a detailed advisory published on dev.to by security researcher Kunal Vohra. The bug has been in the kernel since Linux 4.4, which puts nearly every supported distribution kernel in range. Any server exposing an IPv4 TCP port — a website, an API, SSH — should be treated as affected until its kernel has been checked.

How the flaw works

According to the write-up, the root cause is a race condition in how the kernel transfers IP options from an incoming connection request to the newly created socket. When a server accepts an IPv4 TCP connection, the kernel hands the request's IP options to the child socket without copying them first. If the client retransmits its connection request at exactly the wrong moment, the kernel can read those options after they have already been freed. The upstream fix, merged on 5 October 2026, delays the free until it is safe.

The trigger is a TCP connection request carrying IPv4 Record Route or Timestamp options, aimed at any listening port. No login and no user interaction are needed. The main flaw affects IPv4 only; a related IPv6 migration problem is being handled separately.

Severity is rated differently, but nobody doubts the bug

The CVSS scores vary by vendor: the kernel CVE team and Ubuntu assign 9.8 (Critical), Oracle, SUSE and Amazon's CVE page use 8.1, and Red Hat, which initially scored it lower, now also treats it as Critical. The dev.to guide notes the spread reflects how hard the race is to win, not disagreement over whether the flaw is real.

Anthropic, whose researcher is credited in the kernel fix, published research on 27 October 2026 describing an exploit its model wrote for one specific configuration: a server running a Multipath TCP listener. The reported chain took 48 minutes to leak a kernel address and roughly five more to execute commands as root. The exploit code was not released, and as of 3 November 2026 no vendor or CERT had reported attacks in the wild.

Patch status by distribution

The remedy is the same everywhere — install the vendor's patched kernel, reboot, and verify the running version — but availability differs. Status as reported between 1 and 3 November 2026:

• Debian: fixed kernels are in the security repositories — bookworm in linux 6.1.190-1 (with a backported 6.12 build available), trixie in 6.12.113-1 or later.
• Amazon Linux: advisories dated 24–30 October 2026 cover Amazon Linux 2023 and 2, the 5.4, 5.10 and 5.15 extras, and the 6.12 and 6.18 kernel packages.
• Red Hat family: fixed kernels for RHEL 8.10, 9.8 and 10.2 shipped on 1 November 2026, and the errata require a reboot; RHEL 7 is unaffected. Oracle's UEK kernels were fixed on 16 October, with Rocky and Alma expected to follow Red Hat's builds.
• Ubuntu: the outlier. As of Canonical's 2 November post, fixed kernels for 22.04, 24.04 and 26.04 LTS sit in the -proposed pocket pending qualification testing, while 26.10 has its fix. Older LTS releases need Ubuntu Pro, and cloud, FIPS and real-time flavours are still in progress.

Two traps when checking exposure

The guide flags two common mistakes. First, a fixed kernel package that has been installed does nothing until the machine is rebooted into it; uname -r shows what is actually running, not what is on disk. Second, Red Hat's suggestion to look for Multipath TCP listeners with ss -Mlnp matches only the configuration Anthropic exploited — having no MPTCP listeners does not mean a host is safe, because the bug sits in the ordinary IPv4 TCP path.

Containers do not change the picture, since they share the host kernel, so the host is what needs patching. Managed platforms where operators never touch a kernel, such as serverless or most PaaS offerings, remain the provider's responsibility.

Why it matters

This is a pre-authentication flaw in code every Linux server exercises, with a documented research path from an open port to root in under an hour. The only complete fix is a kernel update plus a reboot, an operation many small teams routinely defer, and Ubuntu — the distribution many startups run — still lacks a fix in its normal update channel. Between the CVSS disagreement and the headline-grabbing exploit research, the practical takeaway is simpler than the debate: inventory every Linux host, including databases, bastions, CI runners and Kubernetes nodes, patch what has a fixed kernel available, and treat anything left unpatched with an open IPv4 port as exposed.