The arrayref Rust supply chain attack that poisoned three widely used Rust crates on 20 August has been attributed to the North Korean threat actor Sapphire Sleet, according to SecurityWeek. The campaign’s infrastructure overlaps with previous DPRK-linked operations, including ones targeting the Mastra and axios ecosystems, and the reach was considerable, given that arrayref was present in roughly 75% of cloud environments running Rust applications, per Infosecurity Magazine.
How the arrayref Rust supply chain attack unfolded
The attacker began by creating a GitHub account impersonating prominent Rust developer David Tolnay at 01:17 UTC, followed shortly by a matching account on the crates.io registry. At 01:55, they published proc-macro1@1.0.106, a clean copy of the legitimate proc-macro2 crate, plausible enough to avoid immediate suspicion. The malicious version, 1.0.107, followed at 07:11.
The key move came four minutes later. At 07:15, the attacker published arrayref 0.3.10 through the legitimate droundy account (the real maintainer account behind the crate) having apparently compromised it. Versions 0.3.5 through 0.3.9 were simultaneously removed from the index, a step designed to push anyone pulling a recent release straight into the malicious build. Within the same 23-minute window, two further crates were poisoned: append-only-vec 0.1.9 and internment 0.8.7, both maintained by the same account.
The attack was reported at 07:54. Crates.io deleted proc-macro1 at 08:03 and pulled arrayref 0.3.10 from the index at 08:41. SecurityWeek reports that the Rust Security Response Team removed the malicious packages roughly 86 minutes after the attack began, a fast turnaround, though not fast enough to guarantee a clean exposure window for every affected build pipeline.
The malware: compilation as the attack surface
The mechanism itself is worth unpacking. The attacker did not modify the core source of any poisoned crate, all upstream code was left intact. Instead, they injected a dependency on proc-macro1, a typosquat designed to impersonate the ubiquitous proc-macro2. A script inside proc-macro1, named build.rs, runs automatically during compilation (a standard Rust build step), at which point it reconstructs its payload from base64-encoded fragments and selects the appropriate binary for the host operating system: Linux x86-64, Windows x86-64, macOS x86-64, or macOS ARM64.
On Unix systems, the malware writes to /tmp/rust-setup, marks it executable, and launches it as a detached process. On Windows, it creates %TEMP%\rust-setup.ps1 and uses a hidden wscript.exe and VBS launcher to sustain execution. The payload receives what researchers believe to be a command-and-control address as an argument; network indicators include traffic to 23.254.165[.]112 on ports 9089 and 443.
Cloud security company Wiz’s analysis found that second-stage capabilities include exfiltrating host information and credentials. The malware queries SQLite login databases belonging to Google Chrome, Brave, and Edge. Persistence is established via the Registry Run key on Windows, LaunchAgent on macOS, and systemd on Linux. Application security company StepSecurity also confirmed the attacker published four additional crates of their own (aovine, arone, aronenao, and tinymember) which have since been removed from crates.io.
Scope: 245 million downloads and a fast-moving downstream patch
The exposure window was roughly 1.5 hours, but the potential blast radius is large. Arrayref alone has more than 245 million lifetime downloads; append-only-vec and internment add nearly 19 million more. The crate is a dependency of blake3, several Rust GUI frameworks including egui, eframe, and iced, and components used in Ethereum and Solana tooling.
One downstream response arrived quickly. According to The Hacker News, blake3 declared arrayref as a dependency through version 1.8.6, but version 1.8.7, published at 09:09 UTC on 20 August, no longer lists it, suggesting the blake3 maintainers moved to drop the dependency within hours of the incident becoming public.
Developers who pulled any of the affected crates during the exposure window should treat their environment as compromised. Recommended steps include reviewing Cargo.lock files for the malicious version strings (arrayref 0.3.10, append-only-vec 0.1.9, internment 0.8.7), checking for the dropped files on disk, and auditing outbound traffic to the C2 address above. Where compromise is confirmed, all credentials, CI tokens, signing keys, and secrets accessible from the affected environment should be rotated immediately, and the environment rebuilt from clean backups. Unaffected projects should pin to known-safe versions until the droundy maintainer situation is fully clarified.
