CVE-2026-98432: The CVSS 9.8 Linux TCP Bug Now Has an Exploit. Patched Node Images

Patch every Linux node to a kernel containing the fix for CVE-2026-98432, starting with internet-facing hosts that run Multipath TCP listeners. It is a use-after-free in the IPv4 TCP handshake, present since Linux 4.4, scored CVSS 9.8, and a working exploit exists. If you run Go 1.24 or newer servers, you probably have MPTCP listeners already.

What happened, in dates

The CVE was published on October 15, 2026 with the kernel title "ipv4: free inet_opt and ireq_opt after an RCU grace period". The kernel CNA has since scored it 9.8 (AV:N/AC:L/PR:N/UI:N). On October 29 the Go security team, citing an exploit described in Anthropic's vulnerability research write-up, warned that a server with MPTCP listeners "is shown to be vulnerable to Remote Code Execution"; the notice reached oss-security on October 30 (UTC). The Go team adds the line that should change your priority: "the underlying bug is not specific to MPTCP."

Mechanically, when a TCP request socket becomes a child socket, the IPv4 options buffer (ireq_opt) is handed over without a copy. Another CPU processing a retransmitted SYN can still be building a SYN-ACK from that buffer when the child is freed with a plain kfree(), so ip_options_build() reads freed memory. A second path exists through request socket migration (net.ipv4.tcp_migrate_req=1). IPv6 is not affected by the first issue because it duplicates the options.

Am I affected? Three checks per node

# 1. Kernel version (compare with the matrix below; distros backport, so trust the advisory)
$ uname -r

# 2. Can this kernel create MPTCP sockets? Default is 1 (enabled)
$ sysctl net.mptcp.enabled

# 3. Is anything actually listening with MPTCP right now?
$ ss -Mlnp

# Whole cluster at once: kernel and OS image per node
$ kubectl get nodes -o custom-columns=NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage

Since Go 1.24, Go programs enable MPTCP by default on Linux listen sockets, so a Go service in a pod opens an MPTCP listener in the node's kernel. Every container on a node shares that kernel, which is why this is a node-level problem and not an application one.

The patch matrix, as of October 31, 2026

The managed Kubernetes picture follows from that. EKS: the v20261031 AL2023 AMIs for Kubernetes 1.33 through 1.37 ship the patched 6.12.113 and 6.18.56 kernels. The 1.31 and 1.32 standard AMIs in the same release still carry kernel 6.1.189, below the upstream 6.1.190 fix, so move those clusters to 1.33 or newer AMIs. AKS: Ubuntu node images inherit Ubuntu's status, so treat them as unpatched until a node image release says otherwise. GKE: we found no GKE security bulletin for this CVE as of October 31; watch the bulletins page before assuming COS or Ubuntu nodes are fixed.

Roll patched images through node pools

Use surge, not in-place reboots, wherever the platform supports it. Make sure your PodDisruptionBudgets allow at least one eviction first, or the rollout stalls (we covered that trap in surviving node drains with PDBs).

# EKS managed node group: latest AMI release for the current Kubernetes version
$ eksctl upgrade nodegroup --name=workers --cluster=prod --region=eu-west-1

# GKE: one extra node per pool, never take capacity away, then recreate nodes
$ gcloud container node-pools update workers --cluster=prod --location=europe-west1 \
    --max-surge-upgrade=1 --max-unavailable-upgrade=0
$ gcloud container clusters upgrade prod --node-pool=workers --location=europe-west1

# AKS: node image only, no Kubernetes version change, a third of the pool at a time
$ az aks nodepool update -g rg-prod --cluster-name prod -n workers --max-surge 33%
$ az aks nodepool upgrade -g rg-prod --cluster-name prod -n workers --node-image-only

# Self-managed nodes: cordon, drain, patch, reboot, uncordon
$ kubectl cordon node-1 && kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
$ sudo apt update && sudo apt full-upgrade && sudo reboot
$ kubectl uncordon node-1

Karpenter users on an AL2023 alias such as al2023@latest get the new AMI through drift replacement; confirm nodes actually rotated with the custom-columns query above rather than assuming they did.

Interim mitigations where no patch exists

Block IPv4 packets with IP options. The bug lives in IP option handling, which is why Red Hat's bulletin ships an nftables rule that drops inbound IPv4 TCP packets whose header is longer than five 32-bit words, that is, any packet carrying options:

# cve-2026-98432.nft (from RHSB-2026-016)
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

Normal internet TCP rarely carries IP options, but test it against your own traffic first, and remove the table with sudo nft delete table inet cve_2026_98432 once patched. The same filter at a cloud edge or load balancer layer helps where you can express it.

Turn off MPTCP where nothing needs it. sudo sysctl -w net.mptcp.enabled=0 stops new MPTCP sockets from being created. For Go services, GODEBUG=multipathtcp=0 disables it per process, but the Go team calls per-program disabling "a fragile mitigation": one forgotten listener and the node is exposed again.

Segment. A NetworkPolicy that defaults to deny limits which pods can reach a listener, which narrows the in-cluster path. It does nothing for traffic arriving at a node port or host-network pod from outside.

Where this breaks

None of these mitigations is a fix. Disabling MPTCP removes the demonstrated exploit path, not the bug, and the Go team explicitly warns that hosts without MPTCP listeners may be reachable by similar attacks. The nftables rule depends on traffic actually passing through that hook, and a DaemonSet that applies it can drift. Kernel version strings also mislead in both directions: distro kernels backport fixes without changing the upstream number, so check the vendor advisory, and a patched package does nothing until the node reboots into it.

Questions people ask

Does disabling MPTCP fix CVE-2026-98432?

No. Setting net.mptcp.enabled=0 blocks the publicly demonstrated attack path, which needs an MPTCP listener, but the use-after-free is in the regular IPv4 TCP handshake code. The Go security team says the underlying bug is not specific to MPTCP and other exploit paths may exist. Use it as a stopgap on unpatched Ubuntu, RHEL and Amazon Linux 2 hosts, then install a fixed kernel and reboot.

Is IPv6-only traffic affected by CVE-2026-98432?

The main race is IPv4-only, because the IPv6 handshake copies the options instead of transferring them. The kernel description notes a related request-migration issue in IPv6 that touches options set only by CALIPSO, to be fixed separately. Most dual-stack nodes still accept IPv4, so being IPv6-capable does not make a node safe; only a node with no IPv4 listeners at all sidesteps the primary bug.

Which EKS AMI fixes CVE-2026-98432?

The AL2023 EKS-optimized AMIs in release v20261031 for Kubernetes 1.33 to 1.37 include kernel 6.12.113-138.209 or 6.18.56-125.164, both listed as fixed in Amazon's advisories. The 1.31 and 1.32 standard AMIs in that release still ship kernel 6.1.189. Upgrade managed node groups with eksctl upgrade nodegroup, then confirm the kernel column on every node.

The call we'd make

Roll patched images today on Debian, AL2023 and Oracle UEK fleets, internet-facing pools first. On Ubuntu and RHEL nodes with no fix yet, apply the IP-options drop rule and disable MPTCP where nothing depends on it, then patch the day the vendor ships. The caveat: an exploit is public and the bug is not MPTCP-only, so treat the mitigations as days of cover, not a resting state. Triage the rest with our production vulnerability playbook.

Sources

• Ubuntu: CVE-2026-98432
• Red Hat: RHSB-2026-016, Linux kernel IPv4 use-after-free
• Amazon Linux: ALAS2023-2026-3335 (kernel6.12)
• oss-security: Go security team on CVE-2026-98432 and MPTCP