Ing. Calogero Bono
A critical flaw in the Linux kernel's TCP IPv4 code, tracked as CVE-2026-98432, can lead to remote code execution. Red Hat published fixed kernels for RHEL 8, 9 and 10 on November 1. Canonical, on November 2, put the fixes for Ubuntu 22.04, 24.04 and 26.04 LTS into the -proposed testing channel, with no date for the regular update. If you run exposed servers, the choice is between waiting and installing right away.
A few terms, before we get into the facts. CVE is the code that identifies a known vulnerability. CVSS is the 0 to 10 scale that measures its severity, here 9.8. Use-after-free is an error where a program reads memory that has already been released. -proposed is the Ubuntu channel where updates stay in testing and do not install on their own. MPTCP is Multipath TCP, a variant of the protocol that uses multiple network paths.
What is the CVE-2026-98432 flaw?
According to the account from The Hacker News, when a server accepts a TCP IPv4 connection the kernel passes the request's IP options to the new socket without copying them. If the client retransmits the request while another processor is still reading those options, the kernel can read memory that has already been freed.
An attacker sends requests with IPv4 Record Route or Timestamp options to any listening TCP port. No access is required. The main IPv6 path is not involved. The defect has been present since kernel 4.4, and the upstream fix arrived in October.
How serious is it, and is there an exploit in circulation?
The kernel CVE team assigns it 9.8 out of 10. Red Hat started from a 5.9 Moderate and then raised the score to 9.8, labeling the flaw Critical. Amazon Linux rates it 8.1, Important, and mainly describes crashes with possible memory corruption.
No vendor, CERT or kernel team has reported attacks, and at the end of October it was not in the CISA catalog of exploited vulnerabilities. Anthropic said an internal research model wrote a root exploit for servers with an MPTCP listener, but did not publish the code. On GitHub there is only code that triggers the critical race, with no code execution.
Which Ubuntu versions are affected and how do you install the patch?
According to the official Ubuntu blog, Jammy (22.04) has kernel 5.15.0-203.213 in -proposed, Noble (24.04) 6.8.0-149.149 and Resolute (26.04) 7.0.0-43.43. Stonking (26.10) is already fixed with 7.3.0-10.10. For Focal, Bionic and Xenial the fix is on its way, while Trusty is not affected.
Use uname -r to check the kernel you are running. To get the fix early, enable -proposed with add-apt-repository, install the indicated version with apt install -t, and reboot. Canonical tests updates on over 2,000 certified servers and devices before the regular release. Older versions require Ubuntu Pro with ESM.
If you manage packages by hand, our guide to apt and dnf helps with the steps.
Are there mitigations, and is turning off MPTCP enough?
No, disabling MPTCP alone is not enough. The defect sits in the TCP IPv4 path and not in MPTCP, and Canonical reiterates that for the Ubuntu Security Team updates are the only appropriate mitigation. The protocol advice arises only from the fact that the exploit described by Anthropic uses it.
On October 30 Red Hat published an nftables rule that drops TCP IPv4 packets carrying IP options. It blocks the known trigger but does not fully prevent exploitation, and it can break services that use those options. It acts only on the host where it is loaded, and traffic between containers on the same machine can bypass it. To understand the network rules you can start with the guide to Linux network configuration.
Limits to know
There is no date for Ubuntu's regular release. The cloud, FIPS and real-time variants are still in progress, while Canonical's post covers only the generic kernel. Anthropic's exploit is not public and its effectiveness is a claim by the company, not verified by third parties. The picture on real-world attacks can change quickly.
What changes for those working with digital systems
If you manage Ubuntu 22.04, 24.04 or 26.04 servers exposed to the Internet, you need to decide now whether to use -proposed or wait. On RHEL 8, 9 and 10, you just install the update and reboot. The reboot has to be scheduled, so you need a maintenance window. Also check containers and virtual machines, because they inherit the host's kernel. If you use managed hosting, ask your provider about the patch status.
Our take
Canonical's choice is technically cautious, but it leaves servers that most need the patch exposed for days. A 9.8 reachable without authentication deserves a faster path, and shifting the risk onto the administrator with -proposed is acceptable only if it is well explained. The blog does explain it, but the delay on older versions remains a problem. It should be acknowledged that the advice to turn off MPTCP has been clearly debunked.
Frequently asked questions
Is CVE-2026-98432 already being exploited?
No attacks have been reported by vendors, CERTs or kernel teams. The bug was not in the CISA catalog as of October 30. There is, however, an exploit claimed by Anthropic and not published, and test code on GitHub.
How do I check whether my Ubuntu is vulnerable?
Run uname -r and compare the version with Canonical's table. You can list installed packages with dpkg -l 'linux-image*'. A reboot is also needed after the update.
Can I install the patch from -proposed?
Yes, if you accept using a channel still under testing. You enable -proposed and explicitly install the kernel, because it does not update automatically. Then you reboot.
Does disabling MPTCP fix the problem?
No. The flaw is in TCP IPv4 and not in MPTCP, as Canonical points out. The advice comes only from the exploit described by Anthropic.
What about Ubuntu 20.04 or older?
For now there is no fix. Focal, Bionic and Xenial are pending and go through Ubuntu Pro with ESM. Trusty is not affected.
What to watch in the coming days for Ubuntu kernels
The outcome depends on Canonical's regular release and on whether the exploit is published.
- Follow Ubuntu's CVE page for the release date in the updates channel and for the cloud variants.
- Check whether reports of attacks appear or whether it is added to the CISA catalog.
- Prepare a reboot window for exposed servers, so you can apply the patch as soon as it is available.
