Rust malware in arrayref: how a build.rs ran a payload at compile time

On August 20, 2026, Rust malware reached crates.io through one of its most-downloaded small crates. arrayref 0.3.10 added a single dependency, proc-macro1, a look-alike of the real proc-macro2, and that crate's build script downloaded and started a binary while your project compiled. The Rust security response team deleted it 86 minutes later. If you write Rust, the mechanism matters more than the crate: cargo build runs your dependencies' code on your machine, as you, by design.

TL;DR

• arrayref 0.3.10 was published from the maintainer's account at 07:15 UTC and deleted at 08:41 UTC. Per RUSTSEC-2026-0260 it was downloaded 2,285 times, under 10 % of arrayref's traffic in that window, because most lockfiles still held 0.3.9.
• The payload lived in proc-macro1, published by an account called dtolney, one letter from David Tolnay (dtolnay), who maintains the real proc-macro2. Its library code was a genuine copy of proc-macro2, so builds kept working.
• The attacker yanked every clean arrayref version, so Cargo's own "consider updating to a version that is not yanked" warning pointed people at the poisoned one.
• Two more crates from the same account, internment and append-only-vec, got the same treatment. The Rust blog says the author was likely compromised; it treats them as a victim.
• My verdict on the response: NEEDS REVIEW. The deletion was fast; the crate page, cargo audit and the build-script model tell you almost nothing afterwards.

What happened to arrayref: the timeline

arrayref is a tiny crate: four macros for taking fixed-size array references out of slices. It has about a quarter of a billion downloads and 400 reverse dependencies on crates.io, which is exactly why it was worth taking over.

All times UTC, August 20, 2026:

Six attacker crates were deleted in all: proc-macro1, proc-macro-en, aovine, arone, aronenao and tinymember. The same day SafeDep published the teardown, which reached 554 points on Hacker News.

How a Cargo build script runs code on your machine

A build.rs is an ordinary Rust program. Cargo compiles it and runs it on the developer's machine, with the developer's permissions, before the crate itself is built. It exists for good reasons: finding and compiling C libraries, generating bindings, embedding version info. There is no sandbox. Proc macros are the same story inside rustc. That is the design, working as intended.

Here is the second half of the trick. SafeDep's diff shows arrayref 0.3.10's manifest gained exactly one entry:

Nothing in arrayref's source uses proc-macro1. As SafeDep puts it: "Cargo builds every declared non-optional dependency, whether or not the code uses it." One line in someone else's manifest is enough to get a build script executed on your laptop and in your CI. version = "1.0.107" is a caret requirement, and only 1.0.106 and 1.0.107 existed, so it resolved to the malicious one.

To make the point without any malware in it, this is a complete, legal build script. It is a simplified sketch, not from the incident:

// build.rs (illustrative example): Cargo runs this before compiling the crate
fn main() {
    // anything here runs as you: read files, open sockets, spawn processes
    println!("cargo:rerun-if-changed=build.rs");
}

Everything the attacker needed fits in that main.

The yank lure: why Cargo pointed people at the poisoned version

The attacker published 0.3.10 and then went further: they yanked 0.3.5 through 0.3.9. A yanked version stays downloadable for existing lockfiles, but Cargo warns about it and suggests you move: "consider updating to a version that is not yanked". The only version not yanked was 0.3.10.

jhobern, who filed the RustSec issue, wrote: "0.3.5–0.3.9 are all yanked under the owner account, so cargo's consider updating to a version that is not yanked warning is the lure. That is how I hit it."

That is the part I find most instructive. The tool's safety feature became the delivery mechanism. A yank warning is normally a maintainer telling you something is wrong with a version. Here it was an attacker telling you to install theirs.

proc-macro1 vs proc-macro2: an off-by-one typosquat

proc-macro2 is the crate almost every Rust macro depends on, maintained by David Tolnay. The fake was one digit off, published by dtolney, one letter off. Per SafeDep, the manifest forged authors = ["David Tolnay <…>"] and a repository URL under dtolnay that returns 404.

Two details made it quiet:

• The library was real. The src/ of proc-macro1 was a genuine copy of proc-macro2, down to copied issue references, so anything that used it compiled and worked.
• The build dependencies were not. Version 1.0.107 added base64, rustls and ureq as build dependencies. The real proc-macro2 has none of them. A token-stream library has no reason to speak TLS at build time, which is the kind of thing only a reviewer reading the dependency tree would catch.

What the build.rs payload did

I'm describing this from SafeDep's analysis and the RustSec thread, without addresses or code you could run.

• The build script reassembled a server address from base64 fragments, then used a TLS client configured to accept any certificate, so it would talk to the attacker's server no matter what.
• It picked an OS-specific binary for Linux x86_64, Windows x86_64 and macOS (Intel and Apple Silicon), and panicked on anything else.
• On Unix it wrote the binary to /tmp/rust-setup, made it executable and started it detached, with no output, without waiting for it. The build then finished normally.
• On Windows it went through wscript.exe. A comment in the source explains why: "ShellExecute via WScript escapes Cargo's job object; spawned children otherwise keep the build script (and cargo build) waiting until they exit."

The second stage is less certain. An analysis posted on the RustSec thread (its author says it was LLM-assisted, with human review) describes a remote-access tool and stealer aimed at web browsers and crypto-wallet extensions. One commenter on Linux reported new folders under ~/.config and an executable called MonoService, registered as a systemd service so it restarts. Treat the second stage as reported and still unconfirmed.

The irony writes itself when you look at who depends on arrayref:

After tiny-skia, which puts arrayref under winit and most Rust GUI work, the heavy users are libsecp256k1, schnorrkel, spl-token and solana-runtime: cryptocurrency code. The reported payload went after crypto wallets.

Blast radius of the Rust supply chain attack

• 2,285 downloads of 0.3.10 in 86 minutes, per the RustSec advisory, "less than 10% of arrayref download traffic across all versions, as most users had older versions of arrayref in their lockfiles." Committed lockfiles did their job.
• 3 hijacked crates and 6 attacker crates, plus a second poisoned arrayref version published during the response.
• crates.io said there was "no evidence of actual usage". At least two people on the RustSec thread said it ran on their machines.
• The advisory says unaffected = ["<= 0.3.9"] and patched = []: there is no fixed version because the fix was deleting the bad one.

One gap shows up in the thread: once the issue was closed, a commenter pointed out that "cargo audit produces no signal for this incident" for anyone with the .crate file already in their local cache.

Why the version disappeared from crates.io

The top thread on Hacker News was not about the malware. It was about the crate page, where 0.3.10 "has also just disappeared from crates.io with no indication its been yanked". Manish Goregaokar of the Rust security response team replied: "We take a snapshot copy of the crate and then purge it from the system… Any way of keeping it around on the server in a way that is fetchable by cargo is a complete non-starter."

Both are right. Keeping malware fetchable is not an option. But a version page with no trace of the incident means the next person checking their dependency history sees nothing happened. crates.io described its malicious-crate process in February; this incident is a good test of what a tombstone should look like.

git blame: who is at fault

My split, as in the episode:

The maintainer gets no share of intent. The Rust blog: "We do not believe the author of arrayref to be acting maliciously". I found no public statement from them since.

How to check if you pulled arrayref 0.3.10

The Rust blog gives the command to search your local Cargo cache. Verbatim:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.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

No output is what you want. Run it on CI runners with persistent caches too. If something prints, treat the machine as compromised: the build script ran with your permissions, so rotate what that user could read, starting with SSH keys and your crates.io token.

Longer term, the lessons are boring and that is the point:

• Commit Cargo.lock, for binaries at least. It is why only a small share of traffic got 0.3.10.
• Treat a yank warning as a question, not an instruction. Look at what changed in the version it suggests before you move.
• Read new build dependencies. A new build.rs plus a network or TLS crate in a library that parses tokens is a red flag you can spot in a diff of Cargo.lock.

Verdict: NEEDS REVIEW

I stamped the response NEEDS REVIEW. Deleting three hijacked crates within 86 to 107 minutes, a same-day blog post with exact timestamps, a locked account and the clean versions restored: that part is SHIP IT. But afterwards the crate page shows nothing happened, cargo audit stays silent on a cached copy, and every build script still runs unsandboxed as the developer. The next attacker only needs one credential and one line of TOML.

FAQ

Was arrayref malware?
Version 0.3.10 was, through its new dependency proc-macro1. Versions up to 0.3.9 are clean, and the Rust blog says the maintainer's account was likely compromised.

What does a Cargo build script (build.rs) do?
It is a Rust program Cargo compiles and runs before building a crate, usually to find C libraries or generate code. It runs as you, with no sandbox.

How do I know if I downloaded the malicious arrayref?
Run the Rust blog's find ~/.cargo/registry/cache command above. cargo audit may not flag a copy already in your cache.

How many people downloaded arrayref 0.3.10?
2,285 downloads in the 86 minutes it was online, per RUSTSEC-2026-0260.

Sources

• Rust Blog, "Supply chain attack on arrayref" (Aug 20, 2026): https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/
• RustSec advisory RUSTSEC-2026-0260: https://github.com/rustsec/advisory-db/blob/main/crates/arrayref/RUSTSEC-2026-0260.md
• RustSec advisory PR #3162: https://github.com/rustsec/advisory-db/pull/3162
• RustSec issue #3161: https://github.com/rustsec/advisory-db/issues/3161
• SafeDep, "Malicious Rust Crate arrayref Runs a Build-Time Payload": https://safedep.io/arrayref-proc-macro1-rust-build-time-malware/
• arrayref issue #33: https://github.com/droundy/arrayref/issues/33
• crates.io API, arrayref: https://crates.io/api/v1/crates/arrayref
• Hacker News discussion: https://news.ycombinator.com/item?id=49374269
• BleepingComputer: https://www.bleepingcomputer.com/news/security/hackers-poison-arrayref-rust-crate-to-push-infostealer-malware/
• StepSecurity: https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack
• crates.io malicious-crate process update (Feb 13, 2026): https://blog.rust-lang.org/2026/02/13/crates.io-malicious-crate-update/

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.