CVE-2026-98432: a critical Linux kernel flaw and how to protect your server

On 15 October 2026 the Linux kernel security team published CVE-2026-98432, and a few days later rated it 9.8 out of 10. The flaw sits in the code that accepts new IPv4 TCP connections, the path every visitor to your site takes, along with every SSH session and every request to a database or mail server. An attacker who can reach any open TCP port on an unpatched server can crash it, with no account or password, and Red Hat warns that it could lead to remote code execution. On 27 October Anthropic announced that one of its research models had written an exploit that gains root on servers listening for Multipath TCP connections. No attack had been reported as of 5 November, but the fix has been public for weeks, and anyone who reads it knows where the flaw is. This article covers what happened, how the flaw works, who is affected, where each distribution’s fix stands, and how to update your server or shield it until the update arrives.

01What happened, and when

The story did not start with an emergency announcement, but with a small fix to the kernel source that came weeks before the warnings:

The irony is that the fix came weeks before the warning, and still most servers had not taken it. A published fix is also a map for attackers: they read what changed in the code and learn where to strike, while a server that has not been updated and rebooted keeps running the old code.

02How the flaw works

Every TCP connection starts with a three-step handshake: the client sends a SYN packet, the server answers with a SYN-ACK, and the client confirms. When the SYN carries IP options, such as Record Route or Timestamp, the server stores them with the connection request so it can build its reply from them.

The flaw lies in the moment those options are handed over. When the handshake completes, the options pass to the new connection without being copied. At the same time, a retransmitted copy of the same SYN may arrive and be handled by another processor in the server, which builds a fresh reply from it. If the new connection is closed and frees the options at that very moment, the other processor reads memory that has just been freed. This is a use-after-free, a well-known route to crashing a system, leaking its memory or taking control of it.

The flaw entered the kernel in version 4.4 in early 2016, when connection requests began to be processed without locking the listening socket, so a server could accept more connections on more processors. The same flaw has a second path when connection request migration between sockets is turned on with the net.ipv4.tcp_migrate_req setting, which is off by default. The fix itself is simple: the kernel now waits until everyone reading the options has finished before it frees them.

What makes the flaw dangerous is that an attacker loses nothing by failing: an attempt that loses the race only fails the handshake, so they can try again and again. In Anthropic’s test the exploit took 48 minutes to leak an address from kernel memory, then another 5 minutes to run a command as root.

Where does Multipath TCP come in?

Multipath TCP is an extension that lets a single connection use more than one network path at once. The exploit Anthropic described targeted servers with a program listening for MPTCP connections, but the flaw itself is not in MPTCP; it is in ordinary TCP. That is why Red Hat says having no MPTCP listeners on your server is information, not reassurance, and that disabling MPTCP is not enough on its own. Note also that programs written in Go turn MPTCP on for Linux listening sockets by default from Go 1.24, according to the Go security team.

03Who is affected

Every Linux server on kernel 4.4 or newer, which means almost every supported distribution, as long as it accepts IPv4 TCP connections on any port: a website, SSH, a database or mail. What decides the risk is the kernel version, not the software on top of it, so an up-to-date control panel or web server does not protect you. Watch for three cases:

• Systems that are not affected: RHEL 7, CentOS 7 and CloudLinux 7 (non-hybrid), because they run kernel 3.10, which predates the flaw. Windows, FreeBSD and other non-Linux systems are not affected either.
• A KVM virtual server: A KVM server runs its own kernel, separate from the host’s. Your provider updating its servers does not update yours, so you have to update the kernel inside it and reboot it yourself.
• Containers: Docker and LXC containers, including Proxmox containers, run on the host’s kernel, so updating packages inside a container changes nothing. Update the host’s kernel and reboot it.

04Where the fix stands

This is where the fix stood in common distributions as of 5 November 2026. Find yours, then follow the step that matches its status:

• Fix released: Take a backup, update the kernel and reboot the server today.
• Rolling out or in testing: Apply the temporary protection now, and update once the fix reaches the stable repository.
• Not yet released or no fix: Apply the temporary protection now. If your release has reached end of life, no free fix will come: plan your move to a supported release.

05Update the kernel and reboot

Before anything else, take a backup or a snapshot of the server: a kernel update means a reboot, and a server that does not come back up is a bigger problem than one that was not updated. Then update with your distribution’s commands:

# Debian 12 and 13, Proxmox VE, and Ubuntu once its fix is releasedsudo apt update && sudo apt full-upgradesudo reboot# RHEL 8, 9 and 10, AlmaLinux, Rocky Linux and CloudLinux: has the fix reached your repositories?sudo dnf --refresh updateinfo info --cves CVE-2026-98432sudo dnf update 'kernel*'sudo reboot# openSUSE and SLESsudo zypper refresh && sudo zypper patch && sudo reboot

If your server runs CloudLinux, it has two more routes: take the patched kernel before its staged rollout completes, or apply the fix through KernelCare, which provides live patching. KernelCare has released the patch for this flaw for CloudLinux 7h, 8, 9 and 10, so it protects the running kernel without a reboot:

# CloudLinux 7h and 8: the patched kernel before its rollout completes, as CloudLinux advisessudo yum update cloudlinux-releasesudo yum update kernel --enablerepo=cloudlinux-rollout-3-bypasssudo reboot# KernelCare: the patch on the running kernel without a reboot, then check itsudo kcarectl --updatesudo kcarectl --patch-info | grep CVE-2026-98432

Updating alone is not enough: the new kernel is installed on disk, and the server keeps running the old one until you reboot. So after the reboot, make sure the server came up on the new kernel and that it carries the fix:

# The kernel the server is running nowuname -r# RHEL, AlmaLinux, Rocky Linux and CloudLinux 8 and later: a number above 0 means the running kernel is patchedrpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432# Debian: the package version is at the end of the line. The fix is in 6.1.190-1 or 6.12.113-1~deb12u1 for Debian 12, and 6.12.113-1 for Debian 13, or neweruname -v

ProblemI updated the kernel and uname -r still shows the old version

FixYou have not rebooted the server yet, or the boot loader picked another kernel. Reboot, and if it happens again, check the default kernel in the GRUB configuration.

Problemdnf finds no update for this flaw

FixThe fix has not reached your repositories yet, or your repository metadata is stale. Run sudo dnf clean metadata and try again, and if it still has not arrived, apply the temporary protection.

ProblemMy provider updated its servers and my virtual server still runs the old kernel

FixA KVM server runs its own kernel, so updating it is your job inside it: update the kernel and reboot.

ProblemI updated the packages inside a Docker container and it is still exposed

FixThe container runs on the host’s kernel, not on a kernel of its own. Update the host’s kernel and reboot it.

ProblemThe nftables rule disappeared after a reboot

FixA rule loaded with the nft command does not survive a reboot. Add an include line to the nftables configuration file and enable its service, as in the next section.

06If the fix has not arrived: temporary protection

The flaw needs a SYN packet that carries IP options, and ordinary connections do not use these options. If you drop inbound IPv4 TCP packets that carry IP options, you take away the input the attacker needs. An IPv4 header without options is 20 bytes long, that is 5 words of 4 bytes, so any length above 5 means the packet carries options. Red Hat published this rule in its bulletin RHSB-2026-016 and advises testing it against your own server’s traffic before relying on it. The usual TCP options are not affected, because they live in the TCP header, not the IP header.

# Save the rule in /etc/nftables.d/cve-2026-98432.nftsudo mkdir -p /etc/nftables.dsudo tee /etc/nftables.d/cve-2026-98432.nft >/dev/null <<'EOF'table inet cve_2026_98432 {    chain input {        type filter hook input priority -310; policy accept;        ip protocol tcp ip hdrlength > 5 counter drop    }}EOF# Check the file, load it, then list the table and its countersudo nft --check --file /etc/nftables.d/cve-2026-98432.nftsudo nft --file /etc/nftables.d/cve-2026-98432.nftsudo nft list table inet cve_2026_98432

• The rule works at once: It applies to new and existing connections, so no service needs a restart. The counter in the last command’s output tells you how many packets were dropped: if it climbs, someone is sending your server packets with IP options.
• If your server routes traffic to Docker or LXC containers: Change the input hook to prerouting, so packets headed for the containers also pass through the rule.
• Do not apply it on CIPSO or NetLabel networks: These systems carry security labels in the IP options themselves, so the rule would cut their connections.
• To keep the rule after a reboot: Add the line include "/etc/nftables.d/cve-2026-98432.nft" to /etc/nftables.conf on Debian and Ubuntu, or to /etc/sysconfig/nftables.conf on the RHEL family, then run sudo systemctl enable nftables. Note that stopping the nftables service later wipes the rule, so load it again if you stop it.

If your server runs iptables only, this rule does the same job, dropping TCP packets whose header is longer than 5 words:

# iptables: TCP packets with an IPv4 header longer than 20 bytessudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0x0F=6:15" -j DROP

And if you do not use Multipath TCP, turn it off to close the route the known exploit took. The setting applies to new sockets only, so programs started before it keep listening with MPTCP until you restart them:

# Turn MPTCP off now, and make the setting permanentsudo sysctl -w net.mptcp.enabled=0echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-cve-2026-98432.conf# Restart every service listed here until the output is emptysudo ss -lnMp# Connection request migration opens the flaw’s second path: the value should be 0sysctl net.ipv4.tcp_migrate_req

Turning MPTCP off narrows the attack but does not remove the flaw, because the flaw is not specific to MPTCP, so do not rely on it instead of the firewall rule.

07If you are an Illevante customer

What you do depends on your service:

• A CoreVPS server: It runs on KVM with its own kernel, separate from our host servers’ kernel, so updating our servers does not update yours. Update the kernel inside your server and reboot it as in the steps above, taking a backup first. Off-server backup is available for CoreVPS servers.
• CoreVPS with cPanel: You can add a monthly KernelCare licence to your server, so kernel security patches reach it without a reboot.
• cPanel hosting: The server’s kernel is our responsibility, not yours: your account has no access to change it, and your site needs no action from you. Our hosting servers run CloudLinux with KernelCare.
• If you need a hand: Our technical support team is with you around the clock if you need help with the update or with applying the temporary protection.

08After this flaw

This will not be the kernel’s last flaw. Three habits make the next one easier:

1. 01A fixed time for reboots: A kernel update does not protect you until you reboot. Set a regular maintenance window for rebooting your servers, or rely on live patching where it is available.
2. 02A supported release: CentOS 8, Debian 11, Ubuntu 20.04 and older get no free fixes. Plan your move now, not when the next flaw lands.
3. 03An inventory of running kernels: Know, for every server and container host, which kernel version is running now, not just which is installed, because that is what decides whether you are protected.

And subscribe to your distribution’s security announcements, which are the first to tell you a fix is out, before you read about it in the news.