Linux kernel TCP flaw CVE-2026-98432: how to patch

Most Linux kernel vulnerabilities need an attacker who already has an account on the machine. CVE-2026-98432 is different: it sits in the IPv4 TCP code that accepts new connections, so an attacker can reach it over the network, without an account, against any listening TCP port. It has been in the kernel since version 4.4, released in 2016, which means nearly every Linux server running today is affected until it is patched.
Here is what the flaw is, how serious the real-world risk is, and exactly how to fix it.
The short version
- CVE: CVE-2026-98432, a use-after-free in the Linux kernel's IPv4 TCP handshake path.
- Severity: CVSS 9.8 (Critical, per Red Hat's rating).
- Attack vector: Network. A remote, unauthenticated attacker sends crafted IPv4 TCP packets that carry IP options to a listening port.
- Impact: Kernel crash, kernel memory disclosure or memory corruption. Remote code execution has been demonstrated against hosts with a Multipath TCP (MPTCP) listener.
- Affected: Linux 4.4 and later. IPv6 is not affected.
- Exploited in the wild: No confirmed reports as of early November 2026. The demonstrated exploit has not been published.
- Fix: Install your distribution's patched kernel and reboot, or apply a livepatch where available.
What the bug is
When a server receives a TCP SYN — the first packet of a new connection — the SYN can carry IPv4 options. The kernel stores those options with the pending connection and later hands them to the new, fully established connection without copying them.
If the client retransmits the SYN and that retransmission is handled on another CPU at the same moment, the second CPU can read the options after the pending connection has already been freed. That is a use-after-free: the kernel reads memory it no longer owns. Exploiting it means winning a timing race inside the kernel, which makes it harder to weaponise reliably — but not impossible.
The upstream fix (commit e3f33b0a1d89d738e2b913dab519226eaf76e15b) is tiny: it changes two lines so the kernel waits until every reader has finished before freeing the data. IPv6 was never affected because it copies the options instead of sharing them.
How serious is it really?
The bug was disclosed on October 27, 2026 by Anthropic, whose researchers reported that their AI model produced an exploit giving remote root on servers with a Multipath TCP listener. That exploit chain has not been published. CloudLinux's kernel team said it could not reproduce the claim, and AWS states it has no evidence the issue has been leveraged. Some trackers report public proof-of-concept code for parts of the attack (the race and a kernel pointer leak) since late October, and as of November 9 the CVE was not in CISA's Known Exploited Vulnerabilities catalog.
My reading: confirmed in-the-wild exploitation has not been reported, but a remotely reachable, pre-authentication kernel bug with a demonstrated root exploit is exactly the kind of flaw that gets weaponised once details spread. Treat it as patch now, not "patch next maintenance window".
Note that MPTCP is only where RCE was demonstrated. The bug itself is in ordinary TCP code, so servers with MPTCP disabled still need the fix.
How to check if you are patched
Check your running kernel:
uname -r
Then compare it with your distribution's advisory for CVE-2026-98432. Examples of fixed kernels published so far:
| Distribution | Fixed kernel / advisory |
|---|---|
| Amazon Linux 2 | ALAS2-2026-4065 (kernel 5.4, 5.10, 5.15 streams) |
| Amazon Linux 2023 | ALAS2023-2026-3365 / -3335 / -3251; locked instances need release 2023.12.20261102 or later |
| RHEL 9 family (CloudLinux 9) | 5.14.0-687.64.1.el9_8 or newer |
| RHEL 10 family (CloudLinux 10) | 6.12.0-211.73.1.el10_2 or newer |
| AlmaLinux / Rocky / Debian / SUSE | See your vendor's CVE-2026-98432 advisory |
| Ubuntu | Fixes were still in the -proposed pocket in early November; check the Ubuntu CVE tracker |
Remember that installing a new kernel package does nothing until you reboot into it. uname -r shows what is actually running.
How to fix it
Update the kernel and reboot:
# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade
sudo reboot
# RHEL / AlmaLinux / Rocky / Fedora
sudo dnf update kernel
sudo reboot
# Amazon Linux 2
sudo yum update kernel && sudo reboot
# Amazon Linux 2023 (default 6.1 kernel)
sudo dnf update kernel --releasever=latest && sudo reboot
If you cannot reboot right away, a livepatch can apply the fix to the running kernel. KernelCare has published it for CloudLinux 7h, 8, 9 and 10 (kcarectl --update); check whether Canonical Livepatch, kpatch or your provider's equivalent covers your kernel.
After rebooting, run uname -r again and confirm it matches the fixed version.
If you cannot patch immediately
Be careful with mitigation advice here, because vendors disagree:
-
Red Hat says no available mitigation meets its criteria for ease of deployment, so the kernel update is the fix.
-
Disabling MPTCP (
sysctl -w net.mptcp.enabled=0) removes the path where RCE was demonstrated, but AWS and CloudLinux both state it does not resolve the issue. -
AWS lists a temporary firewall rule that drops IPv4 packets carrying IP options, which legitimate traffic almost never uses:
sudo iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROPThe rule matches packets whose IP header is longer than the minimum (IHL 6–15), i.e. packets with IP options. It does not survive a reboot unless you save it — and after a reboot you should be on a fixed kernel anyway.
-
If your servers sit behind a load balancer, CDN or proxy that terminates TCP (AWS Global Accelerator, for example, drops these packets), the backends are less exposed — but anything with a port open directly to the internet still needs the update. That includes SSH.
What I would do this week
- List every Linux host, VM and node pool you run, including "forgotten" VPS instances and self-managed Kubernetes nodes.
- Patch and reboot internet-facing servers first, then internal ones.
- For hosts you cannot reboot, apply a livepatch and the temporary firewall rule, and schedule the reboot.
- Rebuild golden images and autoscaling launch templates so new instances do not come up on a vulnerable kernel.
- Watch your distribution's advisory and CISA KEV for changes in exploitation status.
If you run WordPress or other sites on your own VPS and want help patching and setting up monitoring that catches this kind of thing early, book a free consultation.


