Rust crates attack: cargo build ran the malware
Three popular Rust crates shipped a malicious build script on August 20 and were pulled within two hours. Compiling was enough to run it. What that means for your dependency pipeline.
On August 20, three widely used Rust crates published new versions carrying a malicious build script. You did not have to call a function to get hit. Running cargo build was enough. The versions were live for 86 to 107 minutes before crates.io deleted them — a window shorter than most teams' code review cycle, and long enough to matter. This is the clearest example yet of why "we pin our dependencies" and "we read the changelog" are not the same control.
What actually happened
Per the Rust Security Response WG's writeup, the attacker published proc-macro1 — a typosquat of the ubiquitous proc-macro2 — carrying a build script that downloaded a payload. Then, using what appears to be a compromised maintainer account, they published three new releases that each added proc-macro1 as a direct dependency:
| Crate | Version | Published (UTC) | Deleted (UTC) | Live |
|---|---|---|---|---|
| arrayref | 0.3.10 | 07:15:00 | 08:41:40 | 86 min |
| internment | 0.8.7 | 07:34:07 | 09:04:11 | 90 min |
| append-only-vec | 0.1.9 | 07:37:49 | 09:25:24 | 107 min |
The mechanism is the point. Cargo executes build.rs at compile time. cargo build, cargo check, and cargo test all trigger it. No import, no function call, no runtime — the code ran the moment the toolchain touched the crate.
Scale needs care here, because the headline number and the exposure number are different. arrayref has roughly 245.7 million lifetime downloads and about 54 million in the last 90 days, per the crates.io API. The malicious 0.3.10 got 2,285 downloads in its 86 minutes, per RUSTSEC-2026-0260. Those 2,285 pulls landed on developer laptops and CI runners belonging to a dependency that is three levels down in half the Rust ecosystem.
Nextron Systems reported the malicious proc-macro1 crate. The Rust team locked the affected account and stated plainly: "We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised." The Hacker News, citing Wiz analysis, describes a second-stage implant that pulled browser credentials from Chrome, Brave, and Edge across Windows, macOS, and Linux.
Why a two-hour supply chain window matters for your business
The defense everyone assumes they have is human review. That defense does not fit in 86 minutes. Neither does a weekly dependency audit, a Friday patch meeting, or a CVE feed — the advisory was written after the packages were already gone.
What works is mechanical, and none of it is Rust-specific. npm postinstall, Python setup.py, Gradle plugins — every ecosystem lets a package execute code at install or build time, and every one of them has shipped this exact attack.
Commit your lockfile and build with --locked. A committed Cargo.lock plus cargo build --locked in CI means a fresh upstream version cannot enter your build because someone ran an update at the wrong hour. Same idea as npm ci over npm install.
Put a delay between publish and adoption. A cooldown of even three days on automated dependency updates would have made this entire event a non-issue for you. The malicious versions did not survive two hours.
Treat CI runners as compromised-by-default. Ephemeral runners, no long-lived cloud credentials in the build environment, and OIDC-issued short-lived tokens instead of static keys. If a build script does run, it should find nothing worth stealing.
Check the local cache. If you build Rust, look in ~/.cargo/registry/cache for those exact versions. Deleted from crates.io does not mean deleted from the machine that already downloaded it.
Key takeaways
- Malicious versions of arrayref, internment, and append-only-vec each added a typosquatted
proc-macro1dependency whose build script ran at compile time cargo build,cargo check, andcargo testall executebuild.rs— no code needs to import the crate for the payload to run- The versions were live 86–107 minutes; arrayref 0.3.10 was downloaded 2,285 times before deletion
- The Rust team believes the maintainer's machine or credentials were compromised, not that the author acted maliciously
- Commit lockfiles and build with
--locked, add a cooldown before adopting new versions, keep CI runners ephemeral and credential-free, and audit~/.cargo/registry/cache
Does your CI pipeline pull the newest version or the version you approved? We build release pipelines with pinned lockfiles, update cooldowns, and short-lived credentials, so a two-hour attack window closes before it reaches you. See how we set up build pipelines, or send us your CI config.
Sources: Rust Blog, RUSTSEC-2026-0260, crates.io, The Hacker News.
- #security
- #rust
- #supply-chain
- #ci-cd
- #dependencies
Tommy Rush — Founder, Rush Commerce
Operator turned builder. 15+ years running operations — now shipping the systems businesses run on. More
Get The Rush Report weekly — one email, zero fluff.
Keep reading
Entra ID CVE-2026-69836: a CVSS 10 you can't patch
Microsoft published a CVSS 10.0 unauthenticated RCE in Entra ID marked Exploited: Yes, already fixed server-side. There is no update to install — here's what you can actually do.
Read itMLflow CVE-2026-64849: your ML server hands out cloud keys
An unauthenticated SSRF in MLflow under 3.15.0 is being exploited to steal cloud credentials. CISA added it to KEV on August 19. Patch or take it off the internet.
Read it