Build6 publishers3 min readPublished Updated
cargo build stopped being a safe verb: arrayref 0.3.10 ran a payload at compile time
The Rust Security Response Team deleted proc-macro1 and arrayref 0.3.10 on August 20 after a build script fetched and launched a binary. The lure was a yank warning.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- On 2026-08-20 at 7:15 UTC the Rust project received a report that the proc-macro1 crate was malicious; the Rust Security Response Team verified that the crate had a build script downloading a malicious payload.
- SafeDep, co-founded by Abhisek Datta, reported on August 20, 2026 that a compromised release of the Rust crate arrayref downloaded and executed malware during compilation; a developer only had to compile a project whose dependency resolution selected the poisoned release.
- arrayref version 0.3.10 added a dependency on proc-macro1, a package impersonating the legitimate proc-macro2.
- Cargo automatically compiled the proc-macro1 dependency, which caused its build.rs script to fetch and launch a binary from a remote server.
- SafeDep found that arrayref retained its familiar macro implementation and that the important change was a single dependency entry in Cargo.toml; Cargo builds declared non-optional dependencies even when the parent crate never calls them.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
On 2026-08-20 at 07:15 UTC the Rust Security Response Team received a report that the crate `proc-macro1` was malicious, and verified that it shipped a build script which downloaded a payload [1]. The operational consequence is narrow and unpleasant: on an unpinned dependency tree, compiling a project was enough to fetch and launch a remote binary, according to SafeDep, which published its analysis the same day [2].
The mechanism was one line of metadata. `arrayref` 0.3.10 added a dependency on `proc-macro1`, a package impersonating the legitimate `proc-macro2` [3]. Cargo compiled it, and its `build.rs` fetched and started a binary from a remote server [4]. SafeDep found that `arrayref` itself kept its familiar macro implementation, so the only meaningful change was that dependency entry, and Cargo builds declared non-optional dependencies even when the parent crate never calls them [5]. The typosquat also copied the real `proc-macro2` source, which kept dependent builds working while the build script ran in the background [6]. SafeDep classifies all versions of `proc-macro1` as a malicious typosquat and identifies 1.0.107 as the version carrying the downloader [7].
The build script reconstructed its server address from base64 fragments rather than putting a URL in plain sight, pulled an architecture-specific binary over TLS, and launched it detached from the build [8]. On Unix it wrote and ran `/tmp/rust-setup`; on Windows it created PowerShell and VBScript launchers in the temporary directory, started them hidden, and abandoned the child so the compiler did not wait [9].
The lure deserves attention because it inverts normal hygiene. The account controlling `arrayref` yanked versions 0.3.5 through 0.3.9 [10], five consecutive releases [11]. Cargo warns when a selected release has been yanked and suggests moving to one still available, and at the time that path pointed at 0.3.10 [12]. SafeDep quotes the reporter who encountered the package saying the warning is what led them there [13]. A developer only had to compile a project whose resolution selected the poisoned release [2].
Impersonation was cheap. The publishing account `dtolney` differs by one letter from `dtolnay`, the account used by Rust maintainer David Tolnay, and the package metadata falsely listed Tolnay as an author and pointed at a repository that did not exist under his GitHub account [14]. The evidence identifies Tolnay as the target, not a participant [15].
crates.io deleted `proc-macro1`, `proc-macro-en`, `aovine`, `arone`, `aronenao` and `tinymember`, removed the malicious `arrayref` version, and unyanked the maliciously yanked releases [16]. Two other crates from the same author, `internment` and `append-only-vec`, got the same treatment, and the account was locked [17]. The team does not believe the author acted maliciously and says their machine or credentials are likely compromised [18]. Nextron Systems GmbH's research team found it and reported it [19].
For checking: the deleted set is `append-only-vec@0.1.9`, `arrayref@0.3.10`, `internment@0.8.7`, plus any version of the six typosquats [20], three pinned versions and six whole crates [21]. The Rust blog publishes a `find` over `~/.cargo/registry/cache` for those `.crate` files [22]. SafeDep adds hashes for `proc-macro1` 1.0.106 and 1.0.107 and two network indicators, the defanged host `23[.]254[.]165[.]112` on ports 9089 and 443 [23]. Search build hosts for `/tmp/rust-setup`, `rust-setup.ps1` and `rust-setup-launch.vbs` [24]. A clean compile proves nothing, because the copied library code was designed to let builds succeed [25].
What is not known is the part that matters most: SafeDep's analysis establishes how the downloader executed but not what the second stage did after launch, or how many systems ran it [26]. Watch for the outcome of the attempt to contact the `arrayref` author [18], and for any accounting of second-stage behaviour. Until then, the yank warning is a signal to pin, not to upgrade.