CVE-2026-98432: A Critical Linux TCP Bug Is Raising the Stakes for Kernel Patching

Key takeaways for CVE-2026-98432

• CVE-2026-98432 is a use-after-free bug in the Linux kernel's IPv4 TCP networking stack; it has been present since Linux 4.4.
• It carries a Critical rating and a 9.8 CVSS 3.1 score from both the Linux kernel CVE team and Red Hat.
• Anthropic made headlines by showing how Claude helped construct a working exploit, gaining root-level remote command execution on a server running a multipath TCP listener. However, MPTCP is not required for exposure: the vulnerable IPv4 TCP code paths can also be reached through ordinary TCP connections.
• While this proves RCE is doable under the right conditions, it doesn't automatically mean every unpatched Linux server is an easy target in practice.
• Patches are already available for Debian and Amazon Linux. As of November 2, Ubuntu is rolling out fixes, while Red Hat lists RHEL 8, 9, 10, and OpenShift as affected and is fast-tracking updates.
• Red Hat shared a network filtering rule to help lower risk in the meantime, but stressed that it's purely a temporary band-aid, not a replacement for a kernel patch.

A newly uncovered flaw in the Linux kernel's IPv4 networking stack has caught the security community's attention. The issue quickly made waves after Anthropic demonstrated how Claude helped construct an exploit that achieved remote command execution (RCE) as root. Given how deep this bug sits, the Linux kernel CVE team assigned it a 9.8 CVSS score, and Red Hat tagged it as Critical.

While the proof of concept is certainly eye-opening, real-world impact is still coming into focus. Anthropic's test targeted a server with a multipath TCP (MPTCP) listener enabled, without diving into exact build details. This describes the demonstrated setup, but MPTCP is not required to reach the vulnerable code: ordinary TCP connections can also trigger the affected IPv4 TCP paths. But because the underlying issue lives in core IPv4 TCP handling, security teams shouldn't assume they're safe just because MPTCP is turned off. Your best move is to check your Linux vendor's specific advisory.

What happened?

On October 15, the Linux kernel team publicly disclosed CVE-2026-98432, rooted in how the kernel processes incoming IPv4 TCP connection requests. The bug has been lurking since Linux 4.4, though upstream fixes have already landed in supported stable branches. Remember, upstream code fixes don't magically update your servers, distro maintainers still need to package, test, and ship those updates to you.

The situation gained momentum on October 27 when Anthropic shared that AI-assisted research had successfully generated a working exploit. Anthropic explained that the exploit gained unauthenticated remote root access on a server with an MPTCP listener. However, the vulnerability affects the Linux IPv4 TCP stack, and the vulnerable code paths can also be reached through ordinary TCP connections. The attack unfolded in two steps: spending about 48 minutes discovering kernel memory layouts to bypass KASLR, followed by five minutes to launch the root shell.

Then on October 30, Red Hat pointed out that exposure could extend beyond just MPTCP setups. They noted that vulnerable kernels with IPv4 TCP active are exposed, especially if they accept inbound connections. While pulling off an exploit takes precise packet timing, Red Hat confirmed RCE is on the table.

How CVE-2026-98432 works

At its core, CVE-2026-98432 is a use-after-free vulnerability. This happens when the kernel frees up a chunk of memory while another part of the system is still actively using it. If that memory gets recycled or altered mid-stream, it can trigger crashes or open doors for an attacker. In this case, during TCP handshake processing, the kernel passes IPv4 options to a new socket without making a fresh copy. If a separate CPU core handles a retransmitted request at the exact same instant, a race condition opens up. If the socket gets destroyed and options are freed mid-process, the second core ends up referencing stale memory.

The upstream kernel patch fixes this by adjusting memory cleanup timing through Read-Copy Update (RCU) grace periods, making sure readers finish before memory gets freed. Instead of just causing a kernel panic, Anthropic's exploit turned this race into full system control. First, it forced the kernel to leak memory pointers, effectively neutralizing KASLR (which scrambles memory layouts to thwart attacks). Once it pinpointed kernel addresses, the exploit overwrote a callback pointer to run a root payload. Interestingly, whenever the exploit missed the race window during testing, the connection simply dropped without crashing the host—allowing the attack to retry until it won the race. How reliably this works across different kernels and hardware remains an open question.

Understanding severity ratings

Both Red Hat and the Linux kernel CVE team assigned a CVSS 3.1 score of 9.8 (Critical). Ubuntu aligned with 9.8 under CVSS 3.1, while scoring it an 8.3 (High) under CVSS 4.0. These subtle shifts illustrate how different scoring systems evaluate technical risk.

While CVSS scores help prioritize patching queues, they don't tell you if your specific servers are directly in harm's way. That depends on your specific distro build, active patch levels, and whether an attacker can reach your open ports.

Where things stand: Patching and mitigations

Patch timelines vary depending on your Linux distribution. Debian has pushed fixes for supported releases, and Amazon Web Services provided updated kernels for Amazon Linux 2 and 2023. As of November 2, Ubuntu is issuing updates across several releases, while Red Hat lists RHEL 8, 9, 10, and OpenShift as affected and is expediting patches. Keep an eye on your vendor's security tracker for updates.

On the upstream side, fixes are present in Linux kernel versions 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3. Because enterprise distros regularly backport security fixes into their own package versioning, plain kernel version strings aren't always a reliable check. Always verify patch status through your package manager.

Red Hat published an nftables rule to drop incoming IPv4 TCP packets carrying IP options. While this narrows the attack surface, it isn't bulletproof and could interfere with legitimate traffic, so test thoroughly before deploying. Ultimately, installing vendor-patched kernels and rebooting your hosts is the only complete fix.

Disabling MPTCP would not address the underlying vulnerability, because ordinary TCP connections can also reach the affected IPv4 TCP code paths. The fix is to apply the vendor-patched kernel. As the Go Security Team highlighted, this workaround is fragile, a single unmanaged listener leaves the host exposed, and other attack vectors could bypass MPTCP entirely since the core bug resides in IPv4 TCP handling.

What Bitsight Internet Intelligence found

To establish a baseline before CVE-2026-98432 was disclosed, Bitsight researchers reviewed BII data from the 90 days leading up to October 15, 2026. We identified about 17.8 million internet-facing Linux services associated with affected distribution releases, across about 7.8 million IP addresses. That represented roughly 66% of the 27 million services for which we were able to identify a Linux distribution and version. 

Ubuntu accounted for 89% of the identified services, followed by Debian at 8.5%, the Red Hat family at 1.7%, and device products at 0.8% (reflected in the table below). These are service counts, not unique host counts. Open IP addresses can host multiple services. 

We chose the pre-disclosure period for analysis because no vendor fixes for this vulnerability had been released at that point. That gives us a view of potential exposure before the patching began. A scan post disclosure wouldn’t reliably establish patch status from an external distro version alone. Mostly because vendors can backport kernel fixes without changing the version visible in a service banner. 

How Bitsight can help

Bitsight External Attack Surface Management gives security teams visibility across internet-facing assets and vulnerability risks in their environments and vendor ecosystems. Paired with Dynamic Vulnerability Exploit (DVE) scores, teams get actionable threat intelligence to prioritize critical fixes.

For CVE-2026-98432, external visibility provides a strong starting point, but internal package auditing remains crucial. Because Linux vendors backport security fixes into custom package version strings, verifying local package versions internally is an essential step.

Wrapping up

CVE-2026-98432 is a high-priority Linux kernel vulnerability. Anthropic's research showed how a subtle race condition can lead to remote command execution as root in its demonstrated environment, which had an MPTCP listener. But MPTCP is not a prerequisite for exposure: ordinary TCP connections can also reach the vulnerable code paths. Red Hat's Critical rating is a clear signal for security and engineering teams to audit kernel patch levels across their server fleets.

At the same time, keep things in perspective: Anthropic didn't publish their full target environment details, and there's no evidence yet that every vulnerable host can be exploited in the wild. As of November 1, AWS reported no active exploitation in the wild.

CVE-2026-98432: What to do next

• Check security advisories from your Linux distribution maintainers.
• Apply vendor-issued kernel patches as soon as they become available, and schedule reboots to activate them.
• Track unpatched systems and re-evaluate risks as vendor guidance evolves.
• Treat network filtering or MPTCP tweaks strictly as short-term mitigations until kernel updates can be applied.
• Verify that the updated kernel is actively running after rebooting; simply downloading the package won't protect the host.