The arrayref compromise took 23 minutes to publish and 130 to remove

The figure is a subtraction, not a headline number. Rust's Security Response Team published exact timestamps: arrayref 0.3.10 went up at 07:15:00Z on 2026-08-20 ^[2], internment 0.8.7 at 07:34:07Z ^[3], append-only-vec 0.1.9 at 07:37:49Z ^[4]. That is 22 minutes and 49 seconds to poison three packages with roughly 264 million combined lifetime downloads ^[1][8][2]. Removal was slower: the report arrived at 07:15 UTC and the last malicious version was deleted at 09:25:24Z, about 130 minutes later ^[1][4][4].

What the 23 minutes turns on is that publishing was the cheap part. None of the three crates carried the payload; each simply added a dependency on proc-macro1, a typosquat of proc-macro2 ^[8][10]. The library source of proc-macro1 1.0.107 is a renamed copy of the real crate with the author field spoofed as David Tolnay, and the only attacker-added runtime sits in build.rs alongside three build-dependencies proc-macro2 does not need: ureq, rustls and base64 ^[11]. Cargo compiles and runs build.rs automatically during cargo build, cargo check, CI jobs and rust-analyzer driven builds ^[9]. So a metadata edit measured in minutes buys execution on every machine that later resolves a fresh lockfile.

The constraint on blast radius was lockfiles, not detection speed. arrayref 0.3.10 was downloaded 2,285 times in its 86 minutes online, under 10 percent of arrayref traffic across all versions, because most users had older versions pinned ^[7][2] - roughly 27 downloads a minute ^[3]. The build script disabled TLS verification and fetched a stage two from 23.254.165.112:9089, writing /tmp/rust-setup on Unix and a PowerShell script plus a VBS launcher on Windows to escape Cargo's job object ^[12][13]. That endpoint did not respond when JFrog looked, so the payload was never recovered, which is why JFrog's guidance is to treat confirmed execution as full host compromise and rotate credentials from any developer machine or runner involved ^[14][15].