Rust removed a malicious arrayref@0.3.10 release on August 20, 2026, after it was available on crates.io for 86 minutes. The release made projects pull in a dependency whose build script downloaded a malicious payload, putting developer laptops and CI runners, not only shipped binaries, on the exposure path.
The incident was wider than one poisoned package. The Rust Security Response Team says a likely compromise of the arrayref author’s computer or credentials also led to malicious releases of append-only-vec@0.1.9 and internment@0.8.7, plus six newly created crates designed to look like ordinary dependencies. Existing projects with committed Cargo.lock files would not ordinarily have auto-upgraded into the malicious versions.
Rust said it received a report at 07:15 UTC from Nextron Systems GmbH, a German security vendor, that proc-macro1 was malicious. The team verified that the crate contained a build script that downloaded a payload, then deleted it alongside proc-macro-en, aovine, arone, aronenao, and tinymember.
“The Rust Security Response Team verified this to be the case: the crate had a build script that was downloading a malicious payload.”
The Rust team attributed that finding to its August 20 incident disclosure. That disclosure is also the only technical incident account cited here; it does not establish what the payload did, how many machines ran it, who controlled it, or whether any victim was compromised.
Cargo build scripts are executable code that runs during a build. When a package includes a build.rs file, Cargo compiles and executes it before compiling the rest of that package. In this case, a developer or CI job that fetched and built a poisoned dependency could have run the downloader simply by performing a normal dependency build.
That makes the immediate response an environment investigation: inspect Cargo.lock files and dependency graphs, review CI logs from the incident window, and search local Cargo caches for the exact three deleted versions or any version of the six malicious lookalike crates. Teams responding to the poisoned VS Code extension exposure faced a similar distinction between a compromised package being available and a particular machine actually installing it.
The three malicious crate releases were online for 86 to 107 minutes
The three established crates had short but meaningful availability windows:
| Malicious release | Time online |
|---|---|
arrayref@0.3.10 |
86 minutes |
internment@0.8.7 |
90 minutes |
append-only-vec@0.1.9 |
107 minutes |
Rust also said the attacker had maliciously yanked earlier legitimate releases, which the response team restored. A yank removes a version from Cargo’s registry index for fresh dependency resolution, but it does not erase the downloadable package archive or copies already in local caches, as the Cargo documentation explains.
The yanks could therefore have made a fresh dependency solve more likely to choose a newer attacker-controlled version. Cargo generally prefers the highest compatible version available. But Rust’s disclosure does not establish that this was the attacker’s intent or identify a project whose resolution changed because of the yanks.
A committed lockfile is the practical dividing line. Cargo stores a dependency resolution in Cargo.lock, keeping selected versions fixed over time. Cargo’s own yank documentation says yanked releases are not selected for a new checkout without an existing lockfile, while existing lockfiles and direct downloads are unaffected.
So this was not an emergency for every Rust project using arrayref. It was an emergency for projects that generated or refreshed a lockfile, ran an unlocked build, or otherwise downloaded one of the affected releases between publication and removal. Claims that identify arrayref@0.6.7 as the poisoned release conflict with Rust’s official record, which names arrayref@0.3.10.
The incident also offers a reason to treat dependency age as a security control rather than an inconvenience. Cargo’s min-publish-age option could hold newly published packages out of fresh resolutions; the tracking issue says -Zmin-publish-age was available only on nightly as of June 21, 2026, with stabilization work unresolved. A delay can require exceptions when a security fix is urgent, but it would have excluded releases published minutes earlier.
Rust has locked the affected account as a precaution and said it did not believe the arrayref author acted maliciously. The containment work removed the malicious registry entries; the harder job for engineering teams is determining whether an 86-minute package release ever reached a machine that was allowed to build it.
Key Takeaways
- Rust deleted
arrayref@0.3.10after the malicious release was online for 86 minutes. - The same account also published poisoned versions of
append-only-vecandinternment. - The malicious dependency used a Cargo build script to download a payload during package builds.
- Existing builds with committed
Cargo.lockfiles would not ordinarily select the new malicious versions. - Teams should inspect lockfiles, dependency graphs, CI logs, and local Cargo caches for the affected releases.
Further Reading
- Supply chain attack on arrayref, Rust Security Response Team disclosure naming the malicious packages, timeline, and response.
- cargo yank – The Cargo Book, Documentation on what yanking changes and what it leaves behind.
- Dependency Resolution – The Cargo Book, Documentation on Cargo’s lockfiles and version-selection behavior.
- Build Scripts – The Cargo Book, Documentation on when Cargo executes package build scripts.
- Tracking Issue for min-publish-age RFC 3923, Cargo’s tracking issue for delaying newly published dependencies in resolution.