Linux TCP Flaw CVE-2026-98432: Check and Patch Now

Updated 1 November 2026. Checked against the kernel CVE announcement, Ubuntu's and Debian's CVE trackers, and Red Hat's RHSB-2026-016 bulletin today.

Short answer: CVE-2026-98432 is a remote bug in the Linux kernel's IPv4 TCP code, rated 9.8 out of 10, and it's been there since Linux 4.4 in 2016. If you run a Linux server, VPS, home lab box or Raspberry Pi that accepts connections from the internet, install your distro's fixed kernel and reboot. Debian, Proxmox, Oracle Linux, SUSE and some Amazon Linux kernels already have one. Ubuntu, RHEL and Raspberry Pi OS didn't when I checked this morning, so on those, turn off MPTCP if you don't use it and filter TCP packets that carry IP options until the update lands.

This one got loud this week because Anthropic said an unreleased internal Claude model wrote a working remote root exploit for it. That claim hasn't been independently reproduced, and nobody has reported attacks in the wild. Still, the fix is small, the bug is reachable over the network without a login, and a lot of the machines it affects are the forgotten kind: the Pi in the cupboard, the cheap VPS running a game server. So here's how I'd work through it.

Jump to:

• What the bug actually is
• Step 1: Check your kernel version
• Step 2: Check whether MPTCP is listening
• Step 3: Install the fixed kernel and reboot
• Step 4: Mitigate if your distro has no fix yet
• Step 5: Don't forget containers, VPSes and Go apps
• Fix status by distro (table)
• FAQ

What the bug actually is

When a client opens a TCP connection, the kernel keeps a small "request socket" around until the handshake finishes. If that first SYN packet carries IPv4 options (Record Route or Timestamp, which normal traffic almost never uses), the kernel stores them with the request. When the handshake completes, it hands those same options to the new connection without copying them.

That's the problem. If the client resends its SYN at just the right moment, another CPU core can start building a reply from those options while the connection that owns them is being torn down. The memory gets freed with a plain kfree() and then read anyway. That's a use-after-free, and the kernel CVE announcement spells out the exact code path. The fix, from Eric Dumazet, swaps those frees for kfree_rcu() so the memory sticks around until nothing is still reading it.

A few details worth knowing:

• It's IPv4 only for the main path. The IPv6 handshake already copies the options, so it isn't hit by the first issue.
• There's a second path through socket migration, but only if net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in use. Both are off by default.
• The timeline: fixed upstream on 5 October, CVE published 15 October, and the 9.8 score added on 24 October. Anthropic's write-up followed on 27 October. So it was never a zero-day in the strict sense. The patch existed before most people had heard of the bug.

According to The Hacker News and TuxCare's breakdown, Anthropic's exploit targeted servers with a Multipath TCP (MPTCP) listener. It first leaked a kernel address to get around KASLR, which took 48 minutes in their test, then needed about five more minutes to run a command as root. A lost race only kills that one connection attempt rather than crashing the box, which is why an attacker can just keep trying. Anthropic hasn't published the code or the exact setup it tested, and it hasn't said whether a server without an MPTCP listener can be taken over the same way. I'd treat "no MPTCP" as lower risk, not as safe.

Step 1: Check your kernel version

Run this on the machine itself:

uname -r

Upstream, the fix is in these stable kernels and anything newer in the same branch: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and mainline 7.3.

Here's the catch. Distros backport fixes into their own version numbers, so an Ubuntu kernel like 6.8.0-something can't be compared with that list. Use the upstream list only if you run a vanilla or rolling kernel (Arch, Fedora, a self-built kernel). Everyone else should compare the installed package against the distro's own CVE page, which I've linked in the table below. On Debian and Ubuntu, this shows the installed kernel package version:

dpkg -l 'linux-image*' | grep ^ii

On Fedora, RHEL, Rocky, Alma and Amazon Linux:

rpm -q kernel

Also remember that installing a new kernel does nothing until you reboot. uname -r tells you what's actually running, which is the number that matters.

Step 2: Check whether MPTCP is listening

Since the published exploit went after MPTCP listeners, it's worth knowing whether you have any. Two quick checks:

cat /proc/sys/net/mptcp/enabled
ss -H -lMn

The first prints 1 if MPTCP is allowed on the system (that's the upstream default) or 0 if it's off. The second lists listening MPTCP sockets. Every line it prints is a service accepting MPTCP connections. No output means none.

While I was writing this, I ran the checks on the Debian 13 cloud box I do most of my blog work from. The kernel came back as 6.12.94, which is older than the fixed 6.12.113. MPTCP was enabled, but nothing was listening on it, and socket migration was off:

That box runs on a kernel its provider manages, so I can't patch it myself. Its services also only listen on localhost, so nothing on it is exposed to the internet. Your own server is probably different, which is why it's worth running the same three checks there.

If you want to see the socket-migration setting too, run cat /proc/sys/net/ipv4/tcp_migrate_req. It should say 0 unless you've changed it on purpose.

Step 3: Install the fixed kernel and reboot

This is the real fix. Everything in Step 4 is just a stopgap. Use whichever command matches your system, then reboot and run uname -r again to make sure the new kernel is the one running.

Debian 12 and 13 (and Debian-based systems that use Debian's kernel):

sudo apt update
sudo apt full-upgrade
sudo reboot

Debian fixed trixie in linux 6.12.113-1 (DSA-6568-1) and bookworm in linux 6.1.190-1 (DLA-4841-1), plus linux-6.12 6.12.113-1~deb12u1 for bookworm machines on the newer kernel.

Proxmox VE: Proxmox's kernel is built on Ubuntu's source, but Proxmox staff confirmed on their support forum that the fix is in 7.0.14-25-pve and newer, on both the no-subscription and enterprise repositories. Update through the web UI or with apt full-upgrade, then reboot the node.

Fedora, Amazon Linux 2023, Oracle Linux (UEK):

sudo dnf upgrade --refresh 'kernel*'
sudo reboot

On Amazon Linux 2023, only the kernel6.12 and kernel6.18 packages had fixes when I checked. If you're on the default kernel, keep an eye on the Amazon Linux security center.

SUSE and openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot

Arch: sudo pacman -Syu and reboot. Arch ships close-to-upstream kernels, so you can compare uname -r directly with the stable list in Step 1.

Ubuntu: the same sudo apt update && sudo apt upgrade will pull in the fix once Canonical releases it. As of this morning, its tracker still showed every supported release as "Vulnerable, work in progress".

Step 4: Mitigate if your distro has no fix yet

If you're stuck waiting on Ubuntu, RHEL, Rocky, Alma, Amazon Linux 2 or Raspberry Pi OS, there are two things you can do now. Neither replaces the patch.

1. Turn off MPTCP if you don't use it. Almost no home or small-business setup does. RHEL 8, 9 and 10 already ship with it off.

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-no-mptcp.conf

The first line turns it off now, and the second keeps it off after a reboot. Sockets that are already open aren't touched by the change, so restart any service that was listening over MPTCP.

2. Drop inbound TCP packets that carry IP options. This is the mitigation in Red Hat's RHSB-2026-016 bulletin. Standard TCP options like window scaling and SACK live in the TCP header, not the IP header, so ordinary traffic shouldn't notice. Save this as cve-2026-98432.nft:

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

Then check it, load it and confirm it's there:

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Red Hat is clear that this reduces exposure but can't fully prevent the bug, and it asks you to test the rule against your own traffic first. The rule also disappears on reboot unless you add it to your nftables config. Once you're on a fixed kernel, remove it with sudo nft delete table inet cve_2026_98432.

If your server sits behind a cloud firewall or a home router, closing ports you don't need is still the easiest win. A service that isn't reachable can't receive a crafted SYN. For things you only use yourself, like SSH, a dashboard or a media server, putting them behind a VPN instead of a public port goes a long way. My Tailscale vs WireGuard comparison covers the two easiest ways to do that.

Step 5: Don't forget containers, VPSes and Go apps

• Docker and Podman containers share the host's kernel. Updating a container image does nothing for this bug. Patch and reboot the host.
• On a normal KVM VPS, the kernel is yours to update, even though the provider runs the hardware. On container-style VPS plans (OpenVZ or LXC), the host kernel belongs to the provider, so check their status page or ask support.
• Raspberry Pi OS uses its own kernel packages, not Debian's. When I checked Raspberry Pi's apt repository this morning, the current linux-image-rpi-2712 package was still 6.18.50, older than the fixed 6.18.56. If your Pi runs Pi-hole or a VPN from my Pi-hole and WireGuard guide, turn MPTCP off for now and run sudo apt update && sudo apt full-upgrade again over the next few days. Ubuntu's linux-raspi kernel is still listed as vulnerable too.
• Go programs turn MPTCP on by themselves. Since Go 1.24, listeners created with Go's standard library use MPTCP by default when the kernel allows it. That matters for many self-hosted tools written in Go. The Go team's suggested opt-out is the environment variable GODEBUG=multipathtcp=0, or godebug multipathtcp=0 in go.mod if you build the app yourself. An app that calls SetMultipathTCP in its own code ignores both, so the system-wide net.mptcp.enabled=0 from Step 4 is the more reliable switch.

If you host a game server at home, like the setup in my Minecraft server behind CGNAT guide, the host running it is exactly the kind of internet-facing Linux box this bug is about. The same goes for a Jellyfin server you've opened to the outside.

Fix status by distro

This is what each vendor's own page said as of 1 November 2026 (Debian, Ubuntu, Red Hat, Raspberry Pi and Proxmox checked today; the rest from advisories dated 16 to 30 October). Things are moving fast, so click through before you decide you're safe.

There's also a rebootless option. TuxCare's KernelCare has a live patch out for Debian 13, with Enterprise Linux versions in progress. It's a paid service, aimed at people who can't take a reboot. For most home servers and small VPSes, a five-minute reboot is the simpler answer.

The bug was found and reported by Anthropic researcher Xinyang Ge. As of 30 October, it wasn't in CISA's Known Exploited Vulnerabilities list and no attacks had been reported. That's the window to patch in, before working exploit code shows up in public. If you're also using Claude Code on your dev machine, my post on checking for the backdoored Claude Code extension is worth a look while you're tidying things up.

Related same-week Linux patching: APT CVE-2026-109518 check and patch — an on-path HTTP bug that can turn a poisoned mirror into root RCE on Debian and Ubuntu.

Related guides: I keep the main security walkthrough in my guide to checking your PC after the NIKKE launcher malware. You might also want my notes on checking BTCPay Server after the hot-wallet attack or Discord messages showing up in Google.

FAQ

Is CVE-2026-98432 being exploited right now?

Not that anyone has reported. As of 30 October, it wasn't in CISA's Known Exploited Vulnerabilities catalogue, and Anthropic hasn't released its exploit code. That could change quickly now that the details are public, which is why patching this week makes sense.

Does this affect my Windows PC or my phone?

No. It's a Linux kernel bug. Android does run a Linux kernel, but phones aren't usually waiting for incoming TCP connections from the internet the way servers are. Install Android security updates when they arrive and you're covered. The real exposure is Linux machines running public services.

Am I safe if I don't use MPTCP?

Safer, not safe. The use-after-free itself sits in the normal IPv4 TCP handshake. MPTCP is just what Anthropic's published exploit targeted. Turning MPTCP off and filtering IP options both shrink the risk, but only a fixed kernel removes it.

Is IPv6 affected?

The main path isn't, because the IPv6 handshake copies the options instead of sharing them. The kernel developers noted a similar migration issue in IPv6 that only applies with CALIPSO labelling, which almost nobody uses, and said it will get its own patch.

Do I really need to reboot?

Yes. The new kernel sits on disk until the machine restarts. Running uname -r after the reboot is the only way to be sure the fixed one is running. The exception is a paid live-patching service like KernelCare or Ubuntu Pro Livepatch, and only once it actually covers this CVE for your kernel.

Why does Ubuntu's version number look nothing like 6.12.113?

Ubuntu, Red Hat and most other distros keep their own kernel versions and backport fixes into them. A kernel like 6.8.0-149 can be fixed or not depending on what Canonical has merged, so always check the distro's CVE page rather than the upstream numbers.