Three Compromised Rust Crates Distributed Malware During Compilation

Three Malicious Releases Removed from crates.io

The Rust project removed three compromised versions of widely used crates from crates.io: arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9.

The releases were published on August 20, 2026 by the same account owner and remained available for between 86 and 107 minutes:

• arrayref 0.3.10: from 07:15:00Z to 08:41:40Z;
• internment 0.8.7: from 07:34:07Z to 09:04:11Z;
• append-only-vec 0.1.9: from 07:37:49Z to 09:25:24Z.

The Rust Security Response Team received the first report at 07:15 UTC, following the discovery of a malicious crate named proc-macro1. Its name mimicked the legitimate proc-macro2, a typosquatting technique designed to blend into dependency manifests.

The following crates are also considered compromised in every version: proc-macro1, proc-macro-en, aovine, arone, aronenao, and tinymember.

No CVE identifier was assigned. RustSec advisories contain no evidence that the malicious versions were actually used. The incident is also not listed in CISA’s KEV catalog.

The Attack Began with a Normal Cargo Build

The attack did not require using any specific function from the compromised crates. Running cargo build, cargo check, or cargo test was sufficient on a project that resolved the tampered dependency.

The release manifest included an additional entry introducing proc-macro1. The counterfeit crate contained the authentic source code of proc-macro2, allowing it to behave normally at first glance. The malicious component was a build script that ran automatically during compilation.

The script reconstructed the command-and-control server address and the payload download URL from Base64-encoded fragments. It also installed a custom TLS verifier whose three validation functions always returned success. In practice, certificate verification was disabled.

The code then selected one of four payloads based on the operating system and processor architecture. On Unix and macOS, the file was written to /tmp/rust-setup, marked as executable, and launched in the background, with the C2 address passed as its first argument.

On Windows, two files were created in the user’s temporary directory:

• %TEMP%\rust-setup.ps1;
• %TEMP%\rust-setup-launch.vbs.

The second file was executed through wscript.exe in hidden mode. The child process was then detached from Cargo’s job object, preventing the build from waiting for it to terminate.

The result was an attack chain embedded in the build phase, before the application itself was ever executed. This is materially different from malware triggered only by the program’s runtime behavior.

Withdrawing Previous Versions Helped Distribute the Malicious Release

The publication of arrayref 0.3.10 was accompanied, within the same minute, by the withdrawal of legitimate versions 0.3.5 through 0.3.9. This made the malicious release the only available version in the compatible series.

Cargo uses caret requirements for many dependencies. A constraint such as arrayref ^0.3.6 accepts all compatible versions in the 0.3.x series, including 0.3.10. GitHub researcher jhobern said this mechanism was how they encountered the attack.

The potential reach of arrayref is significant. A crates.io API check conducted on August 21, 2026, found:

• 245,385,500 total downloads;
• 53,905,601 downloads in the 90 days ending August 20;
• 403 distinct crates listing it as a dependency.

One dependency chain involved winit, which requires sctk-adwaita ^0.10.1; that crate depends on tiny-skia ^0.11, which in turn requires arrayref ^0.3.6.

blake3 also depended on arrayref through version 1.8.6, but not through 1.8.7, which was published at 09:09 UTC. The blake2b_simd and blake2s_simd projects removed the dependency in releases published at 09:25 and 09:26 UTC, respectively.

The method used to compromise the account is unknown. The legitimate owner of arrayref is crates.io user 2402, David Roundy, who registered in October 2009. The Rust team believes the computer or credentials were likely compromised, rather than the author acting intentionally.

The Payload Established Persistence and Stole Browser Data

According to Wiz, the next-stage payload communicated through HTTPS POST requests to the /49890878 path. The malware could install operating-system-specific persistence mechanisms:

• a Registry Run key on Windows;
• a LaunchAgent on macOS;
• a user-level systemd service on Linux.

The component supported four command categories: termination, C2 server modification, persistence installation, and the download and execution of additional scripts.

Wiz also observed credential theft from the SQLite databases of Chrome, Brave, and Edge. However, Nextron’s analysis of the Windows payload found only reads of the origin_url and username_value fields, with no direct extraction of password_value.

The Linux and macOS payloads were available only as hashes and were not analyzed. The findings observed in the Windows sample therefore cannot automatically be extended to the other two operating systems.

Attribution remains unresolved. Wiz reported infrastructure overlaps with previous North Korean supply-chain campaigns, including the compromises of Mastra npm and axios. Microsoft linked the Mastra operation to Sapphire Sleet, while GTIG attributed the axios incident to MIDNIGHT NEPTUNE, previously tracked as UNC1069.

However, no vendor has attributed this crates.io campaign to a specific group.

What Developers Should Check

The Rust Security Response Team removed the malicious releases and revoked their previous yanked status to manage the incident. For arrayref, users are advised to remain on version 0.3.9 or earlier. No fixed release exists for the three compromised versions.

Developers should:

1. check ~/.cargo/registry/cache for the removed packages;
2. review projects built with cargo build, cargo check, or cargo test;
3. search for connections to known indicators;
4. check for temporary files and persistence mechanisms;
5. rotate any credentials used on affected systems.

Network indicators include:

• 23.254.165.112:9089, the payload server;
• 23.254.165.112:443, the C2 infrastructure;
• hwsrv-798836.hostwindsdns.com.

Files to look for include /tmp/rust-setup, %TEMP%\rust-setup.ps1, and %TEMP%\rust-setup-launch.vbs. Reported binary names include rust-crate_0.1.0, _0.2.0, _0.3.0, and _0.4.0.

Metadata associated with accounts dtolney, identified as an impersonator, and droundy, associated with the legitimate owner, should also be reviewed. The email address [email protected] was also reported.

For arrayref, the incident is documented in advisory RUSTSEC-2026-0260. Cargo still has no default waiting period for newly published dependencies: a proposal to stabilize global-min-publish-age remained open on August 21, 2026.

The incident highlights the risks of automatically updated dependencies and, above all, scripts executed during compilation. In a previous case in September 2025, two malicious crates activated their code only at runtime. Here, the entry point was the build process itself—a phase often considered more trusted within the software supply chain.