SECURITY Signal 582 2 feeds carried it
Malicious proc-macro1 crate and typosquats infect Rust arrayref 0.3.10 via supply-chain attack
Rust Security Response Team removed malicious crates including proc-macro1 and yanked versions of arrayref 0.3.10 after discovering a build script downloading payloads
This attack demonstrates how a single compromised dependency can propagate malicious code across widely used Rust crates. Engineers must verify their dependency trees to prevent latent infections. The incident highlights the fragility of supply-chain security even in curated ecosystems like crates.io
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Malicious proc-macro1 crate executed payload downloads via build scripts and was deleted from crates.io
arrayref 0.3.10 and other crates were republished to depend on proc-macro1 before being yanked and restored
Rust Security Response Team recommends checking local caches for specific malicious crate versions
THE READ
What the cluster adds up to.
The attack exploited Rust's build script mechanism to download and execute malicious payloads. Build scripts run automatically during compilation, giving attackers a reliable execution vector. This method bypasses static analysis and requires runtime inspection to detect. The payload's exact behavior remains unspecified, but build scripts can modify compilation or inject code into the final binary. Engineers should audit build scripts in dependencies, especially those from new or unverified maintainers.
The typosquatting component targeted crates with names similar to legitimate ones like proc-macro. Attackers published proc-macro1, proc-macro-en, and other variants to catch misspelled dependencies. The arrayref crate, a popular utility, was republished to depend on proc-macro1, amplifying the attack's reach. This technique relies on human error during dependency specification. Rust's cargo-deny tool can help detect typosquats by comparing dependency names against known legitimate crates.
The incident response involved yanking malicious versions and restoring previously yanked legitimate ones. This process required manual intervention from the Rust Security Response Team, creating a window where projects could unknowingly pull malicious code. The team also locked the affected maintainer's account, suggesting credential compromise. Engineers should monitor dependency updates and prefer pinned versions in production to reduce exposure to such attacks.
Detection relied on external reporting rather than automated crates.io scanning. The Rust team credited Nextron Systems for discovering the attack, indicating that current registry monitoring lacks comprehensive malicious behavior detection. This gap leaves the ecosystem vulnerable to similar attacks until better automated analysis is implemented. Projects should implement their own dependency scanning as an additional layer of protection, particularly for build scripts and transitive dependencies.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER
↗