Failing Costs the Attacker Nothing, Which Is Why a 53 Minute Kernel Exploit Works

Anthropic published enough of the chain to check the work. Stage one abuses the race to make the kernel read an attacker-controlled length field, copy extra bytes, and send them back in the reply. One reply carrying a kernel pointer is enough to defeat KASLR. Stage two reuses the same bug to overflow a buffer and overwrite a callback pointer with a payload already staged in kernel memory. When the kernel invokes the callback, the payload chains existing kernel functions and ends in a shell command as root.

The bug itself is ordinary. The kernel advisory describes tcp_v4_syn_recv_sock transferring ownership of a socket option to a child socket without copying it, while another CPU processes a retransmitted SYN for the same request socket. The option gets freed while still in use. Kernel advisories are full of that shape.

A lost race only fails the handshake, so the attacker loops

The Anthropic write-up has the line worth keeping. A lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In the proof of concept, 48 minutes to leak a kernel pointer, another five to reach the shell command.

That reframes what exploitable means. A severity rating built around attack complexity assumes a window the attacker has to hit. A free retry loop removes the window and leaves the clock. An attacker with a list of targets pays that clock in parallel, across every host that answers. Between the packet stream and root sits a kernel that either has the fix or does not.

Go 1.24 moved the listener default without anyone noticing

MPTCP lets a connection use several network paths at once, and it was opt-in on the Go side for years. Go 1.21 added support and used it only when a program asked. The Go 1.24 release note changed that in one sentence. ListenConfig now uses MPTCP by default on systems where it is supported, currently Linux only. The GODEBUG record puts the toolchain default at multipathtcp set to 2, which means enabled on listeners.

Read that against the stack. The Kubernetes control plane, etcd, containerd, Prometheus, Cilium and most operators are Go binaries. Build any of them with a modern toolchain, run them on a kernel with MPTCP compiled in, and the listener is an MPTCP listener unless someone set the knob. Most teams never touched the knob, because until now there was no reason to.

Turning MPTCP off is a mitigation, not a fix

The reflex is to disable the feature, and there are two places to do it. Set multipathtcp=0 via godebug in the module, or set net.mptcp.enabled on the host. Anthropic calls the per-program route fragile, for two reasons. One listener left exposed still leaves the system reachable, and the underlying bug is not MPTCP specific.

Anthropic says systems with no MPTCP listener may still be reachable by similar attacks, and that the fix is a patched kernel. That framing matters for anyone tempted to turn a flag into a permanent answer.

Three questions worth answering this week. Which nodes run a kernel older than the backport, and what is the real count rather than the inventory count. Which services in your fleet build with Go 1.24 or later and accept TCP traffic. And if the answer is a node reboot, how long does your drain take on a full cluster.

Related reading. Our container escape piece covers the last kernel flaw that put Ubuntu patch timing on the critical path. NGINX called a 9.2 flaw medium is the same argument about who owns the severity number. And CISA adding three kernel bugs to its exploited list shows what the end state looks like when a kernel window stays open.