On August 20, malicious versions of three Rust crates were published to crates.io: arrayref@0.3.10, internment@0.8.7, and append-only-vec@0.1.9. All three added a typosquatted dependency named proc-macro1, whose build script downloaded and executed a remote binary.

The releases were pulled within 86 to 107 minutes. That window was enough to matter.

Why build scripts make this worse

The critical detail is where the payload lived. It was in the build script of the injected dependency, not in the crate code.

Rust’s build.rs runs at compile time, with your user’s privileges, before any of your code executes. Nothing had to call anything from arrayref. Merely resolving the dependency and running cargo build was sufficient to execute the payload.

That means the usual defensive instinct fails here. “I do not call that function” is irrelevant. “I only build in CI” is not a mitigation; it means your CI runner executed it. “I did not run the binary” misses the point entirely.

# Audit what a project would actually pull
cargo tree | grep -i proc-macro1

# Check your lockfile for the affected versions
grep -A1 -E 'name = "(arrayref|internment|append-only-vec)"' Cargo.lock

If proc-macro1 appears anywhere in your dependency graph, treat the machine that built it as compromised and rotate whatever credentials were reachable from it.

The blast radius

arrayref has roughly 245 million all-time downloads on crates.io, with about 53.7 million in the last 90 days. One analysis found it present in over 35% of environments surveyed.

It is a small utility crate for taking array references, the sort of dependency that ends up three or four levels down in a graph nobody reviews. Almost nobody who was exposed had chosen to depend on it directly.

What happened to the maintainer

The Rust Security Response Team said it does not believe the legitimate maintainer acted maliciously, and suspects the maintainer’s computer or crates.io publishing credentials were compromised.

That distinction matters for how you reason about the risk. This was not a maintainer going rogue, and it was not a hostile actor patiently building trust over years to take over a package. It was credential theft against someone who already had publishing rights, which is a far more common and far harder problem to design around.

The campaign’s infrastructure reportedly overlaps with recent DPRK-linked supply chain attacks, including operations against Mastra and axios.

The uncomfortable part

Detection worked reasonably well here. An automated scanner flagged the malicious proc-macro1 crate the same morning, and everything was yanked inside two hours.

But two hours of a package with 53 million quarterly downloads being poisoned is still a lot of builds, and the response was fast because someone was watching, not because the system prevented it. Publishing credentials are a single factor between an attacker and every downstream consumer of a package, and build scripts turn any compromised dependency into immediate code execution.

The same structural problem exists in npm, PyPI, and every other ecosystem with post-install or build-time hooks. Arch suspended AUR package adoptions after a similar incident in June for the same underlying reason: the trust is in the account, and accounts get stolen.

Nothing about this is specific to Rust. It is just Rust’s turn.