CVE-2026-98432: What to Do While Kernel Patches Arrive

Sooner or later, CVE-2026-98432 will hit your timeline. If you run Linux systems that accept IPv4 TCP connections, check your patch status now.

The bug is a use-after-free in the kernel’s IPv4 TCP handshake. Anthropic says it built a remote exploit that ran commands as root on a server with a multipath TCP (MPTCP) listener, without credentials. This happens while the kernel is setting up a connection, before the application gets a request or has a chance to authenticate anyone.

The kernel CVE record gives the mechanics. Linux keeps a small request socket during the handshake. When the connection completes, it moves the request’s IPv4 options to the new socket without copying them. Another CPU can be handling a retransmitted SYN for that same request and building a SYN-ACK using those options. If the new socket is destroyed at the wrong moment, the options are freed while that second CPU is still reading them. The fix delays freeing the memory until those readers have finished.

Patches will arrive at different times

Patch status checked: 30 October 2026, 09:40:46 NZDT (UTC+13). This is the time the advisories were checked, not a claim that every package became available at that second. Vendor pages can change after this snapshot.

The Linux kernel CVE record lists these as the first fixed releases in each upstream branch. Release dates come from kernel.org and its 5.x, 6.x and 7.x archives; they do not give a reliable release time for every branch.

Those numbers are for upstream Linux. A distribution may backport the fix without changing its kernel’s base version. Here is the package status in selected vendor advisories at the check time:

The published times above are advisory timestamps where the vendor supplies one. They are not precise package mirror arrival times. Ubuntu’s listed versions remain work in progress, so do not treat those numbers as released fixes. Check the advisory for the exact kernel package you run, install its fixed build, then confirm that build is running after a reboot.

The same applies to appliances from Fortinet, Check Point, Cisco and others. Their exposure and release dates depend on the product and firmware. A Linux kernel under the hood is a reason to check the vendor’s advisory, not proof that every model is affected. A package update inside a container also leaves its host kernel untouched. Watch those advisories over the next few days.

MPTCP and KASLR are not your patch plan

Anthropic demonstrated the exploit with an MPTCP listener. There is a difference between a kernel that supports MPTCP and a service that actually listens with it. Check the listeners you expose. Disabling MPTCP where it is unused narrows the demonstrated path, but it does not establish that ordinary TCP listeners are safe: the CVE record describes a race in IPv4 TCP request handling beyond the MPTCP example.

Kernel address space layout randomisation (KASLR) adds work for an attacker, but Anthropic’s exploit defeated it. In its lab run, leaking a kernel pointer took about 48 minutes; reaching root command execution took another five. A failed race can simply fail the handshake, leaving room to retry. The timing of one lab run is not a safe timeout to build a defence around. KASLR buys time, not immunity.

Filter before the vulnerable TCP path

Host firewall rules can help while a fixed build is unavailable. For traffic delivered to a local service, the Netfilter PREROUTING and INPUT hooks run before the local TCP listener handles the packet. A narrow source allowlist or rate limit at those hooks reduces who can attempt the race and how often. Netfilter documents that packet path. Check where your rules actually sit in the packet path, especially if another rule accepts traffic first. Rate limiting makes repeated attempts harder; it does not remove the underlying race.

The kernel CVE’s scoring notes describe an attacker sending a SYN with IPv4 Record Route or Timestamp options. These are options in the IPv4 header, not TCP options. Ordinary TCP options such as MSS and TCP timestamps are different; filtering every packet with a TCP option would cause real problems. Where your services do not need IPv4 header options, dropping option-bearing IPv4 SYNs at the host or network edge is a reasonable interim measure.

In nftables, ip hdrlength > 5 matches an IPv4 header with options; combine that with a TCP SYN match in the relevant ingress chain. Check for legitimate use before deploying the rule, and verify that it counts or drops the packets you intended. This targets the documented path. It has not been shown to cover every possible exploit path, so keep the kernel update at the top of the list.

The exploit Anthropic described concerns IPv4. The kernel record says IPv6 is unaffected by the primary race, but it also notes a separate IPv6 request-migration issue involving CALIPSO. That issue needs its own fix.

Patch where a fixed build exists. On the rest, check exposed IPv4 listeners, apply ingress controls you can verify, and keep watching the advisory for your actual product.