On 2 November 2026 Fortinet PSIRT published advisory FG-IR-26-188 on CVE-2026-98432, a CVSS 9.8 use-after-free in the Linux kernel’s IPv4 TCP stack. The advisory trails the news: the kernel CVE team published the CVE on 15 October, the upstream fix went in on 5 October, and fixed Red Hat kernels shipped from 1 November. Plan from the kernel timeline, not from Fortinet’s date.

The flaw follows the kernel wherever it runs: hypervisor hosts, container nodes, guest VMs. If you operate your own hosts, you have to decide an order. Below is how we reason about it, what the evidence says about exploitability, and where a filter on IP options fits while kernels roll out.

The bug sits in the plain IPv4 path

When a connection request carries IPv4 options, the kernel could free those options while another CPU was still reading them to answer a retransmitted SYN. The fix switches to kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(). The flaw has been present since Linux 4.4. Other sources name Record Route and Timestamp options as the trigger; Fortinet’s text does not.

According to Fortinet’s page, IPv6 is not affected by this first issue, but a similar migration issue exists for options set through CALIPSO, with a separate patch to follow. MPTCP is not required: the bug is in the plain TCP path, and Anthropic’s exploit used an MPTCP listener. Disabling it with net.mptcp.enabled=0 (or GODEBUG=multipathtcp=0 for Go 1.24+) narrows the conditions, as AWS describes it, but does not fix anything.

How worried to be

The scores disagree. The kernel CNA rates it 9.8; one source reports Red Hat at 5.9 because exploitation depends on winning a race, while another says Red Hat rated it Critical, so read Red Hat’s own bulletin rather than trusting either summary. Fortinet lists Known Exploited as “No”, and ThreatDefence reported no exploitation in the wild and no CISA KEV listing as of 9 November.

Public proof-of-concept code has circulated since 29 October. It covers the race and a kernel pointer leak, not code execution, and Marcus Hutchins reports MPTCP scanning from 2 November. CloudLinux could not reproduce the remote-root exploit. So this is a patch-this-cycle bug, not a reason to reboot everything tonight, but the exposed hosts should not wait for a monthly window.

A CVSS score tells you how bad the bug is. Your patch order depends on where the kernel is reachable and what sits next to it.

Kernel patching strategy: exposure first, then blast radius

We found no vendor guidance on ordering across hypervisor hosts, nodes and guests, so this is our own reasoning, built on what the sources do say.

  1. Internet-facing hosts that terminate TCP. Anyone can send them a SYN with options, so they go first. ThreatDefence then ranks MPTCP and Go 1.24+ listeners next within that group; Anthropic’s exploit used an MPTCP listener.
  2. Shared or multi-tenant container nodes. Containers share the host kernel, so a Kubernetes node kernel update is the fix; rebuilding images changes nothing. Google’s GKE bulletin, as relayed by ThreatDefence, says an unprivileged container process can trigger the bug locally. No other vendor has said this, but if it holds, a shared node ranks with the internet-facing hosts.
  3. Hypervisor hosts. The flaw is in the host’s own TCP stack, so it matters for the host’s management interfaces and any service the host exposes. KVM guests run their own kernels and guest traffic does not terminate on the host kernel, so patching a host does not patch its guests. What ranks this tier is cost: rebooting a host that carries many workloads is the most expensive reboot you schedule (our reasoning, not a vendor’s), so book its window early instead of discovering the constraint on the day.
  4. Hosts behind layer 4 passthrough, then internal hosts. Per ThreatDefence’s ranking, passthrough hosts come above purely internal machines; our reasoning is that a layer 4 passthrough does not rewrite the client’s SYN, so the options reach the host.

Exposure sets the order; blast radius breaks ties. Between two equally exposed hosts, patch first the one that carries more workloads.

The guest kernel is yours on unmanaged instances

Our Cloud instances run on KVM, and the host kernel under them is ours to patch. VPS, VDS and MEM are unmanaged, so the kernel inside the guest belongs to you: patching our hosts does not patch your guest. The same goes for Bare Metal with an operating system you installed. On a managed Bare Metal server we patch the operating system.

On MNG instances, which software the management covers is something to confirm with us for your workload; do not assume the kernel is included. For every unmanaged guest, check uname -r against the fixed versions below and schedule the reboot yourself.

Interim control: an nftables IP options filter

Red Hat and Canonical both publish the same stopgap rule, ip protocol tcp ip hdrlength > 5 counter drop, which drops TCP packets whose IP header is longer than the 5-word minimum, meaning they carry options. The vendors publish only that rule. The table and chain around it below are our own wrapper, so test it before you use it.

table ip ipopts {
  chain input {
    type filter hook input priority 0; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Load it first without drop, so the counter shows whether anything you run depends on IP options. Red Hat warns it can disrupt workloads that rely on them, and RFF warns it should not be used on CIPSO-labelled networks. Red Hat, Canonical and AWS all describe it as reducing exposure, not preventing exploitation. It buys time; it is not a patch.

The same match at the network edge, on a firewall or cloud load balancer that drops IPv4 packets with options, would protect every host behind it. That is vendor-described only. We operate the network and the transit ourselves at all four sites, so the placement is ours to make, and we would test it on our own edge before relying on it. Coverage is the hard part: AMS1 has six carrier uplinks and MUN1 has eight, and if a filter sits per uplink rather than on the routers, partial coverage is no coverage (that is our reasoning, not a vendor’s).

If you run Fortinet products, Fortinet lists a virtual patch, Linux.Kernel.tcp_v4_syn_recv_sock.Use.After.Free., in FMWP db update 26.113, and the 7 November revision added IPS package information. Fortinet also lists about 55 of its products as still under investigation, including FortiOS and FortiGate Cloud.

Fixed kernels and what is still open

  • Upstream: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.
  • RHEL 9.8: 5.14.0-687.64.1.el9_8. RHEL 10.2: 6.12.0-211.72.1.el10_2.
  • Ubuntu 24.04: 6.8.0-149.149. Per ThreatDefence, fixes for 22.04, 24.04 and 26.04 reached -updates on 5–6 November, but there was no Ubuntu Security Notice and nothing in -security as of 9 November. A host that tracks only -security will not see it yet.
  • Proxmox VE 9: proxmox-kernel-7.0.14-25-pve or later (PSA-2026-00080-1).
  • AWS bulletin 2026-160-AWS covers Amazon Linux, EKS and Bottlerocket. GKE Ubuntu node images were not yet fixed.

ThreatDefence found no Red Hat kpatch and no Ubuntu Livepatch notice. TuxCare KernelCare, SUSE live patches and Oracle Ksplice (UEK only) exist if a reboot is expensive. Recheck distro status before you act on any of this: the tracker is moving.

Sources