Attackers poisoned three Rust crates and used Cargo builds to run malware

Attackers published malicious versions of three Rust crates—arrayref, internment, and append-only-vec—through a compromised publishing account associated with David Roundy on August 20th, turning routine Cargo builds into a path for downloading and executing an unknown payload. The Rust Security Response Team removed the releases within roughly two hours and locked Roundy's crates.io account, stating they do not believe Roundy acted maliciously and that his computer or credentials were likely compromised. The malicious dependency, proc-macro1, copied the legitimate proc-macro2 package and added a downloader to its build script, executing on developer machines and CI runners.

Attackers poisoned three Rust crates and used Cargo builds to run malware The releases lived for under two hours, but Cargo build scripts could execute the downloader on developer laptops and CI runners. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: Aligned News - AI Intelligence https://x.com/LundukeJournal/status/2090808186861178976 Why it matters Rust's memory safety does not protect builds from malicious dependencies. A compromised maintainer credential can give attackers code execution across developer machines and CI systems. Attackers published malicious versions of three Rust crates through a compromised publishing account associated with David Roundy https://osuper.physics.oregonstate.edu/directory/david-roundy?ref=runtimewire on August 20th, turning routine Cargo builds into a path for downloading and executing an unknown payload. The Rust Security Response Team removed the releases within roughly two hours and locked Roundy's crates.io account. Roundy, a physicist listed by Oregon State University as former faculty, maintains arrayref , internment and append-only-vec . His documentation for arrayref https://droundy.github.io/arrayref/?ref=runtimewire describes a deliberately compact package: four macros for creating array references from slices and arrays. That limited scope helped make it the sort of dependency developers could install and then stop thinking about. The Rust team said it does not believe Roundy acted maliciously. In its August 20th incident report https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/?ref=runtimewire , the team said his computer or publishing credentials were likely compromised. The report was written by Manish Goregaokar https://rust-lang.org/governance/people/Manishearth/?ref=runtimewire , a Rust Security Response Team member who also leads the project's Clippy and developer-tools teams. The affected releases were email protected https://crates.io/crates/arrayref?ref=runtimewire , and https://crates.io/crates/internment?ref=runtimewire email protected . Each introduced a dependency on https://crates.io/crates/append-only-vec?ref=runtimewire email protected proc-macro1 , a package made to resemble David Tolnay's legitimate proc-macro2 crate. The code ran during the build The attack did not require an application to call a compromised library function. Cargo automatically compiles and executes a crate's build.rs script during operations including cargo build and cargo check . That behavior gave the malicious dependency code execution on developer workstations and continuous-integration runners as soon as an affected dependency graph was resolved and built. JFrog's analysis https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/?ref=runtimewire found that proc-macro1 copied much of the legitimate proc-macro2 package while adding a downloader to its build script. It also spoofed Tolnay's name in the author field and listed the repository github.com/dtolnay/proc-macro1 https://github.com/dtolnay/proc-macro1?ref=runtimewire as its repository. Tolnay is not accused of involvement. The Rust team credited the research group at Nextron Systems GmbH with discovering and reporting the malicious package. In its report, the team said it received the report at 07:15 UTC on August 20th. was deleted 86 minutes after publication, email protected /cdn-cgi/l/email-protection remained available for about 90 minutes, and email protected /cdn-cgi/l/email-protection was online for about 107 minutes. email protected /cdn-cgi/l/email-protection The Rust incident report https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/?ref=runtimewire documents those response timings. The response team also deleted proc-macro1 and several related lookalike packages, restored legitimate versions that the attacker had yanked, and locked the affected maintainer account. Hundreds of millions of downloads, but an unknown victim count The post described the incident as potentially affecting millions of programmers. The available evidence does not establish that scale. JFrog cited https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/?ref=runtimewire roughly 245 million lifetime downloads for arrayref , 14.4 million for internment and 4.5 million for append-only-vec . Those totals measure the historical reach of the legitimate packages. They do not show how many systems downloaded the poisoned releases during their short availability window, much less how many successfully contacted the attacker's server. Projects with an existing lockfile pinned to an older version would not automatically install the malicious release. The higher-risk group includes developers and CI jobs that refreshed dependency resolution, ran cargo update , generated a new lockfile or otherwise selected one of the compromised versions while it was available. The exposure can also outlive the deletion from crates.io. Package caches, vendored dependency trees and internal registry mirrors may retain copies after a registry removes the original release. A poisoned version can therefore remain buildable inside an organization even after the public cleanup. Maintainer access became infrastructure access Roundy's role in the incident shows the uncomfortable economics of open-source maintenance. A small library can sit deep inside a large number of dependency trees while its publishing authority remains concentrated in one person's workstation and credentials. An attacker does not need to defeat Rust's memory-safety guarantees when a trusted maintainer account can authorize code that the build system is designed to execute. The useful metric here is the privilege attached to the dependency, rather than its line count. Cargo build scripts run before an application exists and can access whatever secrets and network permissions are available to the build environment. On a developer laptop, that can include source code and local credentials. In CI, it can include signing keys, deployment tokens and cloud credentials. The Rust team's guidance is to inspect the local Cargo registry cache for the deleted versions and related malicious packages. JFrog additionally recommends https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/?ref=runtimewire checking Cargo.lock files and vendored trees, reverting to arrayref 0.3.9, internment 0.8.6 and append-only-vec 0.1.8, and regenerating lockfiles from trusted registry metadata. JFrog advises treating confirmed execution as a full host compromise because the second-stage payload's behavior remains unknown. Environments that refreshed a lockfile during the exposure window should be investigated, and credentials available to affected machines or CI runners should be rotated where execution is confirmed. The poisoned releases were available briefly, and the registry response was fast. The attack still succeeded at the part that matters strategically: it converted trust in a real maintainer's established packages into automatic code execution. The remaining work is finding where that trust was exercised during those 107 minutes.