Most supply chain warnings tell a team to be careful about what code they run. This one is about code nobody ran on purpose, because it executed before the build even started.
Three crates, one compromised account, 86 minutes
On 20 August, an attacker with access to a maintainer’s crates.io account published new releases of three unrelated Rust packages: arrayref 0.3.10, internment 0.8.7 and append-only-vec 0.1.9. Each release added a single new line to the crate’s Cargo.toml, pointing to a package called proc-macro1, a typosquat of the legitimate and widely used proc-macro2. The Rust Security Response Team locked the account and pulled every malicious version within 86 to 107 minutes of publication, and confirmed the maintainer’s own credentials or machine were likely compromised rather than the crates.io platform itself.
Why compiling was the trigger, not running
Cargo executes a crate’s build.rs script automatically as part of compilation, before a single line of the crate’s actual library code is linked into anything. The malicious proc-macro1 dependency put its payload there, so any project that pulled in a poisoned version and ran cargo build downloaded and executed a detached payload without the developer writing, reviewing or running a single line of application code. That is the detail that should concern engineering leads more than the headline number: a dependency review process built around reading source code does not catch a build script that fetches its real behaviour from the network at build time.
The blast radius was set months before the attack, not on the day of it
arrayref carries 245 million all time downloads on crates.io, with roughly 53.7 million of those in the last 90 days alone, and 403 crates list it as a direct dependency, before counting everything downstream of those. append-only-vec and internment are smaller at roughly 4.5 million and 14.4 million all time downloads respectively, but both sit in dependency trees a maintainer chose without ever expecting to personally vet the account security of every package three or four levels removed from their own code. crates.io has since deleted six attacker-created packages tied to the campaign, including proc-macro1 itself, alongside the three poisoned releases.
What this means for a CI pipeline that pulls fresh dependencies
An 86 minute exposure window sounds small until it overlaps with a scheduled nightly build, a fresh cargo update, or a CI runner that does not pin exact versions in Cargo.lock and rebuilds from a floating range. Any European engineering organisation shipping Rust, particularly in fintech, automotive or infrastructure where the language’s memory safety guarantees made it the default choice, should treat this as a prompt to check whether Cargo.lock is actually committed and enforced in CI, whether build scripts run in a sandboxed or network restricted environment, and whether any build between 20 and 21 August pulled arrayref, internment or append-only-vec from an unpinned source.
If you need to confirm your build pipeline was not exposed, or want a supply chain review that covers dependency pinning, build script sandboxing and CI credential scoping across Rust, Node or Python toolchains, contact Excello Digital. We help European engineering teams close the gap between what their lockfile promises and what their build process actually trusts.