Anthropic disclosure October 27, 2026; distribution status checked October 30, 2026
An AI Model Built a Remote Root Exploit for a Linux Kernel Flaw: The Claim, the Caveat, and the Patch Gap
Anthropic disclosed on October 27 that an unreleased Claude research model built a working zero-click exploit for CVE-2026-98432, a race-condition use-after-free flaw in the Linux kernel IPv4 TCP connection code, reaching remote root command execution against a server running a Multipath TCP listener in about 53 minutes from initial memory leak to root. The flaw, introduced in Linux 4.4 and scored 9.8 by the kernel CVE team, comes from the kernel handing IP options from a pending connection to a new socket without a copy, so a retransmitted connection request handled on another processor can read the options after they are freed; the upstream fix, applied October 5, defers the free until readers finish. Fixed kernel releases include 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, and 6.18.56. The caveats matter as much as the claim. The exploit is not public, no exploitation in the wild has been reported, the flaw is not in the CISA KEV catalog, and CloudLinux kernel team, writing October 30, said it could not reproduce the remote root claim and that triggering the memory error is far from running code remotely. Severity assessments also diverge: Red Hat rates the flaw lower than 9.8 on its own pages, citing the difficulty of winning the timing race. Distribution readiness diverges too: Debian, Oracle Linux, SUSE, and Amazon Linux had fixed packages for at least some releases by October 30, while Ubuntu and Red Hat Enterprise Linux had not yet released patched kernels. Multipath TCP is opt-in and off by default in several distributions, but the underlying flaw sits in ordinary TCP code, so a server with Multipath TCP disabled still runs the vulnerable path and still needs the kernel fix.
Executives
Hold two facts at once: a frontier AI model produced a remote root exploit chain for a real kernel flaw in under an hour of machine time, and an independent kernel team could not reproduce that result and no one is exploiting the flaw in the wild today. The decision this supports is not panic, it is sequencing: put the kernel update at the front of the next maintenance window, and treat AI-assisted exploit development as a standing reason why the gap between a published fix and your reboot now carries more risk than it used to.
CIO / CISO
Inventory by kernel version and by distribution fix status, because the answer differs by vendor this week: Debian-based estates may already have the package, while Ubuntu and Red Hat estates were still waiting on October 30 and need a tracked exception with a date, not an assumption. Record whether any server exposes a Multipath TCP listener, since that is the configuration the demonstrated exploit required, and note in the risk register that the flaw itself is in ordinary TCP code, so disabling Multipath TCP is a scoping fact, not a mitigation. Red Hat states no mitigation meets its criteria; the kernel update or a vendor livepatch is the fix.
Engineers
Check the setting and the version separately: sysctl net.mptcp.enabled tells you whether the demonstrated attack surface exists, and uname -r against your distribution fixed release tells you whether the code is patched. Remember that installing a kernel package changes nothing until the reboot or livepatch activates it. Where your distribution has not shipped the fix, document the exposure, keep the host off any new internet-facing role, and apply the package the day it lands rather than folding it into a monthly cycle.
Everyone (non-IT)
Nothing here asks individual users to do anything, and no attacks using this flaw have been reported. If your IT team schedules a server reboot sooner than usual in the next two weeks, this disclosure is the likely reason: the fix for a kernel flaw only takes effect once the machine restarts on the new kernel.