A 9.8 Linux Kernel Bug Can Hand Over Root Remotely on Some Servers: Your Questions on CVE-2026-98432, Answered
A use-after-free bug in the Linux kernel’s TCP code, CVE-2026-98432, was turned into a remote root exploit on servers with Multipath TCP listeners. Patches are still rolling out across distributions. Here are the answers to the questions server owners are asking.
A newly disclosed Linux kernel vulnerability has drawn two very different severity ratings, and the gap between them is the story. Here are the key questions and answers for anyone responsible for Linux servers.
Our answers are drawn from BleepingComputer’s report on CVE-2026-98432.
What is the bug?
CVE-2026-98432 is a use-after-free flaw in the IPv4 TCP networking code of the Linux kernel. It comes from a race condition in how the kernel handles incoming connection requests: while one processor core hands a pending connection’s option data over to the newly created socket, another core handling a retransmitted connection request for the same connection can still be reading that data. A similar issue can occur during TCP request socket migration when that feature is turned on.
Why does one rating say 9.8 and another 5.9?
The Linux kernel CVE team scored it 9.8 out of 10. Red Hat scored it 5.9, treating it mainly as a potential denial-of-service bug that could crash the kernel, because winning the race is far more complicated than sending one malicious packet. Neither requires a login.
So can it really be used to take over a server?
Under specific conditions, yes. Researchers at Anthropic reported that an unreleased Claude AI model produced an exploit that defeated kernel address space layout randomization and ran commands as root on a Linux server with a Multipath TCP (MPTCP) listener. The exploit took about 53 minutes to reach remote root. The flaw also affects ordinary TCP connections, but remote code execution has not been publicly shown on servers without an MPTCP listener.
What is MPTCP, and am I using it without knowing?
Multipath TCP lets one connection use several network paths at once, such as Wi-Fi and cellular, for speed and resilience. Most applications do not turn it on by default. One notable exception: starting with Go 1.24, the Go programming language enables MPTCP for TCP listeners on Linux whenever the kernel supports it, so some Go-based services may be running MPTCP listeners that their administrators never configured.
Which systems are affected?
- Linux kernels going back to version 4.4, including Ubuntu, Red Hat Enterprise Linux and Rocky Linux.
- Canonical listed Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10 as still vulnerable with kernel fixes in progress as of October 30.
- Red Hat lists RHEL 8, 9 and 10 as affected with fixes planned. RHEL 7 is not affected.
- CIQ confirms Rocky Linux 8, 9 and 10 are affected.
- Debian has fixed packages: 6.1.190-1 for Debian 12 and 6.12.113-1 for Debian 13. Oracle Linux, Amazon Linux and SUSE have released fixes for some kernel versions.
- macOS is not affected because it does not use the Linux kernel.
Is anyone exploiting it?
There are no confirmed reports of exploitation in the wild so far.
What should I do before a patch arrives?
- Install your distribution’s updated kernel as soon as it is available, and reboot so it actually takes effect.
- Until then, limit which networks and addresses can reach exposed Linux services.
- CIQ suggests temporarily blocking IPv4 TCP packets that carry IP options before they reach the vulnerable code, and has published example firewall rules for that.
- Do not rely on switching off MPTCP alone. CIQ warns the underlying bug can still be triggered through ordinary TCP traffic.
What this means for your company
Linux runs far more of a typical business than most owners realize: web servers, firewalls, storage boxes, cloud instances and appliances. Ask whoever manages those systems for a simple inventory of which ones are internet-facing and how kernel updates and reboots get scheduled. This case also shows that AI tools are speeding up how quickly a bug rated as a crash risk can become a working takeover, which shortens the time you can safely wait to patch.
Need help finding every Linux system you depend on and keeping its kernel current? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
