Skip to main content
Published on November 14, 2026
CVE-2026-98432 — Linux kernel, IPv4 TCP connection setup. The kernel security team scores this flaw 9.8. It is exploitable remotely, with no authentication, on any server that accepts IPv4 TCP connections. Install your distribution’s fixed kernel and reboot today.

The bug in two sentences

During a TCP handshake, the kernel hands the IP options of the connection request over to the new socket without copying them, then frees them without waiting for other CPUs to finish reading. A retransmitted SYN, handled at the same moment on another CPU, then builds its SYN-ACK from memory that has already been freed: a use-after-free in ip_options_build(). A second path leads to the same bug: request socket migration (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE BPF program). Affected versions:
  • every Linux kernel since 4.4;
  • fixed upstream in 7.3-rc7, and in stable branches 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10.
The 9.8 score comes from the kernel CVE team and appears in the NVD record. Red Hat uses the same score and rates the flaw critical. Ubuntu gives it critical priority.
Anthropic described an exploit written by Claude, an unreleased internal research model: zero-click remote code execution as root on a server exposing a Multipath TCP (MPTCP) listener. The write-up describes the exploit without releasing its code. The flaw is not in CISA’s Known Exploited Vulnerabilities (KEV) catalog (November 13, 2026 version).

Sizing your exposure

The question to ask: does your server accept IPv4 TCP connections? Almost every server does: SSH, web, mail, databases. MPTCP is not a precondition. The published exploit uses it, but Red Hat points out that the bug lives in plain IPv4 TCP: RHEL, which disables MPTCP by default, is still vulnerable. To see the running kernel:
Disabling MPTCP (sysctl -w net.mptcp.enabled=0) does not protect you: it closes the demonstrated setup, not the flaw. Likewise, ss -Mlnp shows whether a service listens over MPTCP, but an empty result does not mean the server is safe. The Go security team gives the same warning: since Go 1.24, Go programs open their listening sockets with MPTCP by default on Linux, and only a kernel update solves the problem.

Updating the kernel, distro by distro

The fix is a kernel update followed by a reboot. Until the server reboots, the old kernel stays loaded and the flaw stays open. Before rebooting a production VPS, take a snapshot. If the server does not come back on the network, the KVM console gives you the boot screen.

Debian

Ubuntu

Specialized kernels (cloud, lowlatency, FIPS) have their own versions: see Ubuntu’s CVE page.

RHEL, AlmaLinux, Rocky Linux

The AlmaLinux versions come from AlmaLinux’s advisory. For Rocky Linux and RHEL EUS releases, check Red Hat bulletin RHSB-2026-016 and your distribution’s advisory.

Kubernetes

Every node needs the fixed kernel and a reboot. Drain nodes one at a time to keep the service up:
Red Hat notes that an nftables rule on a node only filters traffic that crosses the host’s network namespace, not pod-to-pod traffic. Filtering at the network edge, in front of the cluster, has no such gap.

Mitigation until you can patch

Red Hat and Ubuntu publish the same nftables rule: it drops inbound IPv4 TCP packets that carry IP options, which removes the input the flaw needs. Standard TCP options (timestamps, window scaling) still pass, and so does IPv6. The rule takes effect without restarting services. Its limits:
  • it reduces the risk without removing it and does not replace the kernel update;
  • it breaks connections that depend on IPv4 options;
  • it covers the host; a container with its own networking needs the rule applied separately, and traffic between containers on the same host can bypass it;
  • test it against your own traffic before rolling it out to production.

Debian and Ubuntu

Procedure published by Ubuntu. It assumes the firewall is managed through /etc/nftables.conf, without UFW or firewalld; Debian uses the same file.

RHEL, AlmaLinux, Rocky Linux

Procedure published by Red Hat. Save the rule to a file named cve-2026-98432.nft:
Then check and apply it:
This rule does not survive a reboot. To make it persistent, follow the “Making the mitigation persistent” section of bulletin RHSB-2026-016: Red Hat warns that enabling nftables.service may conflict with firewalld or an existing configuration.

Verifying the mitigation

The command should print the table and its input chain. The counter on the drop line shows how many packets were dropped. An error means the rule is not loaded.

Rolling back the mitigation

Once the fixed kernel is loaded (check with uname -r or uname -v), remove the rule.
If you made the rule persistent on RHEL, follow the “Reverting After Patching” section of the Red Hat bulletin.

What next?

The nftables rule is only a stopgap: the target is the fixed kernel, loaded after a reboot. For another recent Linux kernel flaw, read Copy Fail (CVE-2026-31431). For any technical question, open a ticket from your OnetSolutions customer area.