Linux TCP flaw CVE-2026-98432: patch status after five weeks – and what the wait has taught

As of 14 November 2026. First published 1 November; updated with the kernels from Red Hat, Ubuntu, SUSE SP7 and OpenShift, the public PoC and live patches. The linked vendor pages remain authoritative.

What has changed since the first version

• Red Hat shipped kernels for RHEL 8, 9 and 10 on 1 November; AlmaLinux, Rocky and Oracle followed. OpenShift (RHEL CoreOS) caught up between 9 and 11 November for the maintained 4.x lines and 5.0.
• Ubuntu moved the kernels for 22.04, 24.04, 26.04 and 26.10 into -updates on 6 November and published the USNs on 10 November (USN-9018-1, USN-9022-1, USN-9027-1). HWE and cloud kernels partly later; 24.04 with HWE 6.17 was still unfixed on 9 November.
• SUSE closed SLES 15 SP7 and SL Micro 6.0 and 6.1 on 4 November.
• Since 4 November, public proof-of-concept code for the race condition and the kernel address leak has been available; suspicious scanning on port 443 was reported in parallel. A working root exploit is still not public, and as far as we can tell the CVE is not in CISA’s KEV catalogue.
• Live patches without reboot are now available for RHEL 8 and 10, AlmaLinux, Rocky, Oracle, Amazon Linux 2 and, for the first time, Ubuntu 26.04.

What it is about

CVE-2026-98432 is a race condition in the establishment of new IPv4 TCP connections. The kernel hands the IP options of a pending connection request to the new socket without copying them. If that socket is freed while another CPU is still using the options for a repeated connection request, the kernel accesses already freed memory (use-after-free). IPv6 is not affected because the kernel copies the options there.

The bug has been in the code since Linux 4.4. The fix (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) was merged on 5 October, the CVE published on 15 October. The kernel fix credits Anthropic researcher Xinyang Ge as the reporter.

The flaw drew attention through an Anthropic publication on 27 October: the AI model Claude is said to have written a working exploit with which an attacker without credentials can execute commands as root on servers with a Multipath TCP (MPTCP) listener. Anthropic has not published exploit code, kernel version or test configuration. No attacks in the wild are known so far.

Why the ratings diverge so widely

The difference lies almost entirely in attack complexity. The kernel team rates it low because both sides of the race are triggered by the attacker. SUSE, Oracle and Amazon rate it high because the race is hard to win. Anthropic reports that a lost race only makes the individual connection attempt fail: in testing, leaking a kernel address took 48 minutes, command execution a further 5 minutes. Red Hat raised its rating to Critical on 30 October and published a dedicated security bulletin (RHSB-2026-016).

For prioritisation this means: handle internet-reachable Linux servers with TCP services first, regardless of which score your scanner shows.

Patch status

Proxmox VE: According to an analysis in the Proxmox forum, PVE kernel 7.0.14-25 contains the fix: on 17 October Proxmox bumped the Ubuntu source to Ubuntu-7.0.0-43.43i1, exactly the Ubuntu version Ubuntu lists as fixed. Anyone running Proxmox on the 7.0 kernel series should have at least 7.0.14-25 installed and booted.

Own kernels: The fix is included in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel CVE team recommends moving to the current stable release rather than cherry-picking the patch.

Checking your own systems

1. Check the running kernel, not just the installed package. A kernel update only takes effect after a reboot – or after an applied live patch.

   uname -r
   

   On Debian/Ubuntu also apt list --installed 'linux-image*', on RHEL/SUSE/Oracle rpm -q kernel (or kernel-default, kernel-uek), on Proxmox pveversion -v | grep kernel. Live patch status: kpatch list or canonical-livepatch status.
2. Find MPTCP listeners. The attack path Anthropic describes requires an MPTCP listener:

   ss -Mltnp
   

   Beware of Go services: since Go 1.24, Go programs open listeners with MPTCP by default (according to the Go Security Team). Anyone running Go-based services often has MPTCP listeners without knowing it.
3. Assess reachability. Internet-reachable TCP services first, internal systems after.
4. In the SIEM: run the Wazuh vulnerability detector against the distribution feeds and list every host whose running kernel is below the fix version; check egress and firewall logs for clusters of short-lived TCP connections with IP options – the pattern of a race attempt is many failed connection setups from the same source.

Interim measures while no kernel is available

None of these replaces the patch.

Filter IP options (Red Hat, RHSB-2026-016). Red Hat recommends dropping incoming IPv4 TCP packets with IP options. File cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Remove after the kernel update: sudo nft delete table inet cve_2026_98432. IP options are rare in normal traffic; Red Hat nevertheless advises testing the rule against your own traffic first. The same rule can be set on an upstream OPNsense for whole segments.

Disable MPTCP. This closes only the path Anthropic demonstrated. The Go Security Team stresses that the bug itself does not depend on MPTCP and that systems without MPTCP listeners may be attackable in a similar way. For Go programs: GODEBUG=multipathtcp=0 in the service’s environment. System-wide, sysctl -w net.mptcp.enabled=0 prevents new MPTCP sockets from being created; already running services must be restarted afterwards.

NIS2 perspective

The spread from 5.9 to 9.8 shows why a patch process must not hinge on the score alone. Document for affected systems which rating you base your decision on, which systems are reachable from the network and which interim measure applies until the kernel update. That is exactly the traceable risk assessment Article 21 of NIS2 requires for vulnerability management.

The second lesson is the timeline: from the kernel fix on 5 October to the last major distribution kernel on 10 November, five weeks passed in which the flaw was publicly described. Anyone who had set the nftables rule and checked MPTCP listeners during that time could wait. Anyone who only waited for the package was exposed for five weeks.

We maintain the current status, all sources and the vendors’ ratings on the CVE page.