Sadeem IT Solutions
30 Oct 2026

Root over TCP: Linux kernel flaw CVE-2026-98432 – Debian patched, Ubuntu and RHEL still waiting

A race condition in the Linux kernel's TCP code can, in the worst case, let attackers take over servers without logging in. What it means for Debian, Ubuntu, RHEL and Proxmox – and what to do now.

linux-kernel-tcp-luecke-cve-2026-98432

A flaw in the Linux kernel's networking code can, under certain conditions, let attackers take over a server remotely – without a password and without any user interaction. The vulnerability CVE-2026-98432 has been in the code since kernel 4.4, which means it affects practically every Linux server of the last ten years. Debian has already shipped updates, but as of 30 October there is still no finished patch for Ubuntu or Red Hat Enterprise Linux. Here is what this means for your servers and what you should do now.

What happened

The bug sits in the setup of IPv4 TCP connections – the step that starts every connection to a web server, database or mail server. When several CPU cores process the same connection request at the same time, the kernel can free a piece of memory that is still in use (a so-called use-after-free race condition). Carefully timed network packets can exploit this.

Kernel developers fixed the bug in early October, and the CVE was published on 15 October. The case drew attention at the end of October when the AI company Anthropic reported that its model Claude had built a working attack in a lab environment. Against a server with Multipath TCP (MPTCP) enabled, it took about 48 minutes to leak a kernel pointer and another five minutes to run commands as root. A failed attempt does not crash the server, so an attacker can simply keep trying.

How dangerous is it? Ratings differ:

  • Kernel CVE team (and NVD): CVSS 9.8 – critical
  • Red Hat and SUSE: 8.1 – high, because Red Hat considers exploitation difficult
  • Ubuntu: priority "High"

No active attacks have been reported so far, and the flaw is not in CISA's catalogue of exploited vulnerabilities. But the fact that an AI wrote the exploit shows one thing clearly: the window between disclosure and the first attack is getting shorter.

Who is affected

In principle, any Linux machine with an IPv4 TCP service reachable over the network – web servers, databases, SSH, mail servers, container hosts and virtualisation hosts. Patch status as of 30 October 2026:

  • Debian 13 (trixie): fixed in linux 6.12.113-1 (DSA-6568-1)
  • Debian 12 (bookworm): fixed in linux 6.1.190-1, for the 6.12 kernel in 6.12.113-1~deb12u1
  • Ubuntu 22.04, 24.04, 26.04 LTS and 26.10: fix in progress, not yet released; older releases (16.04–20.04) listed as vulnerable
  • RHEL 8, 9 and 10: affected, no fix available yet according to Red Hat
  • Oracle Linux (UEK): fixed; Amazon Linux 2023 and SUSE partly fixed
  • Proxmox VE: careful – Proxmox does not use the Debian kernel but its own Ubuntu-based kernel. The Debian update alone therefore does not protect a Proxmox host. According to the Proxmox community, kernels from 7.0.14-25-pve onwards (no-subscription and test repositories) contain the fix; official confirmation from Proxmox was still pending at the time of writing.

Fixed upstream kernels are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Note that distributions backport fixes under their own version numbers, so your vendor's security advisory is always what counts.

What you should do now

  1. Take inventory: Run uname -r and cat /etc/os-release on every server and note which systems are reachable from the internet (ss -lntp lists open services).
  2. Update Debian systems now: apt update && apt full-upgrade, then reboot – without a reboot the old kernel keeps running.
  3. Check Proxmox hosts: If a host runs a kernel older than 7.0.14-25-pve, schedule the update and migrate VMs first or plan a maintenance window. Subscription customers should confirm the status with Proxmox support.
  4. Watch Ubuntu and RHEL: Check the Canonical and Red Hat security pages daily and install the update as soon as it appears. Automatic security updates (e.g. unattended-upgrades) help, but the reboot still has to be planned.
  5. Reduce the attack surface: Only expose services to the internet that really need to be there; put admin access such as SSH or databases behind a VPN or firewall rules.
  6. Consider a stopgap: If you do not need MPTCP, you can disable it with sysctl -w net.mptcp.enabled=0. The published attack targeted MPTCP, but it is not proven that this alone fully protects you, and Red Hat has not found any workaround sufficient so far. The kernel update remains the only reliable protection.
  7. Don't forget templates: Update VM templates, container base images and cloud images so no new vulnerable systems are created.

How Sadeem helps

We run Linux servers, container platforms and Proxmox clusters for small and mid-sized companies – in data centres in Germany and the EU. As part of our managed hosting we handle inventory, kernel updates with planned reboots, live migration of VMs and monitoring, so that flaws like this are closed without downtime. Not sure whether your servers are affected? In a free initial consultation we will review your setup together.

Sources

SecurityLinuxProxmoxCVE