A CVE announcement from Greg Kroah-Hartman dated October 15 carries the whole technical story in a few lines, and Anthropic's research post carries the exploitation story. Between them, this is the most consequential networking-stack disclosure for community infrastructure this year, and the part to act on is one line long: the Debian family has already shipped fixed kernels — find out if the box you are reading this on is running one (this machine is: 7.2.12, forky's fixed version).

The bug, from the kernel CVE team

The mechanism is small and eleven years old. tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt (the IP options) to the child socket without copying it. Since commit 079096f103fa — "tcp/dccp: install syn_recv requests into ehash table", which entered 4.4 in October 2015 and removed the listener lock from request-socket processing — nothing prevents the child socket from being freed while a concurrent CPU processes a retransmitted SYN for the same request and sends its own SYNACK. The SYNACK path reads ireq->ireq_opt under rcu_read_lock() only, and ip_options_build() reads opt->optlen twice — so the reader can be between the two reads when inet_sock_destruct() frees the options with a plain kfree(). A use-after-free in ip_options_build(). A second, related window exists in request-socket migration (net.ipv4.tcp_migrate_req=1 or a BPF reuseport program), where a clone shares ireq_opt with the original through the same plain kfree() in tcp_v4_reqsk_destructor().

The fix is exactly as boring as this site insists the good ones should be: use kfree_rcu() in both destructors, like every other path that swaps IP options already does. IPv4 only — the IPv6 handshake path duplicates the options on accept. One footnote from the announcement worth tracking: the IPv6 request-socket-migration variant (reachable only through CALIPSO options) has the same shape and gets a separate patch.

The exploit, from Anthropic

Anthropic's post is a report on five attack chains produced by an internal, unreleased research model, run systematically across "browsers and operating systems" with a platform that parallelizes scanner agents and tracks coverage. The Linux chain is the fifth, and it is fully built out, not a crash PoC:

  1. Stage one, remote KASLR defeat. The race makes the kernel read an attacker-controlled length field and copy extra bytes, which leak back to the attacker. Any overread containing a kernel pointer reveals the address-space layout.
  2. Stage two, control-flow hijack. The same use-after-free overflows a buffer, and the exploit overwrites a callback pointer with an address whose payload was pre-staged in kernel memory through an ordinary protocol feature. The chained calls end with the attacker's shell command running as root.

Two properties make the weapon practical rather than theoretical. The race is forgiving: a lost race only fails the handshake, it does not crash the machine — so the attacker iterates indefinitely. Anthropic's proof of concept took 48 minutes to leak a kernel pointer and five more to reach the shell. And the entry requirement is one MPTCP listener on the target, because multipath TCP is exactly the handshake path where the racing retransmission is available.

The same post's other chains are a useful calibration of what the platform is producing generally: 62 CVEs assigned against Chrome, patched as of Chrome 156, all critical or high — a one-click sandbox-escape chain assembled from four separate bugs (V8 heap corruption, a memory-sandbox escape via ROP, a CacheStorage race, a FedCM use-after-free); a data-only same-origin-policy bypass in Safari via a JavaScriptCore UAF, a Gigacage escape and a sandbox-IPC bug; an Android lock-screen bypass that extracts data over USB from a stolen phone; and a remotely-triggerable crash loop against the Windows QUIC implementation (CVE-2026-33096), found by binary analysis with Ghidra, with "several million" internet-listening HTTP/3 servers in scope. Every one went through coordinated disclosure — 90 days to patch, 45 additional before detail discussion — with Apple acknowledging its report the same day and shipping a fix promptly, and Google patching Chrome's sixty-two in a stable release.

What the Go security team measured

The exposure math for community boxes is Go's own announcement from October 29, and it is blunter than most of the coverage:

  • Since Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux. The Go runtimes of the community self-hosted world — the git forges, the proxies, the webhooks, the dashboards — are MPTCP listeners by default on any remotely modern Go.
  • "The underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks." The demonstrated exploit needs the MPTCP listener; the bug family does not.
  • Per-program MPTCP disabling is called a fragile mitigation by the team shipping the runtime — one missed listener re-exposes the box — and their recommendation is to patch the kernel. The knobs exist for the gap: GODEBUG=multipathtcp=0 at runtime, godebug multipathtcp=0 in go.mod at build time, or per-socket SetMultipathTCP(false); Go is tracking a possible default change in issue 82717.

No public exploit exists. No exploitation in the wild is documented. The PoC is held by the reporter under a disclosure policy that leaves 90+45 days of silence behind patched advisories. The correct reading is not "this is being shot at" — it is "the shot is reproducible by whoever is willing to spend 53 minutes of compute the next time someone does this, against code that took an unfilmed research platform to find in the first place."

What to actually do

The kernel CVE team's fix landed October 15 in 6.12.113, 6.18.56, 7.2.10 and 7.3-rc7, backported to all maintained stable branches. Debian's tracker — Devuan inherited the following verbatim, being Debian by the design choice this site's first essay argued:

| Release | Fixed in | Shipped via | |---|---|---| | bookworm (kernel 6.1 line) | 6.1.190-1 | DLA-4841-1 | | bookworm (6.12 line, linux-6.12) | 6.12.113-1~deb12u1 | DLA-4850-1 | | trixie (6.12 line) | 6.12.113-1 | DSA-6568-1 | | forky (7.2 line) | 7.2.12-1 | tracker: fixed | | sid | 7.2.14-1 | tracker: fixed |

Every one of these arrives through the security repository, so the practical check is mechanical. On the hosts you run: uname -r against the table, and where the box is behind, apt update && apt install linux-image-amd64 from the security line, then reboot. For anything where a reboot is a maintenance window — a community's single forge box, a clinic's appliance — the two-stage PoC math makes the honest weighing easy: 53 minutes of one attacker's patience is cheap insurance against a window you control the timing of, and a missed reboot is a window an attacker controls the timing of. Take your own.

Two caveats stated plainly, because this site exists to avoid its own hype. First: the demonstrated exploit requires an MPTCP listener; if your kernel is patched, the whole question is closed, and if it is not, the MPTCP knobs are a stopgap the Go team itself calls fragile — the risk does not need the listener to be real. Second: the race conditions that make this exploitable at all are the kind a codebase accumulates for eleven years without a single human noticing; the fix commits were reviewed by multiple people in 2015 and the bug shipped anyway. The code was never sloppily written. It was merely big.

The part worth copying

The lifecycle here worked, and it worked at the speed the community infrastructure world needs. A model running under a research platform found an 11-year-old bug in the most-reviewed network stack on the planet, built a working zero-click root exploit to prove it, reported it, upstream fixed and backported it into every maintained stable branch, CVE entry landed October 15, Debian's stable lines carried the patch within roughly two weeks, and the Go security team published an exposure note for its runtime within a further two. Five parties, ten weeks, no hype anywhere.

The part this site keeps coming back to — from the mass-produced authorization bugs in the forge advisories to ESR's closed-source-is-over claim — is that the method is now the product: scanner-diversity platforms running agents in parallel, per-scanner contribution measured, findings funneled through uniform verification, with a documented 90+45-day disclosure clock and the PR-time scanning practice built as a plugin rather than a press release. Anthropic's own words in the same post: "fixing the existing backlog only solves half the problem; the other half is cutting the rate at which new vulnerabilities enter the codebase." A community that inspects its own infrastructure can run the same loop with open tooling or with the released method — the loop is the auditable part, and the loop is what you can copy. Everything else about this story — the CVE number, the severity score, the 48 minutes — is someone else's meter running on your box.