TL;DR
CVE-2026-98432 is a flaw in how the Linux kernel sets up IPv4 TCP connections, present in kernel 4.4 and later. The kernel's own CVE team rates it 9.8 out of 10. Anthropic reports that an unreleased Claude research model wrote an exploit that gives a remote attacker root on a Linux server with a multipath TCP (MPTCP) listener, with no credentials and no user interaction. AWS confirms that under specific conditions a remote, unauthenticated attacker could get remote code execution. As of October 29, no vendor advisory reported attacks in the wild.
How to fix CVE-2025-98432
Install a patched kernel and reboot. AWS calls this the only complete remediation, and says a livepatch also resolves the issue.
Find every affected VM first. Include forgotten hosts and the nodes under your containers. Aikido’s Virtual Machines feature flags the ones running an affected kernel.
Amazon Linux. Patched kernel packages are available for Amazon Linux 2 and 2023 across kernel 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 and 6.18.
- Amazon Linux 2: sudo yum update kernel && sudo reboot
- Amazon Linux 2023: sudo dnf update kernel --releasever=latest && sudo reboot
Kubernetes, ECS and other managed AWS services
- EKS: update managed node groups, self-managed nodes and Karpenter nodes to AMI release v20261031 or later. EKS Auto Mode replaces nodes automatically.
- ECS on EC2: update the kernel and reboot, or replace instances from ECS-optimized AMI release 20261031.
- Fargate: new tasks launched after November 1, 2026, 6:00 AM PDT use the patched platform. Existing tasks retire on your task retirement settings, or you can replace them sooner.
- Bottlerocket: updated AMIs were expected from November 2.
Other distributions. Check your vendor's tracker, because status changes daily.
- Ubuntu: fixes were in progress for 22.04, 24.04, 26.04 and 26.10 when the tracker was last updated on October 30. 20.04, 18.04 and 16.04 were listed as vulnerable with no fix.
- Red Hat: RHEL 8, 9 and 10 were listed as affected, with no fixed kernel and no release date.
- Debian, Oracle Linux and SUSE: fixed packages have shipped for at least some kernels, per The Hacker News.
Building your own kernel. The upstream fix is in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The kernel CVE team recommends moving to the latest stable kernel rather than cherry-picking the patch.
How Aikido helps
Aikido’s Virtual Machine scanning detects CVE-2026-98432 on your connected VMs, with a base severity of 9.8. Aikido adjusts severity per VM based on network reachability, so use the reachability view to see which VMs the internet can reach and patch those first.
If you haven’t connected your VMs yet, go to Virtual Machines in Aikido and select Connect VMs. Aikido supports AWS, Azure and GCP.
Detection follows vendor advisories. Where a vendor hasn’t published a fixed kernel yet, a host can be vulnerable without showing as affected, so check your distribution’s tracker as well. A host that has installed the update but not yet rebooted can show as fixed, so reboot first.
If you can't patch yet
These steps reduce exposure. None of them fixes the bug, so patch and reboot as soon as your vendor ships a kernel. AWS lists the first two as interim measures, while Red Hat says no mitigation it has reviewed is easy to deploy, suitable for most installations and stable. If you run a Go server that isn’t behind a load balancer, use the Go setting below.
- Disable MPTCP. Set net.mptcp.enabled=0. For Go 1.24 or later programs, set GODEBUG=multipathtcp=0. This matters because Anthropic's exploit needed an MPTCP listener, and Go 1.24 and later request them by default where the kernel allows MPTCP. It is a weak control: the Go Security Team calls per-program disabling fragile, since one MPTCP listener left exposed still leaves the system vulnerable.
- Drop IPv4 packets that carry IP options. AWS gives this rule: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. This matters because the flaw is in how the kernel handles the IP options stored with a pending connection, and the attack uses a SYN that carries them. On AWS Network Firewall, AWS publishes an equivalent stateful rule that needs strict rule order.
- Put the host behind a separate load balancer or managed service that terminates TCP before traffic reaches your kernel. A proxy on the same host doesn't count. Update the instances behind it anyway.
How to verify the fix is live
A kernel update only takes effect after a reboot, so check the kernel that is running, not the one that is installed.
uname -r
Compare the output with the fixed kernel version in your vendor’s advisory. Vendors backport fixes, so use their own fixed version rather than the upstream one. If it still shows the old version, the host hasn’t rebooted into the patched kernel.
Repeat this on every VM, including forgotten ones and the nodes under your containers.
Who is affected
Any Linux host running kernel 4.4 or later with an IPv4 TCP port an attacker can reach. IPv6 is not affected by the main race. On AWS, that covers self-managed EC2 and Lightsail instances, ECS on EC2 container instances and EKS nodes. AWS Lambda is not affected, because functions expose no public IPv4 TCP ports.
What sits in front of the host changes your exposure:
- AWS WAF, Application Load Balancer, Classic Load Balancer, Network Load Balancer TLS listeners, CloudFront and API Gateway. AWS says that when you follow best practices, these services don’t pass TCP connections from untrusted sources straight to your instances, and it is patching the infrastructure underneath them. It still recommends updating the instances behind them within 30 days.
- Network Load Balancer TCP listeners and Global Accelerator. AWS tells customers to update their platform version once patched versions are available.
- A proxy such as nginx or HAProxy on your own Linux host. This is not a shield. The kernel of the machine that accepts the connection handles the TCP handshake, so the proxy host needs the patch too.
For containers, the kernel that matters is the one on the node that runs them.
How serious is it?
Treat this as urgent for any internet-facing host. Three details stand out:
- A remote root exploit has been demonstrated. Anthropic's Frontier Red Team says that after initial prompting, Claude wrote an exploit that runs commands as root on a Linux server with a multipath TCP (MPTCP) listener. In its test, leaking a kernel address took 48 minutes and reaching command execution took 5 more.
- The attacker can retry. According to Anthropic, a lost race only fails that one handshake and doesn't crash the system, so a determined attacker can keep trying until it works.
- The precondition may be more common than it sounds. An application has to request MPTCP when it opens a socket, and since Go 1.24, Go programs do that by default for the sockets they listen on, according to the Go Security Team. The kernel also has to allow MPTCP, and some distributions, such as AlmaLinux and CloudLinux, ship with it off by default. Where it is on, a Go server can be a listener without anyone choosing it.
Some questions remain open. Anthropic didn't publish the exploit, the kernel version or the configuration it tested, and CloudLinux's kernel team says it couldn't reproduce the claim. The flaw sits in ordinary IPv4 TCP code, and neither the CVE record nor the kernel fix mentions MPTCP, so the Go Security Team says systems with no MPTCP listeners may be open to similar attacks. No vendor advisory had reported attacks in the wild as of October 29.
Vendors score it lower than the kernel team because they judge the race harder to win:
What is CVE-2026-98432?
In plain terms, the kernel can free a piece of memory while another CPU is still reading it. An attacker who controls the timing can use that to read or corrupt kernel memory, or crash the system, according to the kernel CVE team.
During a TCP handshake, the client sends a SYN packet and the server replies with a SYNACK. The kernel keeps the IP options from the SYN with a placeholder for the half-open connection, called a request socket. In tcp_v4_syn_recv_sock(), the new child socket takes ownership of those options without copying them. If another CPU is still building a SYNACK for a retransmitted SYN, the options can be freed while still in use. That is a use-after-free, here in ip_options_build().
Request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF reuseport migrate program) opens a similar path. The upstream fix switches the frees to kfree_rcu(), which waits until no CPU can still be reading the memory. IPv6 avoids the first issue because the kernel copies the options for IPv6 connections. A similar migration issue exists for IPv6, but it only applies where CALIPSO sets IPv6 options, and the kernel is addressing it in a separate patch.
The bug was introduced in Linux 4.4. Kernel developers applied the fix on October 5, and the CVE was published on October 15. The kernel fix credits an Anthropic researcher with reporting it.
