{"slug": "attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware", "title": "Attackers poisoned three Rust crates and used Cargo builds to run malware", "summary": "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.", "body_md": "# Attackers poisoned three Rust crates and used Cargo builds to run malware\n\n**The releases lived for under two hours, but Cargo build scripts could execute the downloader on developer laptops and CI runners.**\n\nBy [RuntimeWire Staff](/author/runtimewire-staff)\n· Published\n\nPrimary source: [Aligned News - AI Intelligence](https://x.com/LundukeJournal/status/2090808186861178976)\n\n## Why it matters\n\nRust'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.\n\nAttackers 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.\n\nRoundy, a physicist listed by Oregon State University as former faculty, maintains `arrayref`\n\n, `internment`\n\nand `append-only-vec`\n\n. 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.\n\nThe 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.\n\nThe affected releases were [ [email protected]](https://crates.io/crates/arrayref?ref=runtimewire),\n\n[and](https://crates.io/crates/internment?ref=runtimewire)\n\n`[email protected]`\n\n[. Each introduced a dependency on](https://crates.io/crates/append-only-vec?ref=runtimewire)\n\n`[email protected]`\n\n`proc-macro1`\n\n, a package made to resemble David Tolnay's legitimate `proc-macro2`\n\ncrate.### The code ran during the build\n\nThe attack did not require an application to call a compromised library function. Cargo automatically compiles and executes a crate's `build.rs`\n\nscript during operations including `cargo build`\n\nand `cargo check`\n\n. 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.\n\n[JFrog's analysis](https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/?ref=runtimewire) found that `proc-macro1`\n\ncopied much of the legitimate `proc-macro2`\n\npackage 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.\n\nThe 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.\n\nwas deleted 86 minutes after publication, [[email protected]](/cdn-cgi/l/email-protection)\n\nremained available for about 90 minutes, and [[email protected]](/cdn-cgi/l/email-protection)\n\nwas 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.\n\nThe response team also deleted `proc-macro1`\n\nand several related lookalike packages, restored legitimate versions that the attacker had yanked, and locked the affected maintainer account.\n\n### Hundreds of millions of downloads, but an unknown victim count\n\nThe post described the incident as potentially affecting millions of programmers. The available evidence does not establish that scale.\n\n[JFrog cited](https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/?ref=runtimewire) roughly 245 million lifetime downloads for `arrayref`\n\n, 14.4 million for `internment`\n\nand 4.5 million for `append-only-vec`\n\n. 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.\n\nProjects 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`\n\n, generated a new lockfile or otherwise selected one of the compromised versions while it was available.\n\nThe 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.\n\n### Maintainer access became infrastructure access\n\nRoundy'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.\n\nThe 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.\n\nThe 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`\n\nfiles and vendored trees, reverting to `arrayref`\n\n0.3.9, `internment`\n\n0.8.6 and `append-only-vec`\n\n0.1.8, and regenerating lockfiles from trusted registry metadata.\n\nJFrog 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.\n\nThe 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.", "url": "https://wpnews.pro/news/attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware", "canonical_source": "https://runtimewire.com/article/rust-crates-arrayref-supply-chain-attack", "published_at": "2026-08-22 23:55:46+00:00", "updated_at": "2026-08-23 00:13:09.890380+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["David Roundy", "Rust Security Response Team", "crates.io", "arrayref", "internment", "append-only-vec", "proc-macro1", "JFrog"], "alternates": {"html": "https://wpnews.pro/news/attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware", "markdown": "https://wpnews.pro/news/attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware.md", "text": "https://wpnews.pro/news/attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware.txt", "jsonld": "https://wpnews.pro/news/attackers-poisoned-three-rust-crates-and-used-cargo-builds-to-run-malware.jsonld"}}