arrayref Rust supply chain attack drops build-time malware

A Rust supply chain attack compromised the maintainer account behind arrayref on August 20, 2026, pushing a version that ran malware on every machine that compiled it. The malicious arrayref 0.3.10 stayed live on crates.io for 86 minutes. If you pulled dependencies during that window, your build machine may be exfiltrating browser credentials right now.

The attack is a textbook account takeover. The Rust Security Response Team confirmed the incident and removed the malicious versions within hours, but the exposure window was wide enough to matter. Three popular crates were poisoned in a coordinated push: arrayref, internment, and append-only-vec, all maintained by the same account.

How did the attacker take over a trusted Rust crate?

The attacker started at 01:17 UTC on August 20 by creating a GitHub account impersonating David Tolnay, one of the most prominent Rust developers. The username dtolney closely resembles Tolnay's real dtolnay account, and the crate metadata forged his email address. At 01:55, they published proc-macro1 version 1.0.106, a benign copy of the legitimate proc-macro2 crate with a mechanical find-and-replace. At 07:11, they published version 1.0.107 with the malicious build script.

At 07:15, the attacker used the compromised droundy account of David Roundy to publish arrayref 0.3.10. This version added a single line to Cargo.toml: a dependency on proc-macro1 version 1.0.107. The rest of the arrayref source code was unchanged. As the same analysis from SafeDep explains, Cargo builds every declared dependency whether or not the code uses it, so that manifest entry alone was enough to trigger the payload.

The attacker also yanked arrayref versions 0.3.5 through 0.3.9, making Cargo print a warning that nudged developers toward the only non-yanked release: the malicious 0.3.10. The reporter who filed the RustSec advisory hit the malicious version through exactly this yanking trick. Two more crates from the same maintainer, append-only-vec 0.1.9 and internment 0.8.7, got the same treatment within 23 minutes.

What does the malware do to your build machine?

The malicious code lives in the build script of proc-macro1 1.0.107. When Cargo compiles any project depending on the compromised arrayref, that build script runs. It reassembles a server address from base64 fragments, fetches an architecture-specific binary over TLS, and executes it detached from the build process.

The C2 address is 23.254.165.112 on ports 9089 and 443. The TLS connection accepts any certificate without validation. On Unix, the script writes the payload to /tmp/rust-setup, marks it executable, and spawns it without waiting. On Windows, it writes a PowerShell script to %TEMP%\rust-setup.ps1 and launches it through a hidden VBScript launcher. SafeDep's technical analysis notes that routing through WScript is what escapes Cargo's job object, so the process survives after the build finishes. The second-stage payload uses names like rust-crate_0.1.0 or _0.2.0 depending on the operating system and architecture, so scan for those patterns if you are hunting on endpoint systems.

Once running, the second-stage payload behaves like a credential stealer. According to BleepingComputer's reporting on the Wiz analysis, it queries SQLite login databases in Google Chrome, Brave, and Edge to extract saved credentials. Persistence is established via Registry Run key on Windows, LaunchAgent on macOS, and systemd on Linux. Wiz researchers also noted that the campaign's infrastructure overlaps with recent North Korean supply chain attacks, including the Mastra npm campaign.

The SHA256 hash of the malicious arrayref 0.3.10 crate is 25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae, and the malicious proc-macro1 1.0.107 has hash 61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4. If you have either crate cached, verify the hash before assuming anything.

For a deeper look at how the build script mechanics work, see our earlier technical breakdown of this attack.

How wide is the blast radius?

The chart above shows the lifetime download counts of the affected crates. arrayref has accumulated 245 million downloads, making it one of the most widely used transitive dependencies in the Rust ecosystem. It sits deep in dependency trees through tiny-skia, sctk-adwaita, and winit, which places it under most GUI work built on egui, eframe, and iced. Projects using arrayref include blake3, components used in Ethereum and Solana, and a long tail of cryptography and blockchain tooling.

The clean arrayref 0.3.9 release alone accounts for roughly 152 million of those downloads. The gap between 152 million and 245 million tells you how much of the install base was on older, safe versions. The risk concentrates in builds that updated during the attack window.

The combined downloads of append-only-vec and internment reach 19 million. Those numbers measure how widely the crates are used, not how many builds actually pulled the malicious versions. The malicious arrayref 0.3.10 was online for 86 minutes, internment 0.8.7 for 90 minutes, and append-only-vec 0.1.9 for 107 minutes.

The key question is whether your CI pipeline or any developer workstation fetched these versions during those windows. If you ran cargo update or built without a committed Cargo.lock between 07:15 and 09:25 UTC on August 20, check now.

What should you check right now?

The Rust Security Response Team published a command to scan your local Cargo cache for the malicious artifacts:

find ~/.cargo/registry/cache -type f \( \
-name 'append-only-vec-0.1.9.crate' -o \
-name 'arrayref-0.3.10.crate' -o \
-name 'internment-0.8.7.crate' -o \
-name 'proc-macro1-*.crate' -o \
-name 'proc-macro-en-*.crate' -o \
-name 'aovine-*.crate' -o \
-name 'arone-*.crate' -o \
-name 'aronenao-*.crate' -o \
-name 'tinymember-*.crate' \
\) -print

If that returns anything, assume compromise. Here is the response sequence:

• Search your Cargo.lock files for the affected versions. If you find arrayref 0.3.10, internment 0.8.7, or append-only-vec 0.1.9, those builds ran the malicious proc-macro1 build script.
• Check for the dropped files: /tmp/rust-setup on Unix, %TEMP%\rust-setup.ps1 and %TEMP%\rust-setup-launch.vbs on Windows.
• Review network logs for traffic to 23.254.165.112 on ports 9089 or 443.
• If you confirm compromise, rotate every credential accessible from the affected machine: browser passwords, CI tokens, signing keys, cloud credentials, and any secrets in environment variables or config files.
• Rebuild the environment from a known-safe backup or fresh image. Cleaning the malware is insufficient; you cannot know what else the attacker exfiltrated or staged.

For clean projects, pin a known-safe version. Update your Cargo.toml to depend on arrayref 0.3.9 and commit your Cargo.lock if you have not already. Run cargo audit and cargo deny in CI against the RustSec Advisory Database to catch known-malicious versions before they reach a build. A case study from Safeguard recommends diffing dependency updates, especially changes to build.rs, since a version bump that suddenly adds network calls or binary downloads at build time is the strongest signal of a compromised crate. Consider restricting build-time network egress in your CI so a malicious build.rs has nowhere to phone home.

This incident also reinforces lessons from previous supply chain attacks on AI build rooms: your attack surface is your dependency graph. A single compromised maintainer account in a popular transitive dependency can reach thousands of downstream projects.

The line between a typo and a breach

The proc-macro1 typosquat worked because it was close enough to proc-macro2 to pass a glance and because the build succeeded. The malicious version kept the real proc-macro2 source intact so builds would not break, and the build script ran silently in the background. The attacker needed one compromised account and one extra line in a Cargo.toml to reach every downstream project.

The Rust Security Response Team has locked the droundy account and restored the yanked versions. The GitHub repositories for arrayref, append-only-vec, and internment are offline, and the maintainer's computer or credentials are likely compromised. Until the maintainer situation is resolved, treat any new release from those crates with suspicion.

The exposure window was under two hours. The cleanup will take longer. If you build with Rust and pulled dependencies on August 20, go check your cache.

Sources

• blog.rust-lang.org Rust Security Response Team announcement
• safedep.io SafeDep technical analysis of arrayref and proc-macro1
• bleepingcomputer.com BleepingComputer coverage of the arrayref supply chain attack
• safeguard.sh Safeguard case study on crates.io account takeover