Last updated: November 4, 2026
If you run a Linux server on the internet, this is the week to patch the kernel and actually reboot. A ten-year-old bug in the way Linux accepts TCP connections now has a demonstrated remote root exploit, and researchers have spotted what looks like attackers mapping which servers are reachable. Here is what the bug is, who is exposed and the exact commands to check and protect your machines.
What Happened
- October 15, 2026: the CVE record for CVE-2026-98432 is published. The Linux kernel CVE team rates it 9.8 (CVSS 3.1).
- October 27: Anthropic’s Frontier Red Team publishes research in which an unreleased Claude model wrote a working remote root exploit from a single prompt. In the lab, leaking a kernel pointer took 48 minutes and getting a root shell took five more. The exploit was not released.
- October 30: internet scans count about 2.1 million servers answering MPTCP on port 443.
- November 2 to 3: Marcus Hutchins reports probes for MPTCP on port 443 from residential proxies and VPN servers. He suspects, but has not proven, that they are looking for this bug.
There is still no public remote code execution exploit and no confirmed attack in the wild. But scanning is usually the step right before exploitation, and denial-of-service proofs of concept already exist.
How the Bug Works
When a client connects, the kernel keeps the SYN’s IP options on a half-open “request socket”. When the connection is accepted, the new socket takes those options without copying them. If a retransmitted SYN arrives at the same time and another CPU is still building a SYN-ACK, that CPU can read the options after they were freed: a classic use-after-free in tcp_v4_syn_recv_sock(). The fix delays the free with kfree_rcu().
IPv6 is not affected by the main race. The demonstrated exploit goes through MPTCP (Multipath TCP), which is why servers with an MPTCP listener are the ones being scanned. Programs built with Go 1.24 or later use MPTCP for listeners by default when the kernel supports it, so many web servers and proxies have it on without their admins knowing.
Check if You Are Exposed
Run these three commands on each server:
uname -r # your running kernel
sysctl net.mptcp.enabled # 1 = MPTCP is on
sudo ss -Mlnp # programs listening with MPTCPIf ss -Mlnp lists anything listening on a public port and your kernel is older than the fixed version below, treat the server as exposed.
Fixed Kernel Versions
| Where | Fixed in |
|---|---|
| Upstream Linux | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 |
| Ubuntu 26.10 | 7.3.0-10.10 (released) |
| Ubuntu 26.04 LTS | 7.0.0-43.43 (in -proposed) |
| Ubuntu 24.04 LTS | 6.8.0-149.149 (in -proposed) |
| Ubuntu 22.04 LTS | 5.15.0-203.213 (in -proposed) |
| Ubuntu 20.04 and older | Fix pending (needs Ubuntu Pro ESM) |
| Amazon Linux 2 / 2023 | Patched kernels available; EKS and ECS AMIs from 20261031 |
On Ubuntu, packages in -proposed are not installed by default, so you have to enable that pocket or wait for the fix to reach the normal updates. Debian, Red Hat, SUSE and others backport the fix with their own version numbers: check their security trackers.
How to Protect Your Server
- Update the kernel and reboot. On Debian, Ubuntu and Raspberry Pi OS:
sudo apt update, thensudo apt full-upgrade, thensudo reboot. A new kernel does nothing until you reboot into it. - If you can’t patch today, turn MPTCP off with
sudo sysctl -w net.mptcp.enabled=0and add it to/etc/sysctl.d/to keep it after reboot. Then restart the services that were listening, because existing sockets stay open. - For Go services, start them with
GODEBUG=multipathtcp=0to stop them from opening MPTCP listeners. - Drop IPv4 packets with IP options at the firewall. Almost no normal traffic uses them, but test first: anything that relies on IP options will break.
- Put the server behind a load balancer or managed service that terminates TCP on a different machine. A reverse proxy on the same host does not help.
All the workarounds reduce the risk but do not remove the bug. The kernel update is the real fix.
Why This One Is Different
Kernel bugs are found every week. What makes this one stand out is the speed: an AI model went from bug to remote root in under an hour in a lab, and within a week the internet was being scanned for vulnerable hosts. The window between “patch available” and “patch needed” is getting very short. If your servers don’t install security updates and reboot on their own, this is a good moment to set up unattended-upgrades or a patching schedule.
Frequently Asked Questions
What is CVE-2026-98432?
It is a use-after-free bug in how the Linux kernel sets up IPv4 TCP connections. A new connection can take the IP options of a half-open connection without copying them, so another CPU handling a repeated SYN can read memory that was already freed. It was introduced in Linux 4.4, so almost every kernel from the last ten years has it until patched.
Is it being exploited?
Not confirmed. Security researcher Marcus Hutchins reported on November 3, 2026 that what looks like threat actors started scanning the internet for MPTCP on port 443 from November 2. He strongly suspects it is linked to this CVE but it is not proven. No public remote code execution exploit exists yet, though denial-of-service proofs of concept do.
Which servers are most at risk?
The remote root exploit that was demonstrated targets servers with an MPTCP listener exposed to the internet. Programs written in Go 1.24 or later use MPTCP for listeners by default when the kernel supports it, which is one reason around 2 million servers answer MPTCP on port 443. The underlying bug is in IPv4 TCP, so every unpatched Linux machine should be updated.
Which kernel versions fix it?
Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distributions backport fixes with their own numbers: for example Ubuntu 24.04 uses 6.8.0-149.149 and 22.04 uses 5.15.0-203.213. Always check your distribution’s security tracker.
Is disabling MPTCP enough?
No. Setting net.mptcp.enabled=0 reduces the attack surface for the known exploit but does not fix the bug, and it does not close sockets that are already open, so you must restart affected services. Updating the kernel and rebooting is the only real fix.
Do I need to worry about my Raspberry Pi?
If it runs a Linux kernel 4.4 or newer and is reachable from the internet, update it with sudo apt update followed by sudo apt full-upgrade, then reboot. A Pi that is only on your home network behind a router is a much smaller risk, but it is still worth updating.