Linux TCP flaw: what Ubuntu and Red Hat teams should check
CVE-2026-98432 is a use-after-free flaw in the Linux kernel’s IPv4 TCP handling. Red Hat says a remote attacker who can reach a vulnerable TCP service could exploit it without credentials. The immediate enterprise question is which systems run affected kernels and accept inbound TCP connections, while distribution-specific updates are still pending.
By George the bot
Edited and approved by Faysal Aziz
Published

What is known
Anthropic reported that its research model developed a proof of concept against an MPTCP listener and achieved remote code execution. This demonstrates a possible attack path; it does not establish that the flaw is being exploited in the wild, or that every vulnerable server will be equally easy to exploit. Red Hat describes the underlying exposure more broadly than MPTCP: ordinary IPv4 TCP connection-request processing is involved. It rates the issue Critical for affected Red Hat products.
Ubuntu and Red Hat status
An upstream Linux fix does not mean a distribution’s installed kernel is fixed. As checked on 31 October 2026, Canonical lists the standard Ubuntu 22.04, 24.04, 26.04 and 26.10 kernels as vulnerable, with fixes in progress. The tracker covers many kernel flavours, so administrators should check the entry for the actual package and release they run. “Work in progress” is not a released update.
Red Hat’s bulletin lists RHEL 8, 9 and 10 and OpenShift Container Platform as affected, and says other products built on the RHEL kernel may be affected. Red Hat says it is expediting fixes. Its published firewall guidance can reduce exposure, but it explicitly says the guidance cannot fully prevent the flaw; a fixed kernel update is the complete remedy. That is the important distinction: Red Hat has an interim mitigation, not a complete solution in the bulletin.
The practical concerns for enterprises
First, inventory the running kernel on hosts, virtual machines and container nodes. A package may be installed without the host having booted into it. Match each system to its vendor’s advisory, release and kernel flavour rather than assuming a generic upstream version answers the question.
Second, map inbound IPv4 TCP exposure. Internet-facing systems deserve priority, but internal services reachable from less-trusted networks also matter. Review network ACLs and firewalls, and limit access where the service does not need broad reachability. Containerised applications still depend on the host kernel.
Third, consider interim controls only with testing. Red Hat describes an nftables rule that drops IPv4 TCP packets carrying IP options. It may disrupt traffic that legitimately needs those options, and Red Hat says it is not a complete fix. If MPTCP is used, assess whether disabling it is workable for the affected service; AWS says that reduces the demonstrated execution path but does not eliminate the underlying vulnerability. Neither measure should be presented as a patch.
Finally, monitor the Canonical tracker and Red Hat bulletin for a fix for each specific kernel. Apply the vendor-supported update when available and verify the running kernel afterward. Until then, keep a record of affected systems, the network exposure you found and any interim control you tested. The concern is concrete: a remotely reachable kernel flaw with demonstrated code execution, while patch availability depends on the distribution and build—not a claim that every Linux server is already compromised.
Sources
- Anthropic Frontier Red Team — “Discovering and exploiting vulnerabilities in critical, real-world software with Claude” (27 October 2026)
- Canonical — Ubuntu CVE-2026-98432 tracker (checked 31 October 2026)
- Red Hat — CVE-2026-98432 assessment (checked 31 October 2026)
- Red Hat — RHSB-2026-016 security bulletin and mitigation (checked 31 October 2026)
- AWS — Security bulletin 2026-160-AWS and interim guidance (30 October 2026)