The arrayref Attack Turned Cargo's Yank Warning Into the Delivery Mechanism

A Rust crate with 245 million downloads shipped a dependency that ran malware during `cargo build`. The part worth studying is what the attacker did 24 seconds after publishing it.

Twenty-four seconds after pushing the poisoned release of arrayref, the compromised account started yanking the clean ones. Version 0.3.9 at 07:15:24 UTC. Then 0.3.8, 0.3.7, 0.3.6, and 0.3.5, each about four seconds behind the last, finished by 07:15:40. StepSecurity pulled the cadence out of the crates.io audit log, and it reads like a shell script because it was one.

Yanking does not delete anything. It does not break a single existing build. What it does is make Cargo print a warning on every subsequent run: package arrayref v0.3.9 in Cargo.lock is yanked in registry crates-io, consider updating to a version that is not yanked. The only modern release left unyanked was 0.3.10, the one carrying the malware.

That is the whole trick. The attacker did not have to compromise your machine. They had to make your tooling ask you to do it.

The interesting part is not the payload

Plenty has been written about what the payload does, and it is nasty enough. A typosquatted crate named proc-macro1 shipped a build.rs that reassembled a URL from base64 fragments, fetched a platform-specific binary over TLS with certificate validation deliberately switched off, dropped it in a temp directory, and spawned it detached. Wiz analyzed the second stage: browser credential theft from Chrome, Brave, and Edge, persistence via Registry Run key, LaunchAgent, or systemd user service, and a domain generation algorithm as C2 fallback. Wiz reports infrastructure overlap with campaigns Microsoft and Mandiant have attributed to North Korean actors, which is a strong signal and still an overlap rather than a confession.

None of that is new. Build-time droppers are a known category. What is new, and what I think most of the coverage has underweighted, is that the registry's own safety feature was the distribution channel.

Take my position plainly: a yank warning is no longer a maintenance chore. It is an unauthenticated message from whoever currently controls a publishing account, rendered by your build tool, in the voice of your build tool, telling you to change your dependency graph. Treat it accordingly.

Why the poisoned release looked fine

There is not one line of malicious code inside arrayref. The library source is untouched. The complete diff against 0.3.9 is a single added dependency in the manifest, proc-macro1 ^1.0.107.

That crate ships the genuine proc-macro2 source, so it compiles clean and every test passes. The weapon is the build script and the three build-time dependencies it needs, which the crates.io index recorded plainly: base64, rustls, and ureq. A proc-macro utility has no reason to need an HTTP client. The registry metadata gave away the capability before anyone read a line of the script.

Two more details make the setup worth studying. arrayref had not added a dependency in ten years, so the phantom dependency was, by itself, a high-confidence signal that something was wrong. And the typosquat persona was staged: a GitHub account named dtolney created at 01:17 UTC, one transposed letter from dtolnay, followed eight minutes later by a matching crates.io account, followed at 01:55 by a clean decoy release of proc-macro1 containing nothing malicious. Five hours later the same crate was weaponized. Anyone checking for a suspiciously new package would have found one with publishing history.

Cargo has no `--ignore-scripts`

npm gives you a flag to refuse install hooks. Cargo does not have an equivalent, on stable or nightly. Build scripts and procedural macros both run at compile time with the building user's full privileges, and neither surface is sandboxed.

This is not an oversight nobody noticed. Cargo issue #5720, "Sandbox/jail build scripts," has been open since July 2018, a sandboxed build script has been written up as a Rust project goal, and the internals forum has cycled through proposals for years. The reason it is still open is genuinely hard: strip filesystem access and you break cc, which has to write object files. Strip it differently and you break crates that read external grammar or schema files at build time. There is no obvious line, so there is no flag.

Which means the mitigation everyone reaches for in the JavaScript ecosystem does not exist here. Your defenses are all upstream of execution: what you resolve, when you resolve it, and what the machine can reach once the script runs.

Deletion cleaned the registry and nothing else

The clean-up created a second-order problem. crates.io deleted the malicious versions rather than yanking them, so they stopped existing in the index entirely. Registry-side lookups for those versions go quiet, and for a few hours on August 20 that included the advisory tooling, since the RustSec entries were still being written.

That gap has closed. RUSTSEC-2026-0260 was issued the same day, so a current cargo audit will flag a lockfile pinned to arrayref 0.3.10. Run it. Just do not treat a green result from an old advisory database as evidence of anything, because for the window when it mattered most, green is exactly what it printed.

Deletion also purges nothing already on disk. A warm ~/.cargo/registry cache, a committed vendor/ directory, a registry mirror, or a container layer baked with a populated cache will keep building the payload offline, long after the version stopped existing in the registry.

The exposure windows were 86, 90, and 107 minutes for the three compromised crates. That sounds survivable right up until you remember that CI runs on a schedule and does not check the news first.

Put this into practice

None of this takes an afternoon. Work down the list in order.

Check the cache, not the registry. The registry is clean now; your disk may not be. Run the check the Rust Security Response Team published in its advisory:

find ~/.cargo/registry/cache -type f \( \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Run it on developer machines and on any cached registry your CI restores.

Grep every lockfile, and know that Cargo.toml will not save you. A pin of arrayref = "0.3" matches 0.3.10 perfectly well. Only the resolved version in Cargo.lock tells you anything. Search your checkouts for the six attacker-owned crate names as well as the three poisoned versions.
Build with --locked in CI and review lockfile diffs in pull requests. A new entry named proc-macro1 in a Rust lockfile diff is impossible to miss once someone is looking. This is the single highest-value change on the list and it costs one flag.
Add a cooldown. If your organization can enforce a policy that only admits crate versions older than some number of days, this attack becomes a non-event for you. The malicious releases lived for under two hours. A three-day cooldown would have caught all three without a human making a judgment call.
Read new build-dependencies entries like they are code, because they are. A networking crate appearing under [build-dependencies] in a package with no reason to make network calls is the tell. That one heuristic would have flagged proc-macro1 from the index metadata alone.
Change how your team responds to yank warnings. The old reflex is cargo update -p <crate>. The new one is to look at what changed first. A sudden yank of several stable versions of a long-lived crate is a reason to investigate, not a chore to clear.

If you built anything during the 07:11 to 09:25 UTC window on August 20, the machine gets treated as compromised: rotate SSH keys, cloud tokens, registry tokens, signing keys, and CI secrets, and rebuild artifacts from clean sources.

Honest limitations

Cooldown policies have a real cost, and I would rather say so than pretend otherwise. They delay security patches too. A three-day window that stops a malicious release also stops you from picking up a fix for an actively exploited bug for three days. Teams that ship to regulated environments will feel that tradeoff more than most, and there is no setting that gets you both.

--locked protects applications and does very little for libraries, which do not commit lockfiles by convention. If you maintain crates, your CI is resolving fresh on most runs, and it is the population this attack was aimed at.

Egress control is the defense that actually worked here, since the dropper still had to call somewhere. It is also the one most teams do not have, and the runtime products that provide it are commercial. Blocking a list of IP addresses after the fact is not the same capability as baselining what a build is allowed to talk to.

And the honest ceiling on all of it: none of these steps stops a build script from running. They shrink what it can reach and how likely you are to resolve a poisoned version. The execution itself stays unsupervised, by design, until the Rust project solves a problem it has been circling for years.

The question the registries have to answer

Yanking exists so a maintainer can say "this version has a problem, please move on." That message and "an attacker has taken this account and wants you to move onto their version" are, at the protocol level, the same message. Cargo renders both identically. So does every registry I know of.

crates.io reversed the attacker's yanks and restored the clean releases, which is the right response and also the only one available after the fact. What is not obvious is whether a registry could distinguish the two cases in advance. Rate-limiting a burst of yanks might have bought forty seconds. Requiring a second factor for bulk yanks might have stopped it. Both add friction to a legitimate operation that maintainers already use rarely and reluctantly.

I do not think the answer is obvious, and I would rather leave it open than pretend it is. If you have seen a registry handle this well, or you had a lockfile diff catch something like this in review, tell me what it looked like.

Sources: Rust Blog: Supply chain attack on arrayref, Wiz Research, StepSecurity technical write-up, rustsec/advisory-db#3161, RUSTSEC-2026-0260, rust-lang/cargo#5720 on sandboxing build scripts.