CVE-2026-98432: Check and Patch Linux

To fix CVE-2026-98432, install your Linux distribution's patched kernel and reboot into it. Debian, Red Hat Enterprise Linux, AlmaLinux, Oracle Linux and Amazon Linux have shipped one, SUSE has for some releases, and Ubuntu had not as of November 3, 2026. Until a server boots a fixed kernel, drop inbound IPv4 TCP packets that carry IP options, and turn off multipath TCP wherever nothing needs it.

The bug lives in the kernel's TCP handshake, so it is reachable on every listening IPv4 TCP port before your web server or SSH daemon sees the connection, and containers share the host's kernel, so rebuilding images changes nothing. The Linux kernel CVE team scores it CVSS 9.8, and Anthropic says its Claude model wrote a working remote root exploit for it.

Ubuntu raised its priority for the bug to Critical on November 3, 2026, yet its CVE tracker still listed the kernel on every supported release as vulnerable, with fixes "work in progress."

How the Handshake Bug Reads Freed Memory

A client can attach IPv4 options, such as Record Route or Timestamp, to the IP header of its SYN, and Linux keeps a copy on the half-open request socket to echo them in the SYN-ACK. On a stock Ubuntu 24.04 kernel, 6.8.0-142-generic, our SYN carrying a Record Route option came back as a SYN-ACK carrying the same option.

The fix commit, posted by Eric Dumazet on October 1, 2026 and crediting Xinyang Ge of Anthropic as the reporter, describes the race. When the handshake completes, tcp_v4_syn_recv_sock() hands the saved options to the new socket without copying them. If the client retransmits its SYN, another CPU can be building a second SYN-ACK from those bytes while the connection closes and inet_sock_destruct() frees them with a plain kfree(). The fix swaps two kfree() calls for kfree_rcu(), which waits until no reader is left. The flaw dates to Linux 4.4; IPv6 copies the options and avoids the main issue.

The CVE record, published October 15, 2026, says the stale bytes can leak kernel heap memory to the peer, steer out-of-bounds kernel writes or panic the machine. Anthropic's October 27 write-up says Claude wrote an exploit that runs commands as root on "Linux servers with a multipath TCP listener" with no credentials. A lost race only fails one handshake, so the attacker retries: the proof of concept took 48 minutes to leak a kernel pointer and five more to reach a shell. Anthropic has not released it, and CISA's October 30 Known Exploited Vulnerabilities catalog did not list the CVE.

That listener is easy to have without knowing it. The Go Security Team wrote on October 29 that "as of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux," and that "the underlying bug is not specific to MPTCP."

The Fastest Way to See What Is Exposed

Start from the outside. The Port Checker tests one host and port from DevToolLab's servers, the view an attacker has: on November 3, 2026 it reported port 443 open and port 22 closed on devtoollab.com. Every open IPv4 TCP port on an unpatched kernel is a way in, and the Common Ports Lookup names the service behind an unfamiliar number. Neither tool can tell whether a kernel is patched; that check runs on the server.

Our example is api.example.com, a Go service whose go.mod says go 1.24, on an Ubuntu 24.04 EC2 instance in us-east-1 behind a Network Load Balancer TCP listener. It is the worst case: an unpatched kernel, a multipath TCP listener and a load balancer that passes IP options through. We rebuilt it on an Ubuntu 24.04.5 cloud image in a local VM to run every command below; the load balancer behavior is AWS's statement, not our test.

Check the Kernel That Is Running

On Ubuntu, ask the running kernel's own changelog whether it carries the fix:

Bash
Copy
# the kernel running now, which may be older than the newest one installed
uname -r
apt-get changelog "linux-modules-$(uname -r)" 2>/dev/null | grep -c CVE-2026-98432

On the api.example.com rebuild it printed:

text
Copy
$ uname -r
6.8.0-142-generic
$ apt-get changelog "linux-modules-$(uname -r)" 2>/dev/null | grep -c CVE-2026-98432
0

Zero means the fix is not there, and upgrading does not help yet: apt-get -s full-upgrade offered 6.8.0-147.147, whose changelog names 3,514 CVEs but not this one. Ubuntu's tracker shows the fix in progress for 6.8.0-149.149 on 24.04, 5.15.0-203.213 on 22.04 and 7.0.0-43.43 on 26.04. Once one installs and the host reboots, the same check should count above zero.

On RHEL-family servers, compare uname -r and rpm -q kernel with the table below; an installed kernel newer than the running one does nothing until a reboot. Run every check on the host or Kubernetes node, not in a container. Self-built kernels are fixed in 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.

Find Multipath TCP Listeners

Ubuntu enables multipath TCP by default; our 24.04 image printed net.mptcp.enabled = 1. The usual check, sudo ss -Mlnp, printed only its header there while two MPTCP listeners were open, because the mptcp_diag module it needs ships in linux-modules-extra, which the cloud image leaves out. This works without it:

Bash
Copy
# MPTCP listeners also appear as TCP listeners tagged tcp-ulp-mptcp
sudo ss -tlnpi | grep -B1 tcp-ulp-mptcp

text
Copy
LISTEN 0      4096       127.0.0.1:39657      0.0.0.0:*    users:(("containerd",pid=2512,fd=16))
	 cubic cwnd:10 tcp-ulp-mptcp
--
LISTEN 0      4096               *:8124             *:*    users:(("api-go1.24",pid=4651,fd=3))
	 cubic cwnd:10 tcp-ulp-mptcp

The second entry is our api.example.com build, a plain net/http server. The first is containerd v2.4.1, which Lima, the tool running our VM, had installed: Go software you never compiled opens these listeners too, though this one only listens on 127.0.0.1. The same server built with go 1.23 in its go.mod opened plain TCP, because Go takes the default from that line, not from the toolchain (we built everything with Go 1.27.3).

To switch it off for one program, start it with GODEBUG=multipathtcp=0 or add godebug multipathtcp=0 to its go.mod; both gave plain TCP listeners in our test. The Go team calls this per-program route "a fragile mitigation," since one forgotten listener undoes it.

Patch and Reboot

A kernel update changes nothing until the machine boots into it. On Debian 12, apt-get upgrade kept back linux-image-arm64 in our test, while a full-upgrade dry run selected linux-image-6.1.0-54-arm64 at 6.1.190-1 from the security archive:

Bash
Copy
sudo apt update && sudo apt full-upgrade
# on Ubuntu, this lists the packages waiting for a reboot
cat /var/run/reboot-required.pkgs
sudo reboot

On RHEL-family hosts, AlmaLinux's instructions are sudo dnf clean metadata && sudo dnf upgrade, then sudo reboot and uname -r to confirm. For Amazon Linux 2023, AWS gives sudo dnf update kernel --releasever=latest && sudo reboot, and instances locked to a release need 2023.12.20261102 or later.

Managed AWS compute takes a new image instead. The AWS security bulletin says EKS-optimized Amazon Linux 2023 AMIs from release v20261031 and ECS-optimized AMIs from release 20261031 carry the fix, Fargate work launched after 9:00 AM PST on November 1 runs patched, and Lambda is not affected. On Ubuntu there is nothing to install yet: watch the tracker, then run the apt commands above and reboot.

If You Cannot Patch Today

Every published stopgap drops inbound IPv4 TCP packets whose IP header is longer than 20 bytes, which only IP options produce. TCP options such as window scaling live in the TCP header and still pass, and dropping the SYN stops the kernel from saving the options at all. Red Hat's bulletin RHSB-2026-016 says the rule "reduces exposure to this vulnerability but cannot fully prevent it."

Use AlmaLinux's version, which hooks prerouting. The rule Red Hat and Ubuntu publish hooks input, and in our test it never saw a SYN routed to a seperate network namespace behind the host, which is how Docker and Kubernetes deliver traffic to containers. The prerouting rule dropped that SYN and one aimed at the host itself:

Bash
Copy
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
  chain prerouting {
    type filter hook prerouting priority -300; policy accept;
    meta l4proto tcp ip hdrlength > 5 counter drop
  }
}
EOF
sudo nft list table ip cve_2026_98432

text
Copy
table ip cve_2026_98432 {
	chain prerouting {
		type filter hook prerouting priority raw; policy accept;
		meta l4proto tcp ip hdrlength > 5 counter packets 2 bytes 120 drop
	}
}

The counter shows our two Record Route SYNs, and ordinary curl requests on the same paths still got answers. ip hdrlength counts 32-bit words, so anything above 5 means options; the iptables form below reads that field with 0>>24&0x0f, which the Bitwise Calculator can walk through. Both rules vanish at reboot; remove the nftables one sooner with sudo nft delete table ip cve_2026_98432.

Bash
Copy
# iptables hosts: the raw table also runs before routing decisions
sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0x0f=6:15" -j DROP

It dropped the same two SYNs on the stock Ubuntu 6.8 kernel, which ships the xt_u32 module. AWS's bulletin offers an INPUT-chain version that, like Red Hat's, missed the routed SYN.

Ubuntu's tracker shows how to keep a rule across reboots by including it from /etc/nftables.conf. Read that file first: on Ubuntu it starts with flush ruleset, and running sudo nft -f /etc/nftables.conf on our live VM deleted an iptables-nft chain we had created, as it would delete Docker's or UFW's.

Then turn off multipath TCP if nothing needs it. That removes the setup Anthropic's exploit used, not the bug:

Bash
Copy
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

Existing listeners stay MPTCP until their process restarts. Our Go server kept its MPTCP listener after the change and came back on plain TCP after a restart, with no error logged.

Last, check what sits in front of each host. AWS says Network Load Balancer TCP listeners "pass client packets, including IP options, to targets," as do Global Accelerator, PrivateLink and VPC Lattice TCP listeners, so instances that recieve traffic from those go first. Application Load Balancer, CloudFront and API Gateway do not, and AWS Network Firewall can drop the packets at the edge with the bulletin's rule.

Common Errors and Warning Signs

sudo ss -Mlnp prints only its header. On an Ubuntu cloud image that can mean mptcp_diag is missing, not that no listener exists. Use the tcp-ulp-mptcp check, or install linux-modules-extra-$(uname -r) and run sudo modprobe mptcp_diag.

sysctl: cannot stat /proc/sys/net/mptcp/enabled: No such file or directory. The kernel has no multipath TCP, like Docker Desktop's 6.10.14-linuxkit kernel. No MPTCP listener can exist, but the kernel still needs the fix.

dnf updateinfo list --cve CVE-2026-98432 prints nothing on AlmaLinux 9. Its errata did not list the CVE for version 9 on November 3, yet dnf list --available kernel in our AlmaLinux 9 container showed the fixed 5.14.0-687.64.1.el9_8. Trust the version.

The upgrade finished and uname -r did not change. The old kernel runs until a reboot; on our Ubuntu VM, /var/run/reboot-required.pkgs listed the new kernel right after it installed.

When Not to Rely on This

The packet filter and the MPTCP switch are not the fix: Red Hat, AlmaLinux, Ubuntu and AWS all say only a patched kernel closes the hole. AlmaLinux warns that traffic between containers on one host may bypass the filter, and networks using CIPSO security labels, which ride in IPv4 options, cannot use it. Skip the init_on_free=1 boot flag: a CIQ kernel engineer showed on oss-security that the leak reads live objects, which zeroing freed memory never touches. Leave public proof-of-concept repositories alone too; Atlas Security counted 57 by November 2.

Conclusion

Only a fixed kernel the host has booted closes CVE-2026-98432; the packet filter and the MPTCP switch only buy time.

On Ubuntu, apply the prerouting rule now, turn multipath TCP off where nothing uses it, and watch the tracker for 6.8.0-149.149 on 24.04 or 5.15.0-203.213 on 22.04, then upgrade and reboot. That is the plan for api.example.com.

On Debian, RHEL, AlmaLinux, Oracle Linux, SUSE 16.0 and Amazon Linux, install the fixed kernel and reboot today, starting with hosts behind a Network Load Balancer TCP listener. On EKS and ECS, roll nodes to the v20261031 and 20261031 AMIs or later. On OpenShift, which had no fixed RHEL CoreOS on November 3, filter IPv4 options in front of the cluster.

For Go services, read the go line in each go.mod: from go 1.24 on, a service opens multipath TCP listeners wherever the kernel allows them.

Related DevToolLab Tools

• Port Checker - test each public IPv4 TCP port from outside your network to decide which hosts to reboot first.
• Common Ports Lookup - name an unfamiliar port in ss -tlnp output before deciding whether it should listen at all.
• Bitwise Calculator - work through 0>>24&0x0f to see why a header length field of 6 to 15 means IPv4 options.
• Uptime SLA Calculator - turn your SLA into a downtime budget before scheduling the reboots this fix needs.

Related Guides

• PHP2Shell: How to Check and Patch PHP
• How Zero-Day Exploits Unfold in Kubernetes
• Container Security Tools Compared
• TCP vs UDP Explained