A critical flaw in the Linux kernel’s IPv4 TCP stack, tracked as CVE-2026-98432, can let a remote attacker with no login run code as root on affected servers, and major Linux vendors are now shipping fixes. The bug carries a CVSS 3.1 score of 9.8 from the kernel’s CVE team. It has existed since Linux 4.4, which means a very large share of the servers, cloud instances and appliances running today are in scope.
The flaw drew wide attention after Anthropic said one of its unreleased internal research models wrote a working remote root exploit for it. That exploit has not been released, and Akamai said on November 2 that it was not aware of a public working exploit. Red Hat rates the issue Critical and has published both patches and a temporary firewall mitigation. CISA had not added CVE-2026-98432 to its Known Exploited Vulnerabilities catalog at time of publication.
How the bug works
The problem is a use-after-free race in how the kernel cleans up IPv4 option data attached to TCP sockets and connection requests. Two cleanup functions, inet_sock_destruct() and tcp_v4_reqsk_destructor(), freed that option data right away with kfree(). Other parts of the kernel can still be reading the same memory under RCU, a locking scheme that expects memory to stay valid until a grace period has passed. Freeing it early leaves a window where the kernel reads memory that may already hold something else.
To hit that window, an attacker sends a TCP SYN packet that carries IPv4 options, such as Record Route or Timestamp, and then forces retransmission during the handshake. A second trigger path exists on systems that enable TCP request migration, either through the net.ipv4.tcp_migrate_req=1 setting or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program. The first path affects IPv4 only, and kernels older than 4.4 are not affected.
The fix, written by Google kernel engineer Eric Dumazet, swaps the immediate free for kfree_rcu(), which waits until no reader can still be using the memory. It was committed upstream on October 5, 2026, and the CVE record was published on October 15.
The AI-written exploit
Anthropic’s Frontier Red Team described the exploit in an October 27 post titled Discovering and exploiting vulnerabilities in critical, real-world software with Claude. The company said an internal research model, which it has not released, built a 2-stage remote exploit against servers running a Multipath TCP (MPTCP) listener.
- Stage 1 defeats kernel address space layout randomization (KASLR) in about 48 minutes.
- Stage 2 overwrites a kernel callback pointer and reaches root command execution roughly 5 minutes later.
A failed race attempt only causes a single TCP handshake to fail, so an attacker can keep trying without crashing the target. That makes the bug far more practical than many kernel races, where a lost attempt brings down the machine. Anthropic said it is withholding the exploit code.
The work adds to a run of recent Linux root bugs. BreachNews recently reported that Linux root exploits keep piling up, but most of those required local access first. CVE-2026-98432 stands out because the attacker only needs to reach a listening TCP port over the network.
Why MPTCP matters, and why it is not the whole story
Anthropic’s exploit targets servers with an MPTCP listener, and more servers have one than administrators may expect. On October 29, the Go Security Team pointed out that Go 1.24 and later turn on MPTCP for Linux listeners by default, so many Go-based web services, proxies and APIs accept MPTCP connections without any extra setup. Setting GODEBUG=multipathtcp=0 turns that behavior off.
Red Hat warned in its security bulletin RHSB-2026-016 that MPTCP is not required for exploitation and that default systems with MPTCP disabled are still affected. Ubuntu also said disabling MPTCP is not a fix. Administrators should treat MPTCP settings as a way to shrink exposure while they patch, not as protection.
Affected and fixed kernel versions
The upstream fix landed in Linux 7.3 and in these stable releases. Any stable kernel below the listed version on its branch is vulnerable:
5.10.2725.15.2236.1.1906.6.1596.12.1136.18.567.2.10
Distribution kernels use their own version numbers, so check the vendor advisory for your system rather than comparing against upstream releases.
Vendor patch status
Red Hat issued fixed kernels on November 1, 2026. All of them require a reboot.
- RHEL 8:
RHSA-2026:93414, kernel4.18.0-553.182.1.el8_10 - RHEL 9:
RHSA-2026:93412, kernel5.14.0-687.64.1.el9_8 - RHEL 10:
RHSA-2026:93413, kernel6.12.0-211.72.1.el10_2
Red Hat said OpenShift nodes running Red Hat Enterprise Linux CoreOS are also affected, and the issue may matter for OpenStack and Red Hat Virtualization deployments. Details are on the Red Hat CVE page.
Canonical said on November 2 that fixed kernels are in the -proposed pocket for Ubuntu 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) and 26.04 (7.0.0-43.43). Ubuntu 26.10 is fixed in 7.3.0-10.10. Fixes for 16.04, 18.04 and 20.04 are still pending, and those older releases need Ubuntu Pro. Ubuntu 14.04 is not affected. The full status is on the Ubuntu CVE tracker.
Akamai said Debian, SUSE, Oracle Linux and Amazon Linux 2023 had fixes available as of October 30. AWS said in bulletin 2026-160-aws that it found no evidence of exploitation, and AlmaLinux published its own patch announcement on October 30. The original disclosure thread is on the oss-security mailing list.
How to check if a server is exposed
Start by checking the running kernel and comparing it against your vendor’s fixed version:
uname -r
Next, check whether MPTCP and request migration are turned on. A value of 1 means the feature is enabled:
sudo sysctl net.mptcp.enabled
sudo sysctl net.ipv4.tcp_migrate_req
To list services that are listening for MPTCP connections, along with the process that owns each one, run:
sudo ss -M -l -n -p -e
Any internet-facing server on a vulnerable kernel should be treated as exposed, whether or not MPTCP shows up in that list.
Temporary mitigations until you can reboot
Patching and rebooting is the only real fix. Where a reboot has to wait, Red Hat’s bulletin offers an nftables rule that drops inbound TCP packets carrying IPv4 options, which removes the trigger the exploit relies on. Save the following as cve-2026-98432.nft:
table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }
Check the file for errors, then load it:
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
Legitimate TCP traffic almost never uses IPv4 options, so the rule should not affect normal connections, but test it on a staging host first. After the patched kernel is running, remove the rule:
sudo nft delete table inet cve_2026_98432
Akamai also suggests turning off MPTCP and request migration to shrink the attack surface, while stressing that this alone does not prevent exploitation:
sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0
To keep those settings after a reboot, add both lines (without sudo sysctl -w) to /etc/sysctl.d/99-cve-2026-98432.conf. Go services can also be started with GODEBUG=multipathtcp=0. Akamai’s full analysis is in its research post.
Installing the Ubuntu fix from proposed
Ubuntu users who cannot wait for the fix to reach the regular updates pocket can enable -proposed:
sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
Canonical recommends installing the fixed kernel packages explicitly by version instead of upgrading everything from -proposed, then rebooting and confirming the new version with uname -r. Remove the -proposed pocket once the fix reaches the standard updates channel.
What this means for defenders
A network-reachable, retryable kernel bug with a proven root exploit is close to a worst case for Linux fleets. The exploit is not public, but its existence shows the bug can be weaponized, and patch diffs often help skilled attackers build their own. Security teams should put internet-facing Linux systems first, especially Go services, load balancers and container hosts, apply vendor kernels, and schedule reboots now rather than waiting for confirmed attacks. The full CVE record is at CVE.org.
