CVE-2026-98432: What the Linux TCP Flaw Means If Your App Runs on Your Own Server

When a client opens a TCP connection, it can include IPv4 options such as Record Route or Timestamp in its connection request. The kernel hands those options to the new socket without copying them. If the client retransmits its request while another processor is still reading the options, that second code path can read memory that has already been freed. The upstream fix delays freeing the memory until concurrent readers have finished.

Two details matter for risk. The trigger arrives over the network and requires no credentials, which is why the score is so high. It also depends on winning a race, which is why turning it into reliable code execution is hard. Those facts do not cancel each other out. Hard to exploit reliably is a description of today's public tooling, not a guarantee about next month.

Much of the coverage has focused on Multipath TCP. Anthropic's post describes an exploit against servers with an MPTCP listener, taking about 48 minutes to leak a kernel pointer and another five to reach command execution. Anthropic did not publish the exploit. Code that triggers the race has appeared on GitHub, but The Hacker News reports that it does not implement code execution.

Sources frame the dependency differently. BleepingComputer and TuxCare point out that remote code execution has not been publicly demonstrated without an MPTCP listener. Red Hat states plainly that having MPTCP enabled is not a precondition of the vulnerability, and that RHEL systems remain vulnerable even though MPTCP is off by default. Both statements can be true: one describes what has been shown, the other describes where the bug lives.

Plan around the conservative reading. Akamai notes that disabling MPTCP reduces the likelihood of triggering the race but does not prevent exploitation, and Red Hat warns that checking for MPTCP listeners is not a test for exposure. One detail is worth knowing if you ship Go services: Go 1.24 and later enable MPTCP on Linux listeners by default, so a server can have an MPTCP listener without anyone having chosen one.

The dividing line is who operates the kernel. If you rent a virtual machine, run your own Kubernetes nodes, or host containers on a server you administer, the kernel is yours to patch. Containers share the host kernel, so rebuilding an application image does nothing for this flaw. The node underneath has to change.

On managed platforms where you deploy code and never log in to a machine, the provider generally carries this work. We did not find public statements covering every platform, so check your provider's security bulletins instead of assuming. Managed services with customer-visible nodes sit in between: Red Hat has separate guidance for OpenShift and notes that its firewall mitigation does not cover pod-to-pod traffic on OVN-Kubernetes.

Status differs by distribution, and it is changing daily. Treat the list below as a starting point and confirm against your vendor's tracker before you close the ticket. Ubuntu in particular is worth watching: as of its tracker update on November 4, its supported LTS kernels were still listed as work in progress, with fixes in the proposed pocket.

Severity has moved as well. In late October, reporting cited Red Hat's rating as Moderate at 5.9. Its CVE page now lists Critical at 9.8. A team that triaged on the first number it saw and never looked again would have the wrong priority today, which is a good argument for tracking advisories as living documents.

Patching is the only complete fix, and both Red Hat and Canonical say so directly. The step most small teams miss is the reboot. A package manager can report that the new kernel is installed while the old, vulnerable one keeps running for months. Red Hat's erratum spells it out: the system must be rebooted for the update to take effect. Compare the running kernel from uname -r with the version your vendor lists as fixed.

If you cannot patch yet, Red Hat publishes an nftables rule that drops incoming IPv4 TCP packets carrying IP options. It reduces exposure but comes with real limits. Red Hat says it is not a substitute for patching, may disrupt workloads that depend on those options, and does not survive a reboot unless you make it persistent. A CIQ kernel engineer also noted on oss-security that traffic between containers on the same host can bypass it. Use the vendor's published rule and remove it once the kernel is updated.

This flaw has nothing to do with whether a person or a model wrote your code. A hand-written Rails app on an unpatched VM is exactly as exposed. What differs is the operating situation. AI tools make it possible to reach a live, revenue-earning product without anyone ever having been the person who looks after the server. A generated setup guide gets the machine running once. It does not subscribe to a security mailing list, and it does not schedule a reboot three years later.

The timeline also deserves attention. The upstream fix landed on October 5, the CVE followed on October 15, and a lab was describing a working exploit by October 27. The same class of tooling that helps you ship faster is shortening the distance between a published fix and a usable attack. Defensive routines built around checking on things every few months are getting harder to justify.

If your product takes payments or holds customer data, ask a direct question: who would have noticed this advisory, and who would have rebooted the server? If the honest answer is nobody, that gap is the real finding, and it is bigger than this one CVE. An experienced engineer does not need to be full-time to close it, but someone accountable does need to own it. That is the work behind our production hardening engagements and retainers, and the checklist above is a fair way to evaluate anyone you hire for it.