A bug in the Linux kernel's IPv4 TCP handshake code, present since Linux 4.4, can be reached with crafted SYN packets before any application sees the connection. Last week Anthropic's Frontier Red Team said an unreleased AI model turned it into a zero-click remote root exploit in about 53 minutes, and most fleets are still waiting on a reboot.
AG Tech Consulting's advice for clients this week: treat CVE-2026-98432 as an internet-facing emergency, not a routine kernel update. Patch and reboot every Linux host that accepts IPv4 TCP from untrusted networks, starting with the edge. Use the nftables, iptables or MPTCP stopgaps only to buy days, inventory every MPTCP listener and Go-built service, and shorten your kernel patch window, because exploit-writing time just collapsed.
What happened
On 15 October the Linux kernel CVE team published CVE-2026-98432, "ipv4: free inet_opt and ireq_opt after an RCU grace period". The kernel CNA scores it CVSS 9.8.
On 27 October Anthropic published "Discovering and exploiting vulnerabilities in critical, real-world software with Claude". It describes five attack chains built by an internal research model, including a Chrome one-click RCE, a Safari same-origin bypass, an Android lock screen bypass, a Windows remote DoS (CVE-2026-33096) and this Linux zero-click RCE.
Anthropic's wording on Linux is blunt: "After initial prompting, Claude wrote an exploit that allows a remote attacker to send packets to Linux servers with a multipath TCP listener to run arbitrary commands as root, without any credentials or user interaction."
Anthropic has not published the exploit. AWS, BleepingComputer and pwn.watch report no confirmed exploitation in the wild, and the CVE is not in CISA's KEV catalog.How the exploit works
The bug lives in how the kernel handles IPv4 options carried on a SYN.
The kernel keeps those options with the pending connection so it can echo them in the SYN-ACK. When the handshake completes, tcp_v4_syn_recv_sock() hands that copy to the new child socket (newinet->inet_opt) without duplicating it.
If the client retransmits its SYN, another CPU can build a SYN-ACK from the same options in tcp_check_req(). Those readers hold only rcu_read_lock(), and ip_options_build() reads opt->optlen twice.
Meanwhile the child socket can be freed. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() released the options with a plain kfree(). The result is a use-after-free in ip_options_build().
The race became reachable with commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), which lets request sockets be processed without the listener lock. A similar path exists with request socket migration (net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program).
The upstream fix, commit e3f33b0a1d89 by Eric Dumazet and reviewed by Kuniyuki Iwashima, switches inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu(). IPv6 is not affected by the first issue because tcp_v6_syn_recv_sock() duplicates the options.
Anthropic's exploit runs in two stages:
Stage 1, remote KASLR defeat: the race makes the kernel read an attacker-controlled length field, copy extra bytes and send them back. One overread that contains a kernel pointer reveals the memory layout. Stage 2, code execution: the same use-after-free overflows a buffer and overwrites a callback pointer with the address of a payload staged in kernel memory "via an ordinary protocol feature". The payload chains existing kernel functions and ends with a shell command as root.
The detail that matters for defenders: "a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." The proof of concept took 48 minutes to leak a kernel pointer and five more to reach command execution.
Who is exposed
AlmaLinux puts it plainly: "Any AlmaLinux system that accepts IPv4 TCP connections from untrusted networks should be treated as exposed." The same logic applies to other distributions on affected kernels.
Anthropic's demonstrated exploit needs an MPTCP listener. The Go security team flags why that is common: "As of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux."
But MPTCP is not the bug. Go's team warns that "the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks." CIQ, per BleepingComputer, says disabling MPTCP alone is insufficient for Rocky Linux.
Red Hat's bulletin sums up the scope: "Since TCP is fundamental to nearly all networked services, the affected surface is broad." RHEL 7 is not affected, and BleepingComputer reports macOS is not affected.
What the vendors shipped
Status as of the morning of 2 November (IST):
Upstream stable: fixed in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7. Red Hat: rated Critical, CVSS 9.8, after an initial 5.9. Kernel errata dated 1 November: RHSA-2026:93414 and RHSA-2026:93415 (RHEL 8, kernel-4.18.0-553.182.1.el8_10), RHSA-2026:93412 (RHEL 9) and RHSA-2026:93413 (RHEL 10). OpenShift Container Platform 4 is still listed as affected. AlmaLinux: patched kernels in the testing repo for 8, 9 and 10, shipped ahead of RHEL. Debian: fixed in bookworm security (6.1.190-1, DLA-4841-1) and trixie security (6.12.113-1, DSA-6568-1). Ubuntu: priority High; 22.04, 24.04, 26.04 and 26.10 kernels, including the AWS, Azure and GCP flavours, still show "Vulnerable, work in progress". AWS: Amazon Linux 2 and 2023 kernels are out; EKS-optimized AL2023 AMIs v20261031; EKS Auto Mode nodes are replaced automatically by 6 November; Bottlerocket AMIs expected from 2 November. Self-managed EC2 kernels remain the customer's job. Applications: Lightning Labs' lnd v0.20.7-beta turns off MPTCP listeners by default, as a mitigation rather than a fix.
A public research toolkit appeared on GitHub on 30 October. Per pwn.watch, it triggers the race and leaks kernel memory in a lab, and its README says it is not a root exploit.
Why stopgaps are not fixes
AWS is explicit: "A kernel update and reboot is the only complete remediation." Every interim control below has a gap.
Dropping IPv4 packets with options. Red Hat's nftables rule drops TCP packets whose IP header is longer than 20 bytes:
table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }
Red Hat says it "reduces exposure to this vulnerability but cannot fully prevent it". AWS publishes an equivalent iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. AlmaLinux adds caveats: the rule does not survive a reboot, container-to-container traffic on the same host may bypass it, forwarded TCP packets with options are dropped too, and it must not be used with CIPSO/NetLabel.
Disabling MPTCP. net.mptcp.enabled = 0 only stops new MPTCP sockets, so existing listeners need a restart; ss -lnMp lists them. In Go, GODEBUG=multipathtcp=0 or godebug multipathtcp=0 in go.mod changes the default. The Go team calls per-program disabling "a fragile mitigation" because one forgotten listener keeps the system exposed.
The future security risk: exploit time is collapsing
Anthropic says exploit building is now "something models can do with little human involvement". The same post lists 62 Chrome CVEs from this work, all critical or high, patched as of Chrome 156.
Google Threat Intelligence Group, reported by Help Net Security on 1 October, saw one threat cluster exploit an AI-discovered BeyondTrust flaw (CVE-2026-1731) within four days of public disclosure, and five more within seven days.
Four risks to plan for:
1. The n-day window shrinks. GTIG suspects attackers use LLMs to analyse patches and proofs of concept "to rapidly weaponize n-days". A public fix commit is now a starting gun.
2. Kernel reboots become the bottleneck. The upstream fix was public by 15 October; Red Hat's errata arrived on 1 November and Ubuntu's are still pending. Fleets that reboot monthly carry exposure long after a vendor fix exists.
3. Defaults widen the attack surface quietly. A language runtime default (Go's MPTCP listeners) decided which servers matched the demonstrated exploit, not an architecture review.
4. Severity scores lag reality. Red Hat first rated this 5.9 before moving to 9.8. Triage that waits for scores, or for KEV, will be late.
Checklist for this week
Inventory every Linux host that accepts IPv4 TCP from untrusted networks: load balancers, API gateways, bastions, VPN endpoints, Kubernetes nodes. Install the fixed kernel from your vendor and reboot; confirm with uname -r that the running kernel matches. Replace node images rather than patching in place where you can (EKS AMIs v20261031, Bottlerocket, OpenShift updates as they land). Track Ubuntu and OpenShift daily until fixed packages are published, and patch the same day. Run sysctl net.mptcp.enabled and ss -lnMp across the fleet to find MPTCP listeners. Find Go 1.24+ services and set godebug multipathtcp=0 until kernels are patched, knowing it is a stopgap. Deploy the nftables or iptables options-drop rule on unpatched edge hosts after testing, and make it persistent across reboots. Check whether you use net.ipv4.tcp_migrate_req or CIPSO/NetLabel before applying rules. Add kernel network-stack CVEs to your emergency patch path with a target measured in days, not a monthly cycle. Ask your managed providers and appliance vendors, in writing, when their Linux kernels will be fixed.
Bottom line
This is a remote, unauthenticated bug in code every Linux server runs, and an AI model turned it into root in under an hour. The fixes exist for most major distributions; the gap now is reboots.
Patch the kernel, reboot, and treat MPTCP and firewall rules as bridges, not destinations.
Sources
https://lists.openwall.net/linux-cve-announce/2026/10/15/1 https://git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b https://www.anthropic.com/research/discovering-vulnerabilities-with-claude https://groups.google.com/g/golang-announce/c/PCoQcdxoScw https://go.dev/issue/82717 https://access.redhat.com/security/vulnerabilities/RHSB-2026-016 https://access.redhat.com/errata/RHSA-2026:93414 https://almalinux.org/blog/2026-10-30-cve-2026-98432/ https://security-tracker.debian.org/tracker/CVE-2026-98432 https://ubuntu.com/security/CVE-2026-98432 https://aws.amazon.com/security/security-bulletins/2026-160-aws/ https://www.bleepingcomputer.com/news/security/linux-kernel-exploit-enables-remote-root-attacks-on-mptcp-servers/ https://pwn.watch/i/linux-kernel-ipv4-tcp-uaf-cve-2026-98432 https://www.helpnetsecurity.com/2026/10/01/google-ai-discovered-vulnerabilities-remote-code-execution/
Also on our website: https://agtechconsulting.ai/insights/your-linux-servers-answer-every-syn-ai-turned-it-into-remote-root.html
Want help finding every exposed Linux listener in your estate, building a days-not-months kernel patch path, or testing stopgap rules before they hit production? Email avinash@agtechconsulting.ai, visit agtechconsulting.ai, or book a 30-minute call: https://calendly.com/avinash-dubey-30-min-catchup/meeting-with-ag-tech
Thanks to Anthropic , The Linux Foundation , Red Hat , Canonical , Debian , AlmaLinux , CIQ , Rocky Linux , Amazon Web Services (AWS) , Golang , Google , Lightning Labs , BleepingComputer , Lawrence Abrams , Help Net Security , Eric Dumazet , Kuniyuki Iwashima , Greg Kroah-Hartman for the work this builds on.
Originally published on LinkedIn in the Your CTO Advisor newsletter: read and comment on LinkedIn →
