The arrayref Rust Supply Chain Attack: A Typosquat, a Yank Trick, and a 6-Minute Fuse

The malicious code in the arrayref supply chain attack ran before a single line of the compromised crate’s own logic did. That’s the part worth sitting with. On August 20, 2026, an attacker used a hijacked crates.io account to publish poisoned versions of three widely used Rust crates, wired a build script to fetch and execute a remote payload the instant cargo build touched them, and then tried to social-engineer developers into upgrading by yanking every safe alternative out from under them. The Rust Security Response Team shut it down in about two hours. Here’s exactly how it worked.

The attack, step by step

The target was arrayref, a small, extremely widely depended-on crate used across the Rust ecosystem for slicing arrays into fixed-size references. At 07:15 UTC, the attacker, operating through a compromised maintainer account, published arrayref version 0.3.10. The new version added a dependency that hadn’t been there before: proc-macro1, a typosquatted crate designed to look like a plausible internal helper rather than anything a careful reviewer would flag on sight.

proc-macro1’s build script is where the actual payload lived. Cargo runs a crate’s build.rs script during compilation, before the crate’s own code is even compiled, which means the moment a project pulled in the poisoned arrayref and ran cargo build, that build script executed and downloaded a remote binary onto the machine. Whatever ran next, credential theft, further payload staging, is the part every build-time supply chain attack in 2026 has converged on, because it works: build-time execution reaches CI runners and developer machines equally, with none of the “did the user actually run the compromised code path” uncertainty that runtime-only payloads carry.

07:15 UTC  arrayref 0.3.10 published, depends on proc-macro1 (typosquat)
07:15 UTC  attacker yanks every other recent arrayref version, ~4s apart
   ...     any project running cargo build against 0.3.10 executes
           proc-macro1's build.rs, which fetches and runs a remote payload
08:41 UTC  arrayref 0.3.10 removed, ~86 minutes after publish
09:15-09:26 UTC  clean pre-attack versions of all three crates restored

The yank trick is the clever part

What separates this from a routine “attacker publishes a bad version” incident is what happened in the same minute as the malicious publish. The attacker scripted a rapid-fire sequence of yank commands against every other recent version of arrayref, spaced roughly four seconds apart. Yanking a crate version on crates.io doesn’t delete it or make it unavailable to projects that already depend on it, but it does make Cargo print a warning telling anyone who resolves that version to update to one that isn’t yanked.

With every legitimate recent release yanked in one automated burst, that warning pointed developers at exactly one option: 0.3.10, the only unyanked version left, which was the malicious one. It’s a small manipulation of a mechanism built for a completely different purpose, using Cargo’s own “please upgrade” nudge as the delivery vector instead of a phishing email or a fake update prompt. The same logic showed up in the keyv npm worm from earlier this month: once an attacker has legitimate publishing access, the registry’s own trust signals become the attack surface, not a defense against it.

Two other crates from the same maintainer account, internment and append-only-vec, got the same treatment: malicious versions 0.8.7 and 0.1.9 respectively, published from the same compromised identity.

Why it stayed small

This attack’s blast radius is a genuinely good outcome, and it’s worth understanding why. Researchers at Nextron Systems caught the payload and flagged it to the Rust Security Response Team, which verified the threat and pulled the malicious releases within roughly two hours of the first publish. arrayref 0.3.10 itself was live for about 86 minutes before it came down. The team then went further than just removing the bad versions: it restored the clean, pre-attack releases across all three crates between 09:15 and 09:26 UTC that same morning, undoing the yank-burst that had tried to strand developers on the malicious release.

Compare that response window to the keyv npm compromise, where automated scanning caught the first poisoned package in about six minutes but the worm-style spread through stolen tokens still reached hundreds of downstream packages before it was fully contained. The arrayref attack didn’t have that worm mechanic. It was contained to three crates from one compromised account, with no evidence of credential harvesting spreading the compromise further, which is as much a function of how the attack was built as how fast it was caught.

What to actually check

If you maintain a Rust codebase with a dependency tree of any real size, do this now rather than assuming you’re unaffected:

1. Check your Cargo.lock for arrayref, internment, or append-only-vec pinned to versions published on August 20, 2026 (0.3.10, 0.8.7, and 0.1.9 respectively). grep your lockfile or use cargo tree to confirm what’s actually resolved, not just what your Cargo.toml allows.
2. If any build ran against a poisoned version, treat that machine as compromised. Rotate credentials that were present in the environment (cargo registry tokens, cloud credentials, SSH keys) rather than assuming the payload didn’t reach them.
3. Pull the latest clean release for all three crates, published after the 09:15-09:26 UTC restoration window, and re-lock.
4. Audit CI logs for builds that ran between 07:15 and 08:41 UTC on August 20, 2026 if your pipeline auto-updates dependencies on a schedule that could have picked up the poisoned versions during that window.

If you want the longer answer on tooling that catches this class of attack before it reaches a build, we wrote a separate, practical walkthrough of cargo-audit, cargo-vet, and what each one actually protects against.

A typosquatted build dependency and a scripted yank burst are a small amount of mechanism for a fairly effective social-engineering attack on a registry’s own tooling. If your team’s dependency update process still treats “Cargo told me to upgrade” as sufficient justification without checking what actually changed in the new version, an infrastructure review that adds pinned, reviewed dependency updates to your build pipeline is worth doing before the next compromised account finds your lockfile.