CVE-2026-98432: Responding to the Linux Kernel TCP Use-After-Free

On October 15, 2026, the Linux kernel CNA published CVE-2026-98432, a race condition in the kernel’s IPv4 TCP handshake code that leads to a use-after-free, rated CVSS 9.8. A remote attacker with no credentials can trigger it on any unpatched host that accepts IPv4 TCP connections. Anthropic’s Frontier Red Team has built a working exploit that runs commands as root on servers with a multipath TCP (MPTCP) listener, and Red Hat raised its rating to Critical on October 30.

This post explains how the flaw works, which network paths make a host exposed, what it means for Kubernetes, and what to do while distribution patches roll out.

What Happened

When Linux accepts a TCP connection, it tracks the half-open handshake in a lightweight request socket and creates a full socket once the handshake completes. If the client’s SYN carried IPv4 options such as Record Route or Timestamp, the kernel saves them so it can echo them in its replies.

In tcp_v4_syn_recv_sock(), the kernel handed those saved options to the new child socket without copying them, then freed them with a plain kfree() when the socket was destroyed. Meanwhile, another CPU handling a retransmitted SYN for the same connection could still be reading that memory to build a SYNACK. This is a race condition: if the free lands while the other CPU is still reading, the kernel accesses memory it has already released, which is the use-after-free. Averlon’s vulnerability research notes a second path to the same freed memory when request sockets migrate between listeners, which happens when net.ipv4.tcp_migrate_req=1 is set or a BPF program selects the socket. IPv6 is not affected by the main issue, because tcp_v6_syn_recv_sock() duplicates the options.

The fix, written by Eric Dumazet, is a four-line change that replaces kfree() with kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(), so the memory is not released until every reader has finished with it. Xinyang Ge of Anthropic reported the bug.

• October 1: Fix posted to the kernel networking list.
• October 11 to 15: Fixed stable kernels released and CVE published.
• October 27: Anthropic describes its exploit publicly, without releasing it.
• October 30: The Go Security Team flags that Go 1.24 and later open MPTCP listeners by default. Red Hat raises the rating to Critical.
• November 1: Red Hat ships fixed RHEL 8, 9 and 10 kernels. Ubuntu has not yet published a fix.

How Large Is the Exposure

Every Linux kernel from 4.4 onward that lacks the fix is affected, which covers close to a decade of releases. The vulnerable code runs during the TCP handshake, before any application sees the connection, so the language and authentication of the listening service do not matter. Containers run on the host’s kernel, so rebuilding images does not help, and image scanners will not report this CVE because images do not contain the running kernel. The host has to be patched.

The race condition is practical to win because a failed attempt only drops the handshake and does not crash the system, so an attacker can keep retrying. According to Atlasum’s analysis, Anthropic’s exploit took 48 minutes to leak a kernel pointer and another five minutes to reach command execution. Services built with Go 1.24 or later are candidates for the highest exposure, since Go made MPTCP the default for listeners, but build settings and GODEBUG can change that, so verify listener state rather than assume it.

Anthropic has not published its exploit, but by November 1 at least 41 GitHub repositories referenced the CVE, and seven of them claimed race triggers or proofs of concept. The flaw is not yet in CISA’s Known Exploited Vulnerabilities catalog.

Applicability: Which Network Paths Reach the Kernel

For most hosts, exploitation requires an attacker’s IPv4 TCP SYN to reach the kernel with its IP options still attached. Patch status tells you which kernels are vulnerable; the network path tells you which of them an attacker can actually reach. Work through every path into each host, including paths from inside your own network.

Load balancers and proxies

What matters is whether the device in front of a host terminates the client’s TCP connection or forwards the client’s packets.

• L7 load balancers and reverse proxies (AWS ALB, Azure Application Gateway, Google HTTPS load balancing, Cloudflare, nginx or Envoy on separate hosts) complete the handshake and open a clean connection to the backend, so options do not reach it. The proxy is the exposed host. Managed services are the provider’s responsibility; a self-hosted proxy should be patched first.
• L4 proxy-mode load balancers (HAProxy or nginx stream in TCP mode, Envoy TCP proxy, AWS NLB TLS listeners) also keep separate client and backend connections, even with end-to-end TLS. The proxy host carries the risk.
• AWS NLB TCP listeners pass IP options through to targets, according to AWS’s November 1 bulletin, so every target behind them is exposed.
• Other L4 passthrough and NAT paths, including other clouds’ network load balancers, Kubernetes NodePort and kube-proxy DNAT, usually leave IP options in place. Test each one.
• Direct server return (LVS/IPVS DR or TUN mode, anycast) and hosts with a public IP receive the original packet. Security groups and port-based firewalls do not inspect IP options.
• IPv6-only paths, and gateways that translate IPv6 clients to IPv4 backends, are not exposed to the main bug, because the translator builds a new IPv4 header.

UDP services and VPNs

UDP listeners such as WireGuard, IPsec, QUIC and DNS cannot trigger the flaw directly. Once traffic is inside a tunnel, however, the decrypted inner TCP packet reaches the gateway’s kernel and every internal host it routes to, so any authenticated or compromised VPN client can attack them. TCP-mode VPNs, including OpenVPN over TCP, SSL VPNs and SSTP, expose the gateway’s kernel to the internet before authentication, and most VPN appliances also run a TCP web portal or management interface. Apply the nftables filter on the gateway after decryption (in prerouting, which sees wg0 and tun0) and on internal hosts.

Paths from inside your network

An unprivileged process can set Record Route or Timestamp options through the IP_OPTIONS socket option, so a compromised workstation, VPN user or container can attack any internal host it can reach. Treat flat internal networks as exposed.

Hosts with NetLabel/CIPSO labeling configured are a special case. The kernel can attach IPv4 options itself, so a plain SYN can produce the vulnerable state, and option filtering does not protect them. Check with netlabelctl -p cipsov4 list and patch these hosts first.

Testing a path

You can test whether options survive a path without exploit code. Capture incoming SYNs on the target with tcpdump -v, then send two SYNs from where an attacker would sit: one plain, and one carrying a harmless Record Route option (for example with Scapy’s IPOption_RR). If the second arrives with an IP header longer than 20 bytes, options survive and the host should be treated as exposed. If only the plain probe arrives, repeat with a Timestamp option before concluding the path is safe.

Prioritize

1. Internet-facing hosts that receive client packets directly or through L4 passthrough, especially those with MPTCP listeners.
2. Self-hosted proxies and VPN gateways.
3. Kubernetes nodes and other multi-tenant hosts.
4. Internal hosts reachable by VPN users or workstations.
5. Backends reachable only through managed L7 load balancers.

Are You Affected: How to Check

Kernel version

Run uname -r on the host, not inside a container, and compare it against the first fixed release for your branch: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 or 7.3. Distribution kernels carry their own version numbers, so check your vendor’s tracker:

• Red Hat: Fixed in RHEL 8.10, 9.8 and 10.2 (RHSB-2026-016). OpenShift CoreOS is still affected.
• Debian: Fixed in 12 and 13 (tracker).
• Amazon Linux: All kernels fixed by October 30, and patched AL2023 EKS AMIs are v20261031 or later (ALAS).
• Oracle Linux: UEK kernels fixed October 16 (advisory).
• SUSE: SLES 16.0 and 15 SP4 to SP6 fixed. SP7 has livepatches, with the regular kernel update pending (advisory).
• AlmaLinux: Fixed kernels in the testing repository (announcement).
• Ubuntu: No fix published yet for any release (tracker).

A host is remediated when its running kernel matches a vendor-fixed build or an applicable livepatch is confirmed loaded. Reboot indicators such as needs-restarting -r only show that a reboot is pending.

MPTCP listeners

Run ss -Mlnp to list MPTCP listening sockets and the processes that own them, and sysctl net.mptcp.enabled to see whether applications may open them. Both checks are per network namespace, so on container hosts also run them inside workload namespaces, for example with nsenter -t <pid> -n ss -Mlnp.

Kubernetes

Every pod on a node shares the node’s kernel, so clusters need node-level remediation even when no node is directly exposed to the internet. One compromised pod can attack the kernel and gain root on the node, along with every other pod, mounted secret and the node’s cloud identity.

• Core components are Go services. The kube-apiserver, kubelet (port 10250), etcd and CoreDNS are written in Go, and builds with Go 1.24 or later may open MPTCP listeners by default. Confirm on each node with ss -Mlnp.
• Several common node images have no fix yet. The AKS default image, GKE’s Ubuntu image types, Ubuntu EKS AMIs and OpenShift CoreOS all depend on mitigations until fixes ship.

Public API servers

The bug triggers during the TCP handshake, before TLS, so API server authentication does not help. On EKS, GKE and AKS the exposed kernel belongs to the provider, but restricting the public endpoint to admin and CI ranges is still worthwhile. On self-managed clusters, the control-plane nodes, which also hold etcd and cluster credentials, are the highest priority: check whether the API load balancer forwards packets, restrict source ranges, and apply the nftables rule now. etcd (2379 to 2380) and the kubelet (10250) should never be reachable from the internet.

Attacks from inside the cluster

An attacker with code execution in one pod can send crafted SYNs to the kubelet, to other pods on the node and to the rest of the cluster, and nothing on that path strips IP options. Dropping CAP_NET_RAW does not close the path. Whether a node-level nftables rule protects pods depends on the CNI:

• Routed (Calico, AWS VPC CNI, most Azure CNI modes): covered for most traffic into pods.
• Bridged (kubenet, flannel): same-node pod-to-pod traffic needs an additional bridge family rule.
• eBPF (Cilium with BPF host routing, GKE Dataplane V2): may bypass netfilter, so verify from a pod and prioritize patching.
• Any CNI: traffic within a pod’s own network namespace, including loopback, is never covered.

In-cluster mitigations, in order of value:

1. Filter on every node with a privileged DaemonSet and, for durable protection, during node bootstrap. This is generally not possible on GKE Autopilot.
2. Disable MPTCP on nodes and restart the kubelet during a drain window, since net.mptcp.enabled=0 does not close existing listeners.
3. Disable MPTCP in pod namespaces through securityContext.sysctls (with allowedUnsafeSysctls on the kubelet) or the CNI tuning plugin, then restart workloads.
4. Limit pod-to-node traffic to the node ports pods actually need.
5. Isolate internet-facing pods with NetworkPolicy and separate node pools.

Rolling node pools

A node is fixed only when it runs a patched kernel, which means replacing it with a new node image or rebooting it after a kernel update. On EKS, move managed node groups to AMI release v20261031 or later, and update any launch templates or Karpenter EC2NodeClass selectors that pin an AMI. On GKE, upgrade pools to a version whose node image the security bulletin confirms as fixed. On AKS, run az aks nodepool upgrade --node-image-only once a fixed image is available. Self-managed clusters can use kured to reboot nodes after kernel updates.

Rolls often stall without any error: Terraform ignore_changes on image fields, launch templates pinned to old AMIs, PodDisruptionBudgets with maxUnavailable: 0, and pools scaled to zero that return on the old image. Confirm the running kernels across the cluster with:

kubectl get nodes -o custom-columns=NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion

What Can You Do Now

If You Cannot Patch Yet

Drop TCP packets that carry IPv4 options. Legitimate TCP traffic almost never uses IPv4 options, so Red Hat recommends filtering them at the host:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

This reduces exposure but does not remove it. It does not cover bridged container traffic, it breaks systems that rely on CIPSO security labels, and rules added this way are lost on reboot unless you persist them in /etc/nftables.conf. Where you can, apply the same filter at the network edge.

Disable MPTCP where you do not use it. Setting net.mptcp.enabled=0 removes the setup Anthropic’s exploit relies on, though the underlying bug remains, and existing listeners stay open until their service restarts. New container network namespaces start with MPTCP enabled, so the setting has to be applied per namespace. For a single Go service, GODEBUG=multipathtcp=0 turns off the default (Go docs), but the Go Security Team cautions that disabling it program by program is fragile.

Leave request migration off. Keep net.ipv4.tcp_migrate_req at 0 unless you depend on it, since migration opens the second path to the freed memory.

Shrink the reachable surface. Move services that only need L7 behind an L7 load balancer, restrict source ranges on L4 and VPN entry points, and keep MPTCP listeners off the internet.

Patching

Install the fixed kernel and reboot. A kernel package update without a reboot leaves the vulnerable kernel running. Live patches can close the gap without a reboot once your vendor ships one; check that the patch is loaded, not just installed. Follow the priority order from the applicability section, and keep the nftables rule on Ubuntu hosts until Canonical publishes a USN.

What to Monitor

• Ubuntu’s security notice for this CVE, and fixed kernels for AlmaLinux production repositories, SUSE 15 SP7, OpenShift CoreOS and the AKS and GKE Ubuntu node images.
• Any addition of CVE-2026-98432 to CISA’s KEV catalog, which would indicate confirmed exploitation.
• Public proofs of concept, especially any that do not depend on an MPTCP listener.

We will update this post as new developments emerge.