Critical Linux Kernel Flaw: What to Check on Your Server

A flaw in the Linux kernel, CVE-2026-98432, lets an attacker with no account corrupt a server's memory over IPv4 TCP connections and, in some setups, run commands as root. It affects the servers that host websites. Debian has shipped a fix; as of October 30, 2026, Ubuntu and Red Hat had not.

What we know

What it is: a memory bug (a use-after-free caused by a race condition) in the kernel code that sets up IPv4 TCP connections, according to the CVE description carried by Ubuntu and Debian. Debian's tracker says IPv6 is not affected by the main path.
Severity: Ubuntu and Red Hat score it 9.8 out of 10 (CVSS 3.1). Red Hat rates it «Critical» for RHEL. It says an unauthenticated remote attacker can corrupt kernel memory or crash the system, and that reliable code execution needs precise control of memory.
The demonstration: Anthropic said on October 27 that an unreleased internal research model built an exploit that runs commands as root, with no credentials or user interaction, against servers with a Multipath TCP (MPTCP) listener. Per Anthropic, leaking a kernel pointer took 48 minutes and running the command about five more. It has not released the code.
Since when: according to TuxCare, the bug arrived with kernel 4.4 in January 2016. Ubuntu lists every release from 16.04 onward as vulnerable.
The fix: the patch is in the mainline kernel and, per Anthropic, was backported to all maintained stable branches. Debian ships it in its 6.1.190 and 6.12.113 kernels.
Debian: Debian 12 and 13 have fixed kernels (DLA-4841-1, DLA-4850-1 and DSA-6568-1), per its security tracker.
Ubuntu: its CVE page, updated October 30, lists every release as vulnerable: 22.04, 24.04, 26.04 and 26.10 have a fix «in progress»; 16.04, 18.04 and 20.04 show none.
Red Hat: its CVE page lists RHEL 8, 9 and 10 as affected, with no update yet (RHEL 7 is not affected), and points to bulletin RHSB-2026-016 for mitigation. According to TuxCare, Oracle Linux (UEK), SUSE and part of Amazon Linux 2023 are already patched.
Attacks: none of the sources checked reports real-world exploitation as of October 30.

What changes and what doesn't

It changes things if you run your own Linux server (a VPS, a dedicated box or a cloud instance): you need a new kernel and a reboot. Installing the package without rebooting leaves the old kernel running.
It is not only about MPTCP: Anthropic's demo used MPTCP, but Red Hat describes memory corruption or crashes over ordinary IPv4 TCP traffic. According to TuxCare, RHEL and its rebuilds ship with MPTCP disabled, while programs built with Go 1.24 or later enable it by default when they listen for connections.
Nothing changes on shared or managed hosting: the provider controls the kernel.
Your CMS is not involved: WordPress, Drupal, PHP and plugins have nothing to do with it; this is the server's operating system.

How to tell if you're affected

Work out who owns the server. If your site runs on a VPS, a dedicated server or a cloud machine, the kernel is yours. On shared hosting, skip to step 5.
Check the kernel version with `uname -r` in a terminal on the server, and note your distro and release.
Open your distro's CVE page (links below). Debian has a package; Ubuntu and RHEL did not as of October 30, so check again over the next few days.
When the package lands, install it and reboot in a low-traffic window. Until then, follow your distro's official mitigation (on RHEL, bulletin RHSB-2026-016). `sysctl net.mptcp.enabled` tells you whether MPTCP is on (1) or off (0).
On shared or managed hosting, ask your provider: «Are your servers running a kernel with the fix for CVE-2026-98432? If not, what mitigation have you applied?»
Don't forget the rest: staging and test servers count too. Containers such as Docker use the host's kernel, so the host is what needs the update.

Sources

Updates: when Ubuntu or Red Hat ship a fixed kernel, or if attacks are confirmed, it will be added here with a link.