Rust arrayref Attack: Cargo Build Executes Malware Today

A supply chain attack hit the Rust ecosystem this morning. Between 07:15 and 08:41 UTC on August 20, 2026, a compromised version of the widely used arrayref crate (v0.3.10) executed malware on any machine that ran cargo build with the library in its dependency tree. The attack window lasted 86 minutes. The Rust Security Response Team yanked all malicious versions — but any developer who compiled during that window should assume their build machine is fully compromised.

Compiling Was Enough: How the Rust Supply Chain Attack Worked

Most supply chain attacks target install time (npm’s postinstall hooks) or runtime. This one fired at compile time, using Cargo’s build.rs mechanism. The compromised arrayref 0.3.10 pulled in a typosquatted crate called proc-macro1 — a near-identical copy of the legitimate proc-macro2, with one addition: a build script that downloaded and executed a platform-specific binary from a remote server. As StepSecurity’s analysis put it: “any machine that compiles a project resolving the dependency — without ever calling the crate — downloads a platform-specific stage-2 binary from a Hostwinds VPS and executes it, detached from the Cargo build.”

The attacker also used a clever social engineering move. Within the same minute as publishing the malicious 0.3.10, versions 0.3.5 through 0.3.9 were yanked. Cargo warns developers when their lockfile pins a yanked version and nudges them to run cargo update — which would pull in the compromised release. The system designed to keep developers on fresh, supported versions was weaponized against them.

Related: npm keyv Supply Chain Attack: 127M Downloads Hit via ESLint — the previous major package registry attack, 16 days ago.

The Blast Radius: egui, iced, blake3, and the Solana Ecosystem

arrayref has approximately 245 million all-time downloads and sits deep in Rust’s GUI and cryptography stacks. StepSecurity traced the transitive dependency path: arrayref feeds into tiny-skia, which feeds into sctk-adwaita, which feeds into winit — the windowing library at the base of egui, eframe, and iced. The crate also sits under blake3, blake2b_simd, and through them into Ethereum’s revm-precompile and Solana’s solana-runtime. Any project using these frameworks that freshly resolved dependencies during the 86-minute window was exposed.

However, not every Rust developer is at risk. If your Cargo.lock was committed before 07:15 UTC today and you ran builds with --locked, the pinned dependencies protect you. The highest-risk scenario is CI pipelines that don’t commit a lockfile and resolve fresh on every run — many teams discovered this gap the hard way today.

Are You Affected? How to Check Your Cargo.lock Now

Detection takes seconds. Run this against your lockfile:

grep -rn 'arrayref.*0\.3\.10\|proc-macro1\|internment.*0\.8\.7\|append-only-vec.*0\.1\.9' Cargo.lock

Any match means your build executed the payload. On Linux, also check for dropper artifacts: /tmp/rust-setup, ~/.config/AzureKits, and ~/.config/ServiceKit. On Windows, look for rust-setup.ps1 and rust-setup-launch.vbs in your temp directory. SafeDep’s full IOC list includes SHA256 hashes for the compromised crate archives. The stage-2 binary ran with full user privileges, established a persistent systemd service (Linux) or a detached VBScript process (Windows), and connected to C2 infrastructure at 23.254.167.216.

If you find any of these artifacts, treat the machine as fully owned. Rotate everything: SSH keys, cloud credentials, API tokens, crates.io publishing tokens, CI secrets, and GPG signing keys. Clear your cargo cache with find ~/.cargo/registry/cache -name 'arrayref-0.3.10.crate' -delete and rebuild any release artifacts produced during the window on clean infrastructure before shipping them.

The Underlying Problem: Cargo Build Scripts Have No Sandbox

Cargo’s build.rs mechanism runs arbitrary code with full system access during compilation — no network restrictions, no file system isolation. This is a known, unresolved vulnerability in Rust’s supply chain model. The Rust project already has sandboxed build scripts on its roadmap, a feature that would restrict build.rs from making network calls by default, with opt-in for crates that legitimately need it. Today’s attack will accelerate that timeline.

Meanwhile, crates.io lacks the protections that npm and PyPI have been adding: release cooldowns, minimum-age requirements before a version can be indexed, and mandatory 2FA for publishers. The droundy account — a legitimate maintainer in good standing since 2009 — was apparently compromised. Until the ecosystem hardens both the publishing pipeline and the build-time execution surface, foundational crates with enormous reach will remain high-value targets.

Key Takeaways

• If you ran cargo build or cargo update between 07:15 and 08:41 UTC today (August 20, 2026), check your lockfile immediately using the grep command above
• The attack required no function calls — the Rust supply chain attack executed malware at compile time via Cargo’s build script system
• If you find IOC files on your machine, assume full compromise: rotate all credentials and rebuild release artifacts on clean infrastructure
• CI pipelines without committed Cargo.lock files are highest risk — always pin dependencies and use cargo build --locked in CI
• Sandboxed build scripts are on Rust’s roadmap but not yet shipped — today makes the case for accelerating that work