The Attack
The Rust Security Response Team was notified by Nextron Systems GmbH on 2026-08-20 of a malicious crate proc-macro1.
proc-macro1 is a typo squatting of proc-macro2, a well known crate in Rust ecosystem. They discovered that this package executed a malicious script at build time that downloaded and executed a malicious payload. Other malicious crates were also discovered, such as proc-macro-en, aovine, arone, aronenao, tinymember.
Type-squatting attacks are already a problem on their own, but the attack was significantly amplified by the compromise of some widely used crates, which were used to introduce dependencies on the malicious crates.
Specifically, the crates arrayref, internment, and append-only-vec all developed by the same author were compromised. The attackers injected a dependency for the malicious crate and yanked the most recent versions, so it would be delivered to users fetching them.
Interesting to see this type of supply-chain attack, which is relatively common in ecosystems like npm, becoming a recurring concern in Rust as well.
Cargo Yank Mechanism
The idea of the mechanism is to mark a published crate version as unusable for new dependency resolution. The crate is not deleted, existing builds and lockfiles that already pin it keep working. It is useful to steer developers away from an accidental publish, a broken release, or a version with a known vulnerability.
In August 2026, an attacker who had taken over the arrayref maintainer's account abused this mechanism. They published a malicious version 0.3.10 and yanked the legitimate releases. With the legitimate releases yanked, new builds resolved to the malicious one, and existing builds started printing a warning that their pinned version had been yanked. The warning itself can lure developers into updating to the new malicious release.
How Malicious Code can Be Executed at Build Time
Build scripts let a crate run tasks before compilation, such as compiling a bundled C library, locating one already installed on the host, or generating FFI bindings. This is work that has to happen before the Rust code itself is built.
Cargo looks for a file named build.rs in the root of a package. If it finds one, it compiles that file into a native executable and runs it, with the privileges of whoever ran cargo.
This happens for every dependency in your project, not just your own code. So an attacker who hijacks a crate you already depend on, or persuades you to add one, gets arbitrary code execution on your machine at compile time.
It is not only cargo build that sets this off. Any command that needs a compiled view of the project will run the build scripts first:
- cargo build - compiles the project
- cargo check - type-checks without producing a binary
- cargo test - builds and runs the test suite
- cargo run - builds the project and executes the resulting binary
- cargo clippy - runs the linter
- cargo doc - generates the documentation
- cargo bench - builds and runs benchmarks
- cargo install - fetches a crate and builds it
The Payload
The second-stage payload collects information from the system to send to the attacker, including host information, and enumerating saved logins in browsers.
It establishes persistence so it can continue running after the build process has finished. The payload communicates with attacker-controlled infrastructure and runs independently of Cargo. It also appears to be capable of executing scripts supplied by the attacker.
Recommendations
As a response to the incident, the Rust team deleted the malicious packages and also locked the compromised author’s account. You can check your dependencies for the presence of the compromised versions. See below:
CratePublished atDeleted atExposure windowappend-only-vec@0.1.92026-08-20T07:37:49Z2026-08-20T09:25:24Z107 minutesarrayref@0.3.102026-08-20T07:15:00Z2026-08-20T08:41:40Z86 minutesinternment@0.8.72026-08-20T07:34:07Z2026-08-20T09:04:11Z90 minutes
Also check for any version of these: proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember.
If you or your CI ran commands that would build these crates, such as cargo build or cargo install, during the affected window, assume the environment was compromised, regardless of whether the affected crate was a direct dependency or was pulled in transitively through another dependency.
References
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref
https://github.com/rustsec/advisory-db/issues/3161
https://doc.rust-lang.org/cargo/reference/build-scripts.html
.png)
