Linux Kernel TCP Vulnerability CVE-2026-98432 (November 2026): What It Is and How to Patch Your Servers, Step by Step

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP connection setup that a remote attacker can trigger without logging in, and that vendors say can lead to remote code execution. It has been in the kernel since Linux 4.4, so if you run Linux servers with any open IPv4 TCP port (a web server, an API, SSH), assume you are affected until you have checked your kernel. The fix is a kernel update and a reboot. Debian, Amazon Linux, Oracle Linux and RHEL have fixed kernels out; Ubuntu's fixes are still in its -proposed pocket as of 3 November 2026.

I'm Kunal Vohra, a fractional CTO and a security researcher and cybersecurity advisor. Early-stage startups very often run on Ubuntu or Amazon Linux behind a cloud load balancer, with nobody whose job it is to reboot servers. This is the guide I'd hand that team: what the bug is, how to tell where you stand in five minutes, and how to patch each major distribution.

What CVE-2026-98432 is

CVE-2026-98432 is a race condition in how the kernel hands IP options from an incoming TCP connection request to the new socket. When a server accepts an IPv4 TCP connection, the kernel passes the request's IP options to the child socket without copying them. If the client retransmits its connection request (a second SYN) at the wrong moment, the kernel can read those options after they have been freed. The upstream fix, merged on 5 October 2026, delays freeing them until it is safe.

The facts that matter for prioritising it:

• Remote and unauthenticated. The trigger is a TCP connection request carrying IPv4 Record Route or Timestamp options, sent to any listening TCP port. No credentials, no user interaction.
• IPv4 only on the main path. IPv6 is not affected by the main issue; a related IPv6 migration issue is being handled separately.
• Old. Present since Linux 4.4, so almost every supported distribution kernel is in range.
• Scored differently by different vendors. The kernel CVE team and Ubuntu rate it 9.8 (Critical). Red Hat first rated it lower and now treats it as Critical. Oracle and SUSE use 8.1, and Amazon Linux's CVE page shows 8.1. The spread reflects how hard the race is to win, not doubt about whether it is real.
• A working exploit exists, privately. Anthropic, whose researcher is credited in the kernel fix, published research on 27 October 2026 describing an exploit its model wrote for one configuration (a server with a Multipath TCP listener): 48 minutes to leak a kernel address, about five more minutes to run commands as root. The exploit code was not released. As of 3 November, no vendor or CERT has reported attacks in the wild.

The line I'd put in front of any founder: a 53-minute path from "open port" to "root on your server" now exists on paper, and the only complete fix is a kernel update plus a reboot.

Is your server affected? A five-minute check

If a server runs a Linux kernel from 4.4 onwards, accepts IPv4 TCP connections, and has not been rebooted into a fixed kernel, treat it as affected. Containers don't change this: they share the host kernel, so the host is what you patch. Managed platforms where you never touch a kernel (serverless functions, most PaaS) are your provider's job; check their status page, but you have nothing to install.

On each server, start with the running kernel and your distribution:

uname -r
cat /etc/os-release

Then compare against your distribution's fixed version below. Two traps catch people here:

• Installed is not running. A fixed kernel package does nothing until you reboot into it. uname -r shows what is actually running.
• The MPTCP check is not an exposure test. Red Hat mentions ss -Mlnp to find Multipath TCP listeners, which matches the one configuration Anthropic exploited. No MPTCP listeners does not mean you are safe; the bug is in the ordinary IPv4 TCP path.

Make a list of every Linux host you own: web and API servers, databases, bastion hosts, CI runners, Kubernetes nodes. The last two are the ones teams forget.

How to fix CVE-2026-98432, step by step

The fix is the same everywhere: install your distribution's patched kernel, reboot, and confirm the running version. What differs is whether a fixed kernel exists yet. Status below is as published by each vendor between 1 and 3 November 2026; check the vendor pages in the sources before you act, because they are moving daily.

Step 1: Debian

Debian has fixed kernels in its security repositories: bookworm (Debian 12) in linux 6.1.190-1 (and linux-6.12 6.12.113-1~deb12u1), trixie (Debian 13) in 6.12.113-1 or later.

sudo apt update
sudo apt full-upgrade
sudo reboot
# after the reboot
uname -r

Step 2: Amazon Linux

Amazon Linux shows the CVE as fixed on every kernel it ships, with advisories dated 24 to 30 October 2026 (ALAS2023-2026-3365 for the Amazon Linux 2023 kernel package, ALAS2-2026-4065 for Amazon Linux 2 core, plus separate advisories for the 5.4, 5.10 and 5.15 extras and the AL2023 kernel6.12 and kernel6.18 packages).

# Amazon Linux 2023
sudo dnf upgrade --refresh kernel
# Amazon Linux 2
sudo yum update kernel
sudo reboot
uname -r

If you run AWS-managed node groups or launch templates, rolling to the latest AMI is often cleaner than patching nodes in place.

Step 3: RHEL, Rocky, Alma and Oracle Linux

Red Hat shipped fixed kernels on 1 November 2026: RHEL 8.10 in kernel-4.18.0-553.182.1.el8_10 (RHSA-2026:93414), RHEL 9.8 in kernel-5.14.0-687.64.1.el9_8 (RHSA-2026:93412) and RHEL 10.2 in kernel-6.12.0-211.72.1.el10_2 (RHSA-2026:93413). Red Hat's errata say the system must be rebooted. RHEL 7 is not affected. Oracle Linux's UEK kernels were fixed on 16 October. Rebuilds such as Rocky and Alma follow Red Hat; check their own advisories for the matching build.

sudo dnf upgrade --refresh kernel
sudo reboot
uname -r

On OpenShift, node kernels come from RHEL CoreOS; follow Red Hat's OpenShift guidance in the bulletin rather than patching nodes by hand.

Step 4: Ubuntu

Ubuntu is the one most startups run, and the one without a fix in the normal update channel yet. As of Canonical's 2 November post, fixed kernels for 22.04 LTS (5.15.0-203.213), 24.04 LTS (6.8.0-149.149) and 26.04 LTS (7.0.0-43.43) are in the -proposed pocket while Canonical runs qualification testing; 26.10 has its fix in 7.3.0-10.10. Fixes for 16.04, 18.04 and 20.04 are pending and need Ubuntu Pro (ESM). Cloud, FIPS and real-time kernel flavours are still in progress, so check the CVE page for linux-aws, linux-azure or linux-gcp if that is what uname -r shows.

You have two choices. The conservative one: apply the mitigation in Step 5 now, then run sudo apt update && sudo apt full-upgrade and reboot the day the fix reaches the normal updates pocket. The faster one, which Canonical documents: install the kernel from -proposed explicitly.

uname -r
dpkg -l 'linux-image*' | grep ^ii

sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot

Packages in -proposed are still being tested, so I'd do this on one non-critical server first, watch it for a day, then roll it out. Packages from -proposed are not picked for upgrade by default, which is why the explicit install is needed.

Step 5: the nftables stopgap (only until you can patch)

If you can't reboot into a fixed kernel today, Red Hat publishes a filter that drops inbound IPv4 TCP packets carrying IP options, which blocks the known trigger. Save this as cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Then check, load and confirm it:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Know its limits before you rely on it. Red Hat and Canonical both say filtering reduces exposure but is not a substitute for patching. It only protects the host it is loaded on: traffic between containers on the same host can bypass it, and on Kubernetes or OpenShift pod-to-pod traffic is not covered. It can break the rare workloads that depend on IPv4 options, so test it outside production first. It does not survive a reboot unless you add it to your nftables configuration. When the fixed kernel is running, remove it:

sudo nft delete table inet cve_2026_98432

One mitigation I'd skip: disabling Multipath TCP. Red Hat and Canonical both say the bug is not specific to MPTCP, and on RHEL MPTCP is already off by default, so turning it off changes nothing on a default system.

Step 6: confirm, and don't forget the long tail

After each reboot, uname -r should show the fixed version. Then work down the list you made earlier: CI runners (self-hosted ones especially), bastion hosts, database servers you manage yourself, and Kubernetes nodes. Custom kernels need 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, or 7.3 or later; the kernel team's advice is to move to the latest stable release rather than cherry-pick.

What this means for startups

This bug is a reminder that "we're on managed cloud" is not the same as "someone patches our servers." A cloud VM is your operating system to maintain. The teams that will be done with CVE-2026-98432 by Friday are the ones that already had three boring things in place:

• An inventory. A list of every Linux host and what kernel it runs. Without it, you find the forgotten server last, or never.
• Reboots that aren't scary. Two instances behind a load balancer, or nodes you can drain and replace, so a kernel update is a routine rolling restart rather than a downtime window someone has to approve.
• Automatic security updates where you can tolerate them, with unattended-upgrades on Ubuntu and Debian or dnf-automatic on RHEL-family systems, plus a scheduled reboot window. Updates that install but never reboot leave you exactly as exposed as before.

There is a second lesson, and it is the reason this bug got attention. An AI model wrote a working root exploit for a race condition in under an hour. Whatever you think of that, the gap between "patch published" and "exploit exists" is shrinking, and the planning assumption that you have weeks to get round to a kernel update is getting weaker. My startup security checklist puts patching and tested backups near the top for that reason, and the same pattern showed up last month with the Next.js CVE-2026-96889 fix and PHP2Shell: the fix was quick, finding every place that needed it was the slow part.

If nobody on your team owns this kind of work, that is the gap to close, not this one CVE. A technical advisor can set up the inventory and the patch routine with your engineers in a few sessions; a fractional CTO owns it on an ongoing basis along with the rest of your security posture.

Frequently asked questions

What is CVE-2026-98432? A use-after-free race in the Linux kernel's IPv4 TCP connection setup, present since Linux 4.4. A remote, unauthenticated attacker sending connection requests with IPv4 options to an open TCP port can trigger it, and vendors say it can lead to remote code execution. The fix is a kernel update and a reboot.

Is Ubuntu affected by CVE-2026-98432, and is there a fix? Yes. As of 2 to 3 November 2026, fixed kernels for Ubuntu 22.04, 24.04 and 26.04 LTS are in the -proposed pocket while Canonical tests them, with no date yet for the normal updates channel; 16.04, 18.04 and 20.04 fixes are pending. Use the nftables stopgap or install from -proposed carefully until the fix reaches updates.

Is this vulnerability being exploited? No attacks had been reported by vendors or CERTs as of 3 November 2026. Anthropic has described a private working exploit for one configuration, and proof-of-concept code that triggers the race (without code execution) is public, so I would not wait for reports of attacks before patching.

Does disabling MPTCP fix CVE-2026-98432? No. The bug is in the ordinary IPv4 TCP path; MPTCP is only the configuration one exploit used. Red Hat and Canonical both say disabling it is not a complete mitigation.

Do I need to reboot after the kernel update? Yes. The fixed kernel only protects you once it is running. Check with uname -r after the reboot.

Are Docker containers and Kubernetes pods affected? Containers share the host's kernel, so patch the host or the node. Host-level nftables rules don't cover traffic between containers or pods on the same host, which is another reason the kernel update is the real fix.

If you're not sure which of your servers are exposed, or you want a patching routine that makes the next one boring, book a 30-minute call. Bring your list of hosts, or the fact that you don't have one, and we'll start there.

Sources

• RHSB-2026-016: Use-after-free in kernel IPv4 (CVE-2026-98432) (Red Hat)
• RHSA-2026:93412 kernel security update for RHEL 9 (Red Hat)
• CVE-2026-98432 (Ubuntu Security)
• Fixes available in -proposed pocket for CVE-2026-98432 (Canonical)
• CVE-2026-98432 (Debian Security Tracker)
• CVE-2026-98432 (Amazon Linux Security Center)
• Discovering and exploiting vulnerabilities in critical, real-world software with Claude (Anthropic)
• Red Hat Patches 9.8-Rated Linux TCP RCE Flaw While Ubuntu Releases Fixes for Testing (The Hacker News)
• Linux kernel TCP flaw with 9.8 CVSS (The Hacker News)