# CVE-2026-98432: Linux Kernel TCP Flaw Patch Status for Ubuntu, RHEL, Debian, AWS and Proxmox > Amen Security Team · 2026-11-02T20:53:41.043Z · security · cybersecurity · linux · cve · kernel · patching CVE-2026-98432 sits in the code that accepts every new IPv4 TCP connection on a Linux server. The kernel team and Red Hat both rate it 9.8 out of 10, and a working remote root exploit has been described in public. Most distributions now ship a fixed kernel: Red Hat released its fixes on November 1, and Debian, AlmaLinux, Rocky Linux, Oracle Linux, SUSE, Proxmox and parts of Amazon Linux have theirs. Ubuntu is the big exception — as of November 2 it still has no fixed kernel to install. Here is where your distribution stands, how to check a server in five minutes, and the vendor-backed mitigation for the servers you cannot patch yet. In 30 seconds - CVE-2026-98432 is a race condition in the Linux kernel's IPv4 TCP handshake that leads to a use-after-free. It exists in every kernel from 4.4 until the fix. IPv6 is not affected by the main bug. - Patched: RHEL 8/9/10, AlmaLinux, Rocky Linux, Debian, Oracle Linux, SUSE (some releases), Proxmox 7.0 kernels and Amazon Linux 2023's newer kernels. Not yet: Ubuntu, Amazon Linux 2, the RHEL 9 real-time kernel and OpenShift. A patch only counts after a reboot. - Mitigation: Red Hat and AlmaLinux publish the same stopgap — drop incoming IPv4 TCP packets that carry IP options. Turning off multipath TCP (MPTCP) closes the path Anthropic's exploit used, but is not enough on its own. Contents: CVE-2026-98432 patch status by distribution · What the flaw actually is · Why the scores disagree · Where a multipath TCP listener comes in · Who should worry first · Check a server in five minutes · CVE-2026-98432 mitigation while you wait · What not to do · Your week, in order · Seven questions, answered straight CVE-2026-98432 patch status by distribution As published by the vendors between October 29 and November 2, 2026. Install the fixed kernel, reboot, then confirm uname -r shows the new version: Distribution Status Fixed package or advisory Ubuntu 16.04 to 26.10, including cloud kernels Not fixed — vulnerable, fix in progress No USN yet RHEL 8, 9, 10 Fixed (November 1) RHSA-2026:93414 / 93412 / 93413 · kernel-4.18.0-553.182.1.el8_10 / 5.14.0-687.64.1.el9_8 / 6.12.0-211.72.1.el10_2 RHEL 9 real-time kernel, OpenShift Not fixed as of November 1 Bulletin RHSB-2026-016 AlmaLinux 8, 9, 10 Fixed (November 2) ALSA-2026:93414 · same kernel versions as RHEL Rocky Linux 8, 9, 10 Fixed kernel-4.18.0-553.180.1.el8_10.0.1 / 5.14.0-687.61.1.el9_8.0.1 / 6.12.0-211.69.1.el10_2.0.1 Debian 13 (trixie) Fixed linux 6.12.113-1 (DSA-6568-1) Debian 12 (bookworm) Fixed linux 6.1.190-1 (DLA-4841-1) · linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) Proxmox VE and Proxmox Backup Server Fixed in the 7.0 kernel; 6.8, 6.14 and 6.17 not fixed as of October 30 proxmox-kernel 7.0.14-25-pve or later Amazon Linux 2023 (AWS), kernel6.18 / kernel6.12 Fixed ALAS2023-2026-3251 / ALAS2023-2026-3335 Amazon Linux 2 and the Amazon Linux 2023 kernel package Pending None released Oracle Linux 7–10, UEK kernel Fixed ELSA-2026-500397 / 500398 / 500399 SUSE Linux Micro 6.2, openSUSE Leap 16.0 Fixed kernel-default 6.12.0-160000.40.1 or later SLES 15 SP4–SP7, SLES 16.0 In testing or in progress None released RHEL 7 Not affected Not needed Ubuntu Every supported release, from 16.04 to 26.10, is listed as vulnerable with the fix in progress, cloud, FIPS and real-time kernels included. Canonical has not given a date and there is no Ubuntu Security Notice yet. Until one appears, apply the mitigation below, keep unattended-upgrades on for security updates, and plan the reboot for the day the USN lands. To see whether your running kernel's package mentions the fix, read the linux-modules-… changelog shown in the five-minute check. RHEL, Rocky Linux and AlmaLinux Red Hat shipped fixed kernels for RHEL 8, 9 and 10 on November 1. AlmaLinux moved the same versions into its production repositories on November 2, and Rocky Linux published its own fixed kernels in production. Run dnf upgrade, reboot, and check uname -r against the table. Red Hat's real-time kernel for RHEL 9 and OpenShift were still waiting as of November 1; use the mitigation there. Proxmox VE and Proxmox Backup Server The Proxmox kernel is built from Ubuntu's kernel source, but Proxmox confirmed on its support forum that its 7.0 kernel carries the fix from 7.0.14-25-pve onward, in the enterprise, no-subscription and test repositories. The older 6.8, 6.14 and 6.17 series had no fixed build as of October 30. Use apt full-upgrade, not plain apt upgrade, then reboot: # 7.0.14-25-pve or newer has the fix uname -r pveversion -v | grep -i kernel # A pinned kernel keeps booting the old one proxmox-boot-tool kernel list LXC containers share the host's kernel, so they are covered once the host runs a fixed kernel. Virtual machines run their own kernels and need their own distribution's fix. In a cluster, migrate guests and reboot nodes one at a time. AWS and Amazon Linux Amazon Linux 2023's kernel6.18 and kernel6.12 packages are fixed. Amazon Linux 2 and the default Amazon Linux 2023 kernel package were still pending. EC2 instances that run Ubuntu, RHEL or Debian follow those vendors' status, not Amazon's. Building your own kernel The fix is in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel's CVE team recommends moving to the latest stable kernel and does not support cherry-picking the single fix. What the flaw actually is Every TCP connection starts with a handshake: the client sends a connection request (a SYN), the server answers, the client confirms. An IPv4 packet can carry optional extras in its header, called IP options. When a connection request carries them, the kernel keeps a copy so it can use them in its reply. The bug is in what happens to that copy. When the connection is completed, the kernel hands the stored options to the new socket without duplicating them. If that socket is torn down while another CPU is still using the same options to answer a resent connection request, the kernel reads memory it has already freed. That is a use-after-free, and in kernel networking code it can mean leaked memory, corrupted memory, or a crash. A second, similar path exists when the kernel migrates pending connections between listening sockets (net.ipv4.tcp_migrate_req=1, off by default). IPv6 does not have the main problem because the kernel copies options for IPv6 connections. The timeline: the bug arrived in Linux 4.4. Kernel developers applied the fix on October 5, 2026, the CVE was announced on October 15, and the 9.8 score was added on October 24. Anthropic described its exploit on October 27, Red Hat raised its rating to Critical on October 30 and shipped fixes on November 1. Why the scores disagree You will see different numbers for the same CVE, and it matters for how your vendor prioritises it: Who Score Why Linux kernel CVE team (CNA) 9.8 Critical Attack complexity rated low: both sides of the race are attacker-induced. Red Hat 9.8 Critical (since October 30) Raised from Moderate 5.9: no privileges, no user interaction, standard IPv4 TCP traffic. Oracle, SUSE 8.1 Important Same vector as the kernel team except attack complexity, rated high. Amazon 7.0 Important — The 9.8 assumes an attacker sends a connection request carrying IPv4 Record Route or Timestamp options, then resends it to win the race. Anthropic's write-up adds the detail that changes the risk calculation: a lost race only fails that one connection attempt and does not crash the server, so an attacker can keep trying. In its test, leaking a kernel address took 48 minutes and reaching command execution took five more. Anthropic's claims have not been independently verified, but for an internet-facing server we treat this as urgent whichever number your vendor prints. Where a multipath TCP listener comes in MPTCP lets one connection use several network paths at once. On Linux, an application has to ask for it when it opens a socket. Anthropic's root exploit, which it says its AI model Claude wrote after initial prompting, targeted servers with an MPTCP listener. Neither the CVE record nor the kernel fix mentions MPTCP; that link comes only from Anthropic's post. Two details make this more than a footnote. First, since Go 1.24, Go programs ask for MPTCP by default on the sockets they listen on, so a server can have MPTCP listeners nobody configured on purpose. Second, the Go Security Team says the underlying bug is not specific to MPTCP, and Red Hat describes the affected surface as any system accepting inbound IPv4 TCP connections. No MPTCP listener means the published exploit path is closed, not that you are safe. Who should worry first - Internet-facing Ubuntu servers. There is no fixed kernel yet, so the mitigation is all you have until the USN ships. - Patched servers that have not rebooted. On RHEL, Rocky, AlmaLinux, Debian and Proxmox the fix is out, but the old kernel keeps running until the reboot. - Servers running Go services. Reverse proxies, API gateways, agents, Kubernetes components and internal tools written in Go may be listening with MPTCP without anyone choosing it. - Hosts with TCP ports open directly to the internet. If the server is only reachable through a proxy or load balancer that ends the TCP connection, the connection requests your kernel sees come from that proxy, not from the attacker. That only helps if the server's own IP address is not reachable directly as well. - Container hosts. Containers share the host's kernel, so rebuilding images does nothing for this CVE. They also have their own network namespaces, which matters for both parts of the mitigation below. Check a server in five minutes No extra tools needed. Run these on each server, not on your laptop: # Running kernel; on Debian, uname -v shows the package version uname -r uname -v # Ubuntu: does the running kernel's changelog mention the fix? apt changelog linux-modules-$(uname -r) 2>/dev/null \ | grep -c CVE-2026-98432 # RHEL, Rocky, AlmaLinux, Oracle Linux rpm -q --changelog kernel-$(uname -r) | grep -c CVE-2026-98432 # Newest installed kernel (reboot pending if newer than uname -r) ls -1 /boot/vmlinuz-* | sort -V | tail -1 # MPTCP and the secondary migration path sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req # Services listening with MPTCP ss -lnpM - Kernel version: compare uname -r with the table above. Distribution kernels keep their base version and backport fixes, so for those the vendor's tracker and package changelog are what count. - Changelog: on Ubuntu, read the changelog of linux-modules-…. The linux-image-… changelog comes from the signed package and does not list CVEs, so searching it always finds nothing. A count of 0 means the running kernel's package does not mention the fix. - Reboot pending: if the newest kernel in /boot is newer than uname -r, a fix may be installed but not running. - MPTCP: net.mptcp.enabled = 1 plus any line from ss -lnpM means the published exploit path is open in that network namespace. tcp_migrate_req should be 0. CVE-2026-98432 mitigation while you wait Red Hat and AlmaLinux both publish the same interim control, and both say the same thing about it: it reduces exposure, it is not a substitute for the patched kernel, and you should test it first. Step 1: drop incoming IPv4 TCP packets that carry IP options The bug can only be triggered by a connection request that carries IPv4 options. The kernel source shows why: the options that get freed too early are only stored when the incoming SYN actually has them. Ordinary TCP options (window scaling, timestamps, SACK) live in the TCP header, not the IP header, so normal traffic is unaffected. The filter matches the IPv4 header length: anything longer than the basic 20 bytes carries options. We use AlmaLinux's form because it hooks prerouting, so it also covers traffic forwarded to containers and virtual machines. Red Hat's bulletin gives an equivalent rule on the input hook, which does not see forwarded traffic. Save this as /etc/cve-2026-98432.nft: 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 } } The first two lines make the file safe to load more than once. Check it, load it, and watch the counter: # Dry run first, then load and check the counter (should stay 0) nft --check -f /etc/cve-2026-98432.nft nft -f /etc/cve-2026-98432.nft nft list table ip cve_2026_98432 A rule loaded by hand disappears on reboot. To keep it, save this as /etc/systemd/system/cve-2026-98432-stopgap.service and enable it. If you already manage rules through nftables.service, add the table to that configuration instead, because reloading it flushes tables it does not know about. [Unit] Description=CVE-2026-98432 stopgap: drop IPv4 TCP with IP options After=network-pre.target Before=network.target docker.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft ExecStop=/usr/sbin/nft delete table ip cve_2026_98432 [Install] WantedBy=multi-user.target systemctl daemon-reload systemctl enable --now cve-2026-98432-stopgap On hosts that only use iptables, this is the equivalent rule in the raw table: iptables -t raw -I PREROUTING -p tcp \ -m u32 --u32 "0>>24&0x0F=6:15" -j DROP Know its limits before you rely on it. It covers IPv4 only, which is where the main bug is. It breaks networks that depend on CIPSO/NetLabel security labels, which use IP options. And traffic between containers on the same host may never pass through the host's prerouting hook, so it can bypass the filter. Step 2: turn off multipath TCP This closes the path Anthropic's exploit used, without a reboot, and the file keeps it after one: echo 'net.mptcp.enabled=0' > /etc/sysctl.d/90-disable-mptcp.conf sysctl -w net.mptcp.enabled=0 # Anything still listed was opened earlier: restart that service ss -lnpM Services that were already listening with MPTCP keep it until they restart. Go programs fall back to plain TCP on their own when MPTCP is off. Note that this setting belongs to a network namespace: the commands above cover the host, not your containers or pods. Check inside each one, for example with nsenter -t -n ss -lnM, or set it through your container runtime or pod sysctl configuration. For Go services you can also set GODEBUG=multipathtcp=0 in their environment, but the Go team calls per-program switches fragile: one forgotten listener leaves the server exposed, and code that calls SetMultipathTCP overrides it. On its own, step 2 is not enough, because the bug is not limited to MPTCP. Use it alongside step 1, not instead of it. Optional hardening: init_on_free=1 A suggestion on the oss-security list adds the init_on_free=1 boot parameter, which zeroes memory when it is freed. It does not fix the bug, but it narrows what an attacker can read through it. It needs a reboot and has a commonly cited cost of 1 to 5% on workloads that free a lot of memory, so measure it on yours. Undoing it after the patch Once uname -r shows a fixed kernel: # or: nft delete table ip cve_2026_98432 systemctl disable --now cve-2026-98432-stopgap rm /etc/sysctl.d/90-disable-mptcp.conf sysctl -w net.mptcp.enabled=1 What not to do - Do not read "no MPTCP" as "patched". A server that answers over plain TCP has closed one exploit path. The bug is still in its kernel. - Do not stop at the package manager. An installed kernel that has not been booted protects nothing. On Proxmox, also check that no old kernel is pinned. - Do not patch containers and call it done. They run on the host's kernel. - Do not rely on an input-hook filter on a container host. Forwarded traffic never reaches that hook; use prerouting. - Do not remove the mitigation early. Wait until the patched kernel is the one running. - Do not cherry-pick the fix into an old kernel. The kernel team does not support it; move to a fixed stable release or your vendor's package. Your week, in order - Today: list every internet-facing Linux server, Proxmox node and VM, with its distribution and uname -r. - Today: where a fix exists (RHEL, Rocky, AlmaLinux, Debian, Oracle Linux, SUSE, Proxmox 7.0, Amazon Linux 2023's newer kernels), install it and schedule the reboot. - Today: on Ubuntu and anything else still waiting, load the IP-options filter, test that every published service still answers, and make it persistent. - This week: turn off MPTCP where you do not need it, including inside containers, and restart services that were listening with it. - When Ubuntu ships: install, reboot, confirm uname -r, then remove the mitigation. Seven questions, answered straight Is there a CVE-2026-98432 patch for Ubuntu? Not yet. As of November 2, Ubuntu lists every supported release as vulnerable with the fix in progress and has not published a security notice. Use the mitigation above and watch Ubuntu's CVE page. Which kernel versions fix CVE-2026-98432? 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. Distribution kernels use their own version numbers, so check the table above or your vendor's advisory rather than the upstream number. Is IPv6 affected? Not by the main bug: the kernel copies options for IPv6 connections. The fix notes a related IPv6 migration issue that only applies when CALIPSO labelling is in use, and says it will be fixed separately. Has it been exploited in the wild? None of the vendor advisories, the CVE record, or Anthropic's post reports attacks, and as of October 29 the CVE was not in CISA's Known Exploited Vulnerabilities catalogue. Anthropic did not publish its exploit code. That buys time, not safety: the method is now described in public, and a lost race leaves little trace beyond a failed handshake. We do not use MPTCP. Are we safe? Not necessarily. Go programs turn it on for listeners by default since Go 1.24, so check with ss -lnpM rather than assuming. And the Go Security Team says servers with no MPTCP listener may be vulnerable to similar attacks. Do updated container images fix it? No. Containers use the host's kernel. Patch and reboot the host. Do we really have to reboot? Yes, unless your vendor ships a live patch for it. The fix is in the kernel, and the running kernel only changes when the server boots into the new one. Related reading - [What Is a CVE Vulnerability?](https://amensecurity.ca/en/blog/what-is-a-cve) — how CVE numbers, scores and vendor ratings fit together, and why they disagree. - [Node2Shell (CVE-2026-111497)](https://amensecurity.ca/en/blog/node2shell-nodejs-brotli-rce-october-2026) — the October flaw that hid in every bundled copy of a library. - [PHP2Shell: the 15-minute check for your website](https://amensecurity.ca/en/blog/php2shell-critical-php-vulnerability-canada-2026) — the same-month web-stack story, and its quick check. Patch where you can, filter where you can't If you take one thing from this: the fix for CVE-2026-98432 is a kernel you have rebooted into. For most distributions that kernel exists now, so the work is scheduling reboots. For Ubuntu it does not exist yet, so put the filter in front of those servers and keep a list of what to reboot the day the update arrives. If you would rather not work through the list alone, [our free assessment](https://amensecurity.ca/en/contact?tab=consult&utm_source=blog&utm_medium=site&utm_campaign=linux-kernel-tcp-flaw-cve-2026-98432) will go through your servers with you, and you keep the list either way. The same work is part of [cybersecurity for growing businesses](https://amensecurity.ca/en/services/cybersecurity). Trust box — sources & review - [Linux kernel CVE announcement](https://lists.openwall.net/linux-cve-announce/2026/10/15/1) (October 15, 2026): fix description, introduced in 4.4, fixed stable releases, no-cherry-pick guidance. - Red Hat: [bulletin RHSB-2026-016](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016) and [CVE page](https://access.redhat.com/security/cve/CVE-2026-98432) (Critical, 9.8; input-hook nftables filter), fixed kernels [RHSA-2026:93414](https://access.redhat.com/errata/RHSA-2026:93414) (RHEL 8), [RHSA-2026:93412](https://access.redhat.com/errata/RHSA-2026:93412) (RHEL 9), [RHSA-2026:93413](https://access.redhat.com/errata/RHSA-2026:93413) (RHEL 10), November 1, 2026. - [AlmaLinux](https://almalinux.org/blog/2026-10-30-cve-2026-98432/) (updated November 2: fix in production, ALSA-2026:93414, prerouting nftables filter) · Rocky Linux's official announcement of fixed production kernels · [Proxmox support forum](https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-ve.187339/) (Proxmox staff, October 30: fix in 7.0.14-25-pve and later). - [Ubuntu CVE page](https://ubuntu.com/security/CVE-2026-98432) (updated October 30) and [Security Boulevard](https://securityboulevard.com/2026/11/linux-kernel-tcp-flaw-rated-9-8-gets-a-remote-root-exploit-from-an-ai-model/) (November 2: Ubuntu fix still in progress as of November 1) · [Debian security tracker](https://security-tracker.debian.org/tracker/CVE-2026-98432). - [The Hacker News](https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html) (October 29, updated October 30) and [Cloud Security Alliance research note](https://labs.cloudsecurityalliance.org/research/csa-research-note-linux-tcp-mptcp-cve-2026-98432-20261101-cs/) (November 1): Oracle, SUSE and Amazon status, Go Security Team guidance, filter caveats, MPTCP sysctl scoped per network namespace. - [Anthropic Frontier Red Team](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude) (October 27, 2026): exploit against servers with an MPTCP listener; lost races only fail one handshake; 48 + 5 minutes in its test. - [oss-security](https://openwall.com/lists/oss-security/2026/10/31/5) (October 31, 2026): init_on_free=1 as additional hardening. Linux source tcp_v4_save_options(): options stored only when the SYN carries them. Both nftables rules above pass nft --check. - Reviewed: November 2, 2026. From Amen Security, a Winnipeg-based managed IT and web & app development team serving Canadian and US small and mid-sized businesses. No services, prices, partnerships, or certifications are claimed in this post beyond what the live site proves. ## Topic: Cybersecurity & compliance - [Main guide](https://amensecurity.ca/en/services/cybersecurity.md) - [Managed IT vs Break-Fix: Side-by-Side Comparison](https://amensecurity.ca/en/guides/msp-vs-break-fix.md) --- Source page: https://amensecurity.ca/en/blog/linux-kernel-tcp-flaw-cve-2026-98432 Markdown version for AI agents · Amen Security Email: info@amensecurity.ca Phone: +1 (204) 514-3536