Skip to content
Tech News
← Back to articles

Malicious Rust crate Arrayref runs a build-time payload

read original more articles
Why This Matters

The recent compromise of the Rust crate arrayref highlights the increasing risks of supply chain attacks in software development. By injecting malicious code through typosquatted and compromised crates, attackers can execute malicious payloads during build processes, posing significant security threats to developers and consumers. This incident underscores the importance of vigilant dependency management and supply chain security in the tech industry.

Key Takeaways

Summary

On August 20, 2026, a compromised release of the popular Rust crate arrayref appeared on crates.io. Version 0.3.10 added a dependency on a typosquatted crate called proc-macro1 , whose build script downloads and runs a remote binary while a project compiles. The code runs at build time, so simply compiling a project that pulled the bad versions is enough to trigger it. The crates.io team has since removed the malicious versions.

Packages involved

The genuine arrayref and append-only-vec crates are maintained by droundy , whose account appears to have been compromised. The corresponding GitHub repositories are no longer available. github.com/droundy/arrayref , github.com/droundy/append-only-vec , and the entire github.com/droundy account all return 404, so the upstream code is no longer available for inspection. A separate account, dtolney , published proc-macro1 . The username closely resembles David Tolnay’s real dtolnay account. Its metadata forges authors = ["David Tolnay <[email protected]>"] and points repository at a dtolnay/proc-macro1 path that returns 404.

Crate Version Publisher Status arrayref 0.3.10 droundy (compromised) Malicious, removed internment 0.8.7 droundy (compromised) Malicious, removed append-only-vec 0.1.9 droundy (compromised) Malicious, removed proc-macro1 all versions dtolney (impersonation) Malicious typosquat, entire crate removed proc-macro-en all versions Malicious dependency crate, removed aovine all versions Malicious dependency crate, removed arone all versions Malicious dependency crate, removed aronenao all versions Malicious dependency crate, removed tinymember all versions Malicious dependency crate, removed

Note that proc-macro1 is not proc-macro2 . The real crate that macro authors depend on is proc-macro2 . The src/ of the malicious proc-macro1 is a genuine copy of proc-macro2 , so builds kept working while the build script ran.

What the build script does

The payload lives in the build script of proc-macro1 1.0.107. It stores its server address as base64 fragments and reassembles them at build time, quoted in the advisory:

1 // proc-macro1-1.0.107/build.rs (quoted in rustsec/advisory-db#3161) 2 const SRC_URL_PARTS : & [ & str ] = 3 & [ "aHR0cHM6Ly8=" , "MjMuMjU0Lg==" , "MTY1Lg==" , "MTEyOg==" , "OTA4OS8=" ]; 4 const END_URL_PARTS : & [ & str ] = 5 & [ "MjMuMjU0Lg==" , "MTY1Lg==" , "MTEyOg==" , "NDQz" ];

Decoded, those fragments produce the payload host hxxps://23[.]254[.]165[.]112:9089/ and the command and control address 23[.]254[.]165[.]112:443 . The script fetches an architecture-specific binary over a TLS connection that accepts any certificate without validation, then runs it detached from the build. On Unix it drops and runs /tmp/rust-setup . On Windows it writes a PowerShell script and a VBScript launcher under %TEMP% and starts them hidden, then abandons the child process so the compiler does not wait for it.

... continue reading