CVE-2026-98432: The Linux TCP Kernel Flaw and How to Patch It

On 15 October 2026 the Linux kernel's security team published CVE-2026-98432, a bug in the code every Linux server uses to accept new IPv4 TCP connections. If your website, online shop, API or email runs on a Linux server or VPS, this deserves an hour of your time this week.

Last updated: 3 November 2026. Patch status changes quickly, so confirm on your distribution's security page.

In short: Install your distribution's fixed kernel and reboot. Debian, Red Hat Enterprise Linux 8, 9 and 10, and Amazon Linux already ship fixes. Ubuntu's fixes for 22.04 and newer are still in testing. Until you can patch, turning off MPTCP lowers the risk but does not remove it. On shared hosting, ask your host the questions below.

What CVE-2026-98432 is, in plain English

When someone connects to your server, the kernel (the core of the operating system) keeps a short-lived record of the half-open connection while the handshake completes. If the incoming request carries optional extra IPv4 header fields, called IP options, the kernel stores them with that record.

The bug is a timing problem. Under the right conditions, one part of the kernel frees that stored data while another part, running at the same moment on a different CPU core, is still using it. This is a use-after-free: the kernel touches memory it no longer owns. The official CVE record says the result can be a crash, kernel memory leaking back to the attacker, or memory corruption that could let an attacker run code.

Why it matters:

It can be triggered remotely, before any login, against any service listening on IPv4 TCP: web, SSH, mail or a database.
The flaw has existed since Linux 4.4, so nearly every server kernel in use is in scope.
The researchers who reported it (Anthropic) say they built an exploit that runs commands as root on servers with an MPTCP listener. It has not been released. As of 2 November, Akamai, Sophos, AWS and Canonical all said they knew of no public exploit or attacks in the wild.

Two different severity scores

Source	Score
Linux kernel CNA (official CVE record)	CVSS 3.1: 9.8, Critical
Red Hat	5.9 per Sophos (2 Nov), as an attacker must win a race; Red Hat's CVE page now lists 9.8, Critical
Ubuntu	High priority; CVSS 3.1 9.8 and CVSS 4.0 8.3

Either way, treat internet-facing Linux servers as urgent.

Who is affected

Kernels from 4.4 onward are affected unless they contain the fix. Upstream, the first fixed releases are:

Kernel branch	First fixed version
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
Mainline	7.3

Older branches that no longer get stable updates are affected too.

Watch out: Distribution kernels do not follow these numbers. Ubuntu, Debian and Red Hat backport fixes into their own versions, so an Ubuntu 5.15.0-203 or a RHEL 5.14.0 kernel cannot be compared with the table above. Use your distribution's fixed version instead (see Step 2).

Containers such as Docker and Kubernetes pods share the host's kernel, so the host is what needs patching. The same applies to container-based VPS plans: if your provider runs the kernel, only they can fix it.

The MPTCP and Go 1.24+ angle

Multipath TCP (MPTCP) lets one connection use several network paths. The only exploit described so far targets servers with an MPTCP listener, and that is more common than you might expect: the Go Security Team warned that programs built with Go 1.24 or later enable MPTCP on Linux listening sockets by default. If you run a web server, proxy or API written in Go, it may be listening with MPTCP without anyone choosing that.

Two caveats from the Go team, Red Hat and Canonical: the bug itself is not specific to MPTCP, and Red Hat says servers with MPTCP disabled remain affected. Turning MPTCP off closes the publicly described route; it does not fix the flaw.

To see whether anything is listening with MPTCP:

sudo ss -M -l -n -p

For a Go program, set GODEBUG=multipathtcp=0 in its environment (or add godebug multipathtcp=0 to the main module's go.mod and rebuild), then restart it. Code that calls SetMultipathTCP directly overrides this setting.

Step 1: check your kernel version

Run:

uname -r

That shows the kernel that is running now, which is what counts. A fixed kernel that is installed but not yet booted does not protect you.

On Debian, uname -v shows the package version (for example "Debian 6.1.190-1"). To list installed kernels, use dpkg -l 'linux-image*' | grep ^ii on Ubuntu or rpm -q kernel on RHEL, AlmaLinux, Rocky and Amazon Linux.

Step 2: patch and reboot

Status as of 3 November 2026:

Distribution	Status	Fixed version
Debian 12 (bookworm)	Fixed (DLA-4841-1)	linux 6.1.190-1, or linux-6.12 6.12.113-1~deb12u1
Debian 13 (trixie)	Fixed (DSA-6568-1)	6.12.113-1
Ubuntu 22.04, 24.04, 26.04 LTS	In testing (-proposed pocket only)	5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43
Ubuntu 26.10	Fixed	7.3.0-10.10
Ubuntu 20.04 and older	Fix pending	Not yet
RHEL 8, 9, 10	Fixed 1 Nov (RHSA-2026:93414, 93412, 93413)	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 6 and 7	Not affected	None needed
Amazon Linux 2 and 2023	Fixed	Kernel updates available now

RHEL 9's real-time kernel (kernel-rt) was still listed as affected. AlmaLinux, Rocky Linux, SUSE and Oracle Linux publish their own advisories; check them.

Debian:

sudo apt update && sudo apt full-upgrade
sudo reboot

RHEL, AlmaLinux, Rocky Linux:

sudo dnf update kernel
sudo reboot

Amazon Linux (commands from the AWS bulletin):

Amazon Linux 2:

sudo yum update kernel && sudo reboot

Amazon Linux 2023 with the default 6.1 kernel:

sudo dnf update kernel --releasever=latest && sudo reboot

Amazon Linux 2023 instances locked to a release need 2023.12.20261102 or later. The bulletin also lists the commands for the 6.12 and 6.18 kernels.

Ubuntu: a normal apt upgrade will not install the fix until Canonical moves it out of testing. Canonical offers the -proposed packages to people who run their own kernel acceptance tests, so for most small businesses the sensible path is: apply the mitigations below, watch the Ubuntu CVE page, and upgrade the day the fix reaches the normal updates. If you do test and want it now, follow Canonical's instructions and take a snapshot first.

After any reboot, run uname -r (or uname -v on Debian) again and compare with the table.

Temporary mitigations (partial only)

Watch out: None of these fix the bug. They reduce exposure while you wait for a patch. Canonical's security team says updates are the only appropriate mitigation.

Disable MPTCP and TCP request migration, as suggested by Akamai:

sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0

To keep the settings after a reboot:

sudo tee /etc/sysctl.d/99-cve-2026-98432.conf <<'CONF'
net.mptcp.enabled = 0
net.ipv4.tcp_migrate_req = 0
CONF
sudo sysctl --system

The first setting closes the MPTCP route the reported exploit uses. The second covers a related path in the bug that only applies when request migration is turned on. If sysctl says a key does not exist, your kernel lacks that feature and the line is not needed.

Red Hat also publishes an nftables rule that drops incoming IPv4 TCP packets carrying IP options. Red Hat says it reduces exposure but cannot fully prevent the attack, and it should be tested before production use:

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

Save it as cve-2026-98432.nft, load it with sudo nft --file cve-2026-98432.nft, and remove it after patching with sudo nft delete table inet cve_2026_98432. Also close any port you do not need, and limit SSH and database ports to known addresses.

On shared or managed hosting? Ask your host

You cannot patch a kernel you do not control. Send your host these questions:

Are the servers running my site on a kernel fixed for CVE-2026-98432, and have they been rebooted or live-patched onto it?
If not, when will they be, and which interim mitigations are in place?
On my VPS, is the kernel mine to update, or yours?
Is a maintenance reboot planned that I should prepare for?

What our scans can and cannot tell you

No remote scan, including Lordevo's, can safely confirm a server's kernel version or whether this bug is patched. You need uname on the server or a clear answer from your host. For your website's wider security, the Safe Scan on pentest.lordevo.com is free and checks what your site exposes from the outside. Our paid Deep Scan goes further. Neither one tests for this CVE.

Key takeaways

Run uname -r on every Linux server you own or pay for.
Install your distribution's fixed kernel and reboot; a patch on disk alone does not protect you.
Ubuntu users: apply the mitigations now and update as soon as the fix leaves testing.
On shared hosting, get a written answer from your host.

FAQ

Is my WordPress site affected?

The bug is in the server's Linux kernel, not WordPress, so your site is exposed if its server is. Patch the server, or ask your host the questions above.

Do I really need to reboot?

Yes. AWS describes a kernel update plus reboot as the only complete remediation. Live-patching services can sometimes avoid a reboot, but only if your vendor confirms the patch covers this CVE.

Is IPv6 affected?

The CVE record says IPv6 is not affected by the main issue. A related IPv6 case, which only arises in a rarely used labelling feature, is to be fixed separately. Your server almost certainly accepts IPv4 as well, so patch anyway.

Has it been exploited?

As of 2 November 2026, none of the vendors cited here reported attacks in the wild or a public exploit.

I turned off MPTCP. Am I safe?

Safer, not safe. The flaw is in ordinary IPv4 TCP handling, and Red Hat says systems with MPTCP disabled remain affected.