A Compromised Rust Crate Turned a Rust Project's Build Step Into Remote Code Execution

When you run cargo build, you are running someone else's code. On August 20, a compromised release of the Rust crate arrayref turned that trust into remote code execution for anyone who updated before crates.io pulled the bad version.

arrayref 0.3.10 added a first-ever dependency on proc-macro1, a typosquat of proc-macro2, the well-known crate the Rust ecosystem actually uses. The typosquat came from an account called dtolney, one letter off from the real dtolnay handle used by maintainer David Tolnay, and its metadata forged an author tag pointing at a repository that returns 404, per the rustsec advisory. The original arrayref publisher, droundy, also appears compromised.

The payload lives in proc-macro1 1.0.107's build.rs. It stores the server address as base64 fragments, reassembles them at build time, and uses a TLS connection with no certificate validation to fetch and run an architecture-specific binary on the build host. The src/ is a working copy of proc-macro2, so builds succeeded while the payload ran. Decoded fragments point at host 23[.]254[.]165[.]112:9089 with a command-and-control address on the same IP.

arrayref 0.3.9 has roughly 152 million downloads, and the advisory's transitive walk puts the bad versions in scope of most Rust GUI work, including egui, eframe, and iced, via tiny-skia and sctk-adwaita into winit. The crates.io team removed arrayref 0.3.10, proc-macro1 1.0.107, internment 0.8.7, and other crates tied to it; earlier arrayref releases had already been yanked, so cargo's "consider updating" warning was the lure.

What to check: audit Cargo.lock for arrayref 0.3.10 or any proc-macro1 entry, pin arrayref to 0.3.9 or below, remove proc-macro1, and rebuild any machine that resolved the affected versions before the yank. The official Rust team blog post covers the incident.