CVE-2026-98432 Linux TCP Flaw: How to Protect Your Servers

What is CVE-2026-98432?

CVE-2026-98432 is a vulnerability in the Linux kernel, the core of Linux operating systems. Its official title is ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. The Linux kernel CVE team assigned it and published the record on 15 October 2026 ^[1]. The record gives it a CVSS 3.1 base score of 9.8, which is rated Critical ^[1].

The flaw is a use-after-free: a program keeps using a piece of memory after it has been released, so the memory may already hold other data. Here, it sits in the code that handles incoming IPv4 TCP connection requests ^[10]. The CVSS vector is AV:N/AC:L/PR:N/UI:N. That means the attack works over the network, has low complexity, and needs no privileges and no user interaction ^[1].

The bug has existed since Linux 4.4, where it arrived with commit 079096f103fa ^[2]. A fix written by Eric Dumazet was committed on 5 October 2026 and is now in the mainline kernel ^[3]. It has been backported to the maintained stable branches ^[2][4].

Which systems does it affect?

Red Hat says the flaw affects any system running a vulnerable kernel with IPv4 TCP networking enabled. Systems that accept inbound TCP connections are the most directly exposed ^[6]. AlmaLinux advises treating any system that accepts IPv4 TCP connections from untrusted networks as exposed ^[10]. IPv6 is not affected by the main issue ^[2].

How does the vulnerability work?

A TCP connection starts with a handshake. The client sends a SYN packet, the server answers with a SYN-ACK, and the client confirms. A SYN can carry IPv4 options, which are optional extra fields in the IP header. Record Route and Timestamp are two examples ^[1].

According to the kernel's description, the function tcp_v4_syn_recv_sock() hands the saved options to the new child socket without copying them ^[2]. Meanwhile, another CPU core can process a retransmitted SYN for the same request and build a SYN-ACK that reads those options ^[2]. Nothing stops the child socket from being freed while the SYN-ACK is still being built. Its options are released with a plain kfree(), so the kernel reads freed memory in ip_options_build() ^[2].

A second, similar race exists when request-socket migration is turned on, either through net.ipv4.tcp_migrate_req=1 or through a BPF reuseport program ^[2]. The fix makes both release paths wait for an RCU grace period, by using kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() ^[2]. RCU (read-copy-update) is a kernel technique that delays freeing memory until no reader can still be using it.

What could an attacker do with it?

The CVE record's scoring notes describe three impacts ^[1]:

• Information disclosure: the freed memory can be reused by other data, and its contents can be copied into the SYN-ACK sent back to the attacker ^[1].
• Memory corruption: stale lengths and offsets can steer kernel writes out of bounds, with potential control-flow corruption ^[1].
• Crashes: a reused length value can trigger a kernel panic, and the stray writes can also crash the kernel ^[1].

Red Hat adds that reliably executing code through this timing-sensitive bug requires precise heap control. It still rates the bug Critical because there are no network prerequisites and it can cause severe instability ^[7].

What did Anthropic disclose, and what role does MPTCP play?

On 27 October 2026, Anthropic's Frontier Red Team published a write-up of vulnerabilities it found using Claude models ^[4][11]. For CVE-2026-98432, it says the team built an exploit that lets a remote attacker run arbitrary commands as root on Linux servers with a Multipath TCP (MPTCP) listener, without credentials or user interaction ^[4]. MPTCP is an extension of TCP that lets one connection use several network paths at once.

Anthropic describes two stages. First, the exploit leaks a kernel pointer to defeat KASLR, the kernel's address randomisation. Then it overwrites a callback pointer so the kernel runs an attacker-chosen command as root ^[4]. A lost race only fails the handshake and does not crash the system, so an attacker can keep retrying ^[4]. In Anthropic's proof of concept, leaking a kernel pointer took 48 minutes, and command execution took another five minutes ^[4].

Is MPTCP required?

No, according to the vendors that have assessed it. Red Hat states that MPTCP is not a required condition for this flaw, and that systems with MPTCP disabled remain affected ^[6]. The Go security team says the demonstrated exploit needs an MPTCP listener, but that the underlying bug is not specific to MPTCP ^[5]. Go is relevant here because Go programs have enabled MPTCP by default for listening sockets on Linux since Go 1.24 ^[5].

According to Akamai, Anthropic has not released its root exploit, and on 2 November 2026 Akamai said it was not aware of a public working exploit ^[11].

Which kernel versions and distributions are fixed?

The kernel CVE team lists these upstream fixes: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and mainline 7.3 ^[2]. Most people, though, run a kernel built by their distribution, which uses its own version numbers. Check your distribution's advisory rather than comparing upstream numbers.

Status as of 3 November 2026:

• Red Hat Enterprise Linux: fixed kernels were released on 1 November 2026 for RHEL 8, 9 and 10. RHEL 6 and 7 are listed as not affected. The RHEL 9 real-time kernel and OpenShift node images are still listed as affected ^[7].
• Ubuntu: Ubuntu rates the issue Critical. Its tracker shows 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS as vulnerable with fixes in progress; 20.04, 18.04 and 16.04 are also listed as vulnerable, and 14.04 as not affected ^[8].
• Debian: fixes are available for Debian 12 bookworm (linux 6.1.190-1 and linux-6.12 6.12.113-1~deb12u1) and Debian 13 trixie (linux 6.12.113-1), and for unstable ^[9].
• AlmaLinux: fixed kernels for AlmaLinux 8, 9 and 10 are in the production repositories ^[10].
• Others: Akamai reported that SUSE, Oracle Linux and Amazon Linux 2023 had released fixed kernels for some releases by 30 October 2026 ^[11].

What about Android phones?

Android uses the Linux kernel, but the Android Security Bulletin published on 2 November 2026 does not list CVE-2026-98432 ^[13]. Phone owners should install security updates as their manufacturer releases them.

How do you check whether a server is vulnerable?

1. Find the running kernel. Run uname -r. A fix only counts once the machine has rebooted into the new kernel. AlmaLinux tells users to reboot and confirm the version with uname -r ^[10].
2. Compare with your vendor's tracker. Look up CVE-2026-98432 on your distribution's security page. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] and AlmaLinux ^[10] each list the package versions that contain the fix.
3. Check MPTCP. sysctl net.mptcp.enabled shows whether MPTCP is on. sudo ss -lnMp lists MPTCP listeners and the processes that own them ^[10]. Akamai also suggests checking net.ipv4.tcp_migrate_req ^[11].
4. Look for Go services. Go programs built with Go 1.24 or later open MPTCP listeners by default on Linux ^[5]. Any Go service you run may therefore expose the path Anthropic exploited.
5. Check layered products. Red Hat warns that any product built on the RHEL kernel, including OpenShift, OpenStack and Red Hat Virtualization, may also be affected ^[6].

How do you fix or mitigate CVE-2026-98432?

The real fix is a patched kernel. Red Hat calls applying kernel updates the only complete solution ^[6], and the Go security team says the best fix is to upgrade to a patched kernel ^[5]. Install your distribution's kernel update, reboot, and confirm the running version.

What can you do before a patch arrives?

• Drop TCP packets with IPv4 options. Red Hat publishes, and Ubuntu's tracker lists as a user-contributed workaround, an nftables rule that drops incoming IPv4 TCP packets whose IP header is longer than the basic 20 bytes, that is, packets carrying options (ip hdrlength > 5) ^[6][8]. Normal TCP options such as timestamps and window scaling live in the TCP header and are not affected ^[8]. Both vendors say the rule reduces risk but cannot fully prevent exploitation ^[6][8].
• Know the rule's limits. AlmaLinux notes that its version does not survive a reboot, that traffic between containers on the same host may bypass it, that it also drops forwarded packets on routing hosts, and that it breaks networks relying on CIPSO/NetLabel labels ^[10]. Ubuntu notes that containers with separate networking need the rule applied separately ^[8].
• Disable MPTCP if you do not need it. Setting net.mptcp.enabled=0 turns MPTCP off system-wide ^[10]. Akamai also suggests setting net.ipv4.tcp_migrate_req=0 ^[11]. Akamai warns that disabling MPTCP alone does not prevent exploitation; it only lowers the chance of triggering the race ^[11]. Go programs can also opt out with GODEBUG=multipathtcp=0, but the Go team calls per-program opt-outs fragile ^[5].
• Filter at the edge. For OpenShift, Red Hat notes that rules on a node do not filter pod-to-pod traffic, while filtering at the network boundary in front of the cluster avoids that limit ^[6].

Does init_on_free=1 help?

One oss-security post suggested the init_on_free=1 boot option as an extra stopgap. A member of the kernel team at CIQ replied that it does not meaningfully mitigate this CVE and should not carry weight in advisories ^[12]. Treat it as general hardening, not a mitigation for this bug.

Is CVE-2026-98432 being exploited?

As of 3 November 2026, CVE-2026-98432 does not appear in CISA's Known Exploited Vulnerabilities catalog, the US government's list of flaws with confirmed real-world exploitation ^[14]. Akamai said on 2 November 2026 that it was not aware of a public working exploit ^[11]. That is not proof that nobody is exploiting the bug. A reliable exploit has been shown to exist ^[4], and the technical details are public in the kernel fix ^[3].

The severity picture also shifted over time. The CVE was first published on 15 October 2026 ^[1]. Wider attention followed Anthropic's 27 October write-up ^[4][11]. Vendor bulletins with interim mitigations followed between 29 October and 2 November ^[5][6][10]. Administrators who skimmed the original record may have missed the later guidance.

What happens next?

Red Hat describes its investigation as ongoing and says its bulletin will be updated as new information emerges ^[6]. Expect remaining packages, such as the RHEL 9 real-time kernel and OpenShift images ^[7] and the Ubuntu kernels still in progress ^[8], to receive fixes over the coming days or weeks. Check the vendor trackers rather than news summaries, because these pages changed several times in the first weeks.

The kernel fix also leaves one related issue open. The kernel description says IPv6's tcp_v6_reqsk_destructor() has the same migration problem with options set only by CALIPSO, and that this will be handled in a separate patch ^[2]. Under Anthropic's coordinated disclosure policy, it allows 90 days for patching plus 45 more days before discussing details beyond the public advisory ^[4]. More technical detail may therefore appear later.

This is general technical information, not a substitute for your vendor's security advisory or your organisation's incident-response process.