Malicious Rust crate arrayref 0.3.10 executes remote payload during build via typosquatted dependency

The attack leveraged a compromised maintainer account to publish a malicious version of the widely used Rust crate arrayref. Version 0.3.10 introduced a dependency on proc-macro1, a crate designed to mimic the legitimate proc-macro2 but containing a build script that executes arbitrary code. This approach allowed the payload to run during compilation, making detection harder for developers who may not scrutinize build-time behavior. The malicious crate was structured to avoid immediate build failures, ensuring the payload could execute without raising suspicion.

The payload itself was delivered via a build script in proc-macro1, which reassembled a base64-encoded server address at compile time. The script fetched an architecture-specific binary over TLS, though it accepted any certificate, leaving it vulnerable to interception. On Unix systems, the binary was written to `/tmp/rust-setup`, while on Windows, it used PowerShell and VBScript launchers under `%TEMP%`. The process was detached from the build, meaning the compiler would not wait for it to complete, further obscuring its execution.

The attack spread by yanking older versions of arrayref, a tactic that leveraged Cargo’s warning system to nudge developers toward the malicious release. Since arrayref is a transitive dependency for many popular Rust crates, including those used in GUI frameworks like egui and iced, the compromised version had the potential to reach a broad audience. The crates.io team has since removed the malicious versions, but the incident underscores the fragility of dependency chains, where a single compromised crate can have cascading effects.

The use of typosquatting, registering a crate name nearly identical to a legitimate one, was a key factor in the attack’s success. The malicious proc-macro1 crate impersonated the widely used proc-macro2, complete with forged metadata attributing it to a well-known maintainer. This deception made it more likely for developers to overlook the dependency, especially in automated build environments. The incident also highlights the importance of verifying crate metadata and build scripts, even for seemingly innocuous dependencies.