CVE-2026-98432: Protect Your WordPress VPS and Bare-Metal Servers Before Ubuntu Patches

Introduction

A critical bug in the Linux kernel’s TCP code, CVE-2026-98432, went viral on October 29. The kernel’s own CVE team rates it 9.8 out of 10: it sits in the code that accepts new IPv4 TCP connections, so almost every internet-facing server has it, and it has been there since kernel 4.4 in early 2016.

The bad news for most WordPress fleets: Ubuntu, which GridPane, RunCloud and most VPS stacks run on, had not shipped a fixed kernel as of October 31. Debian, Oracle Linux and Amazon Linux have.

The one thing to do today: check net.mptcp.enabled on every Ubuntu host and turn MPTCP off where nothing needs it, then patch and reboot the moment Canonical ships the kernel.

How It Works

It’s a use-after-free in the kernel’s IPv4 TCP connection setup. Oracle’s CVE record describes IPv4 option structures being freed before an RCU grace period ends, so a race during the handshake can leave the kernel touching memory that’s already been released. Because this happens before any application authentication, an attacker needs no login and no user interaction, just the ability to reach a listening TCP port.

The headline exploit came from Anthropic’s Frontier Red Team: an unreleased Claude research model turned the bug into remote root against servers with a multipath TCP (MPTCP) listener, leaking kernel addresses in about 48 minutes and getting a root shell a few minutes later. Anthropic hasn’t published the exploit or its test configuration, and we won’t link anything that claims to be one.

What We Know So Far

• The CVE was published October 15, 2026; the kernel team assigned the 9.8 score on October 24.
• Anthropic disclosed its AI-built exploit on October 27; coverage peaked on October 29.
• Debian shipped its fix on October 16. Oracle Linux and Amazon Linux have also shipped fixes.
• As of October 31, Ubuntu lists every supported release as vulnerable, with a fix “in progress” and no release date. Red Hat says it has no mitigation that meets its criteria for RHEL.
• We have not seen reports of in-the-wild exploitation. That can change fast with a public, AI-assisted exploit story this loud.

Where sources disagree: only Anthropic’s post ties the root exploit to MPTCP. Neither the CVE record nor the fix commit mentions MPTCP, and the CVE record describes an attack on any server that accepts connections. Treat disabling MPTCP as narrowing exposure, not a fix.

Affected Versions and Exposure

The upstream fix is in stable kernels 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Anything from 4.4 up to those versions is affected.

Ubuntu status (from Canonical’s tracker, October 31):

• 22.04, 24.04, 26.04 LTS and 26.10: vulnerable, fix in progress.
• 16.04, 18.04, 20.04: vulnerable, no fix listed.
• 14.04: not affected.

MPTCP is opt-in: an application has to ask for it when it opens a socket. Typical WordPress stacks (Nginx/OpenLiteSpeed, PHP-FPM, MySQL/MariaDB, Redis) don’t, to our knowledge. That doesn’t mean it’s off: the kernel side is switched on (net.mptcp.enabled = 1) on GridPane servers on every Ubuntu version and on Proxmox VE hosts, so any application that asks for MPTCP gets it. The thing to watch is Go: Go 1.24 and later enable MPTCP on listening sockets by default, so any Go binary listening on a public port (exporters, agents, small tools, a lot of Docker containers) can be an MPTCP listener.

Immediate Mitigation Steps

1. Find your exposed Ubuntu and RHEL hosts

Check the running kernel and distro on every server. Debian, Oracle and Amazon Linux hosts can go straight to patching.

uname -r
lsb_release -ds

2. Check whether MPTCP is enabled

A 1 means applications can open MPTCP sockets.

sysctl net.mptcp.enabled

3. Look for MPTCP listeners

ss -M lists MPTCP sockets only. Leave out -t: adding it also lists every ordinary TCP listener, which makes everything look exposed. Anything this shows is the exact shape Anthropic’s exploit targeted; no output means no MPTCP listeners.

ss -Mlnp

4. Turn MPTCP off where nothing needs it

Apply it now and persist it across reboots.

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

5. Pre-approve the kernel update and plan reboots

There’s nothing to install on Ubuntu yet. Line up maintenance windows now so the fixed kernel goes out the day it lands.

Hardening Checklist

• Firewall every port that doesn’t need to be public. Fewer listening sockets means less to reach.
• Restrict SSH to known IPs or put it behind a VPN or Cloudflare Tunnel.
• Lock web ports 80/443 to Cloudflare’s IP ranges on proxied sites so the origin isn’t directly reachable.
• Inventory Go binaries and containers listening on public interfaces.
• Confirm unattended-upgrades is on and that someone actually reboots after kernel updates.

Installing / Applying the Fix

Debian

Fixed kernels are available. Update and reboot.

apt update && apt full-upgrade -y
reboot

Ubuntu

No fixed kernel yet. Once Canonical publishes it, run the same update and reboot. Ubuntu Pro users with Livepatch may get a rebootless patch; check canonical-livepatch status once Canonical announces one.

RHEL / AlmaLinux / Rocky

No fix as of October 31. Watch Red Hat’s CVE page, then run dnf update kernel and reboot when it ships.

Managed Hosting and Control Panels

• SiteGround says it live-patched its servers the same day the flaw made headlines, with no reboots needed. (SiteGround)
• GridPane: no public statement found as of October 31. GridPane servers run Ubuntu and have MPTCP enabled on every Ubuntu version, so assume they’re vulnerable until a kernel ships and you reboot. Turning MPTCP off (step 4 above) is worth doing now.
• RunCloud: no public statement found as of October 31. Same advice: Ubuntu underneath, patch and reboot when available.
• KernelCare / TuxCare has a rebootless patch out for Debian 13; it says Ubuntu patches have no release date yet. (TuxCare)

Mitigations to Reduce Exposure

1. Disable MPTCP (confirmed for Anthropic’s exploit path only)

Covered above. It blocks the specific exploit Anthropic described. It doesn’t remove the underlying bug.

2. Reduce reachable TCP listeners (unconfirmed)

The bug is in connection setup, so an attacker has to reach a listening port. Closing ports at the firewall or provider level shrinks the target. Whether a non-MPTCP listener can be exploited the same way is unknown.

3. Enable the Cloudflare WAF (limited)

The WAF works at HTTP, above where this bug lives, so it can’t filter the attack itself. What does help is proxying sites through Cloudflare and locking origin 80/443 to Cloudflare IPs, so attackers can’t open TCP connections to your web server directly. SSH and any other open ports are still reachable.

4. Take the Site Offline (doesn’t apply here)

Our usual last resort, GridPane HTTP Authentication or Suspend Site and RunCloud Site Authentication, works at the web server level. The kernel still accepts the TCP connection first, so it doesn’t protect you from this bug. If a host is genuinely at risk, firewall it or take it off the network instead.

Detecting Exploitation

1. Watch the kernel log for crashes

A failed race can leave traces. Look for use-after-free, general protection faults or oopses.

journalctl -k --since "2026-10-15" | grep -iE "use-after-free|general protection|BUG:|Oops"

2. Look for unexpected root processes and logins

ps -eo user,pid,ppid,lstart,cmd --sort=lstart | tail -n 30
last -a | head -n 30

3. Check for new accounts and SSH keys

awk -F: '$3 == 0 {print $1}' /etc/passwd
find / -name authorized_keys -newer /etc/hostname 2>/dev/null

4. Review outbound connections

A compromised host often calls home. Check for listeners and connections you don’t recognise.

ss -tunap | grep -v -E "127.0.0.1|::1"

If anything looks off, treat the host as compromised: isolate it, snapshot it, and rebuild rather than clean.

FAQ

Is this a breach?

No. It’s a vulnerability. There’s no report we’ve seen of it being exploited in the wild, but a 9.8 with a public AI-built exploit story is the kind of thing that changes quickly.

Is my server safe if MPTCP is off?

Safer, not safe. Turning MPTCP off blocks the exploit Anthropic described, but the CVE record describes the bug as reachable on any server that accepts connections.

Does Cloudflare protect me?

Only if your origin only accepts web traffic from Cloudflare. Cloudflare can’t filter a kernel TCP bug, but it can stop attackers reaching your origin’s web ports directly.

Do I need to reboot?

Yes. A kernel update only takes effect after a reboot, unless you’re using a live-patch service.

Updates

• October 31, 2026: Added that GridPane servers (every Ubuntu version) and Proxmox VE hosts have MPTCP enabled. Corrected the MPTCP listener check to ss -Mlnp; the earlier ss -Mltnp also listed ordinary TCP listeners.
• October 31, 2026: First version. Ubuntu and RHEL still have no fixed kernel; Debian, Oracle and Amazon Linux have shipped fixes.

Sources

• Ubuntu CVE tracker: CVE-2026-98432
• CVE record (CVEProject)
• TuxCare: CVE-2026-98432 and which distros are patched
• Pillitteri: no patch on Ubuntu and RHEL
• Rescana: prepare now
• Aviatrix: Ubuntu and RHEL status
• SiteGround: patched the same day
• AI Chat Daily: Anthropic’s exploit chains
• Magica: Anthropic exploit chains and vendor records