-
Hackers gained access to a Rust maintainer’s account and added malware in three trusted crates.
-
Developers didn’t need to use the affected code as the malware ran during software build.
-
Teams that built the bad versions should treat those machines as compromised and rotate exposed secrets.
The Rust ecosystem suffered a major software supply-chain attack after hackers managed to release malware via a legitimate maintainer’s account.
The attack affected arrayref, internment, and append-only-vec. All three crates appeared on crates.io on August 20. The attacker added a fake dependency called proc-macro1. Its name closely copies the trusted proc-macro2 crate.
Security researchers from Wiz, StepSecurity, Aikido, and others found the campaign. The Rust Security Response Team removed the malicious releases and locked the maintainer account. The team said the maintainer’s computer or credentials were likely compromised. It does not believe the maintainer acted maliciously.
How the Attack Worked
The attacker published proc-macro1 before targeting the three legitimate crates. Version 1.0.106 looked like a clean copy of proc-macro2. Version 1.0.107 carried the malicious code.
The bad crates added proc-macro1 to their package files. That small change gave the attacker a way to run code during a build.
Cargo runs build scripts while compiling a project. In this case, the proc-macro1 build script rebuilt a server address from encoded text. It then downloaded a second-stage program.
The malware has support for virtually every top operating system, including Linux x86-64 and Windows x86-64. Intel and ARM Mac OS aren’t an exception. On Unix systems, it quietly planted its payload in /tmp/rust-setup. On Windows, it used rust-setup.ps1 and a hidden VBS launcher.
The build could still finish normally. A developer did not need to call an arrayref function. Building a project with a bad version was enough to trigger the malware.
What the malware can do
Wiz found that the second-stage malware acts as a backdoor. It sends system details to a command server and can run commands on the infected machine.
The malware checks Chrome, Brave, and Edge profiles. It queries their SQLite databases for saved login records and extension data. Wiz later clarified that it did not retrieve encrypted browser passwords. Still, the access creates a serious risk on developer machines.
The malware is persistent, too. Even rebooting a system doesn’t deactivate it; it’ll still continue running after the reboot. On Windows, it persists by creating a Registry Run key. Meanwhile, on macOS, it sets up a LaunchAgent. And on Linux, the malware installs itself as a systemd user service. It can even run shell scripts or PowerShell scripts, depending on the target.
A short attack window
According to Rust’s blog post, the malicious releases appeared within minutes of each other. The tainted version of arrayref 0.3.10 went live at 07:15 UTC. Just 19 minutes later, internment 0.8.7 appeared. Then append-only-vec 0.1.9 went live at 07:37 UTC. All three releases happened in less than 30 minutes.
Crates.io removed arrayref after 86 minutes, internment after 90 minutes, and append-only-vec after 107 minutes.
The attacker also yanked older arrayref releases just after publishing version 0.3.10. StepSecurity says this may have pushed developers toward the malicious version when they tried to fix a new warning. Crates.io later restored the clean releases.
The Blast Radius is Large
arrayref has recorded around 245 million lifetime installs, and around 53.7 million downloads in the last 90 days, according to StepSecurity. Internment, on the other hand, boasts about 14.4 million lifetime installs, while append-only-vec had approximately 4.5 million lifetime downloads.
This does not mean that millions of computers have been infected. Downloads count package fetches, not unique users. Still, the crates sit deep inside many Rust projects. Researchers found links to blake3, GUI tools such as egui and eframe, Ethereum tooling, and Solana software.
Rust’s security team also deleted proc-macro-en, a second attacker-controlled dropper, plus aovine, arone, aronenao, and tinymember.
Researchers See Possible North Korean Links
Wiz found infrastructure overlap with recent supply-chain attacks tied to North Korean threat groups. They linked parts of the campaign to infrastructure seen in attacks involving Mastra and axios. The overlap does not prove the same group carried out the attack.
This Rust attack is part of a wider pattern of North Korean campaigns against open-source developers. Researchers have identified a campaign codenamed PolinRider that has been active since at least December 2025, producing 162 malicious release artifacts across 108 packages and extensions in npm, Packagist, Go modules, and Chrome extensions. The campaign uses obfuscated JavaScript loaders hidden inside legitimate GitHub repositories, often concealed in fake .woff2 font files or configuration files to deliver DEV#POPPER RAT and OmniStealer.
What Developers Should Do
Teams should check every Cargo.lock file for arrayref 0.3.10, append-only-vec 0.1.9, and internment 0.8.7. They should also search for proc-macro1, proc-macro-en, arone, aronenao, aovine, and tinymember.
StepSecurity says any hit on those attacker-controlled crates should be treated as a compromise. Clean versions are arrayref 0.3.9, internment 0.8.6, and append-only-vec 0.1.8.
Security teams should hunt for /tmp/rust-setup on Unix systems. Windows users should look for rust-setup.ps1 and rust-setup-launch.vbs files in the temporary folder of the victim’s computer if the attack occurs in Windows-based systems.
Network teams ought to check all traffic going to 23.254.165.112 at ports 9089 and 443. Wiz noted 23.254.167.107 and 23.254.167.216 as related indicators.
If a machine created one of these compromised releases, assume it’s been breached. Rotate cloud keys, CI tokens, signing keys, SSH keys, and other secrets the machine could access. The user would need to rebuild the affected software using clean sources.
The case illustrates that even a small modification to a trusted package can turn the build process into a security incident.