GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1]
The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate."
I feel crates.io was unprepared for a security incident like this since they're managing the response [4]
I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable.
I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total.
There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.
That would make it unnecessary to pull in foreign dependencies in the overwhelming majority of projects. What few do get pulled in becomes lightweight, easily verifiable syntactic sugar or libraries with purposes too niche to be worth targeting.
Of course this approach can go wrong too. You could easily end up with a monster like Boost, but that comes down to project administration keeping creep under control and proper modular design.
Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high.
Also most of these dependencies provide a breadth of features that the end package does probably not need.
show comments
fidotron
Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster.
Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
show comments
fwlr
From the article: “[for Windows victims,] the [malicious] build script [fetches the attacker’s remote payload,] writes [it] to %TEMP%\rust-setup.ps1 and starts [it] through a VBScript launcher under wscript.exe, with a comment in the source explaining why:”
And the comment is:
// ShellExecute via WScript escapes Cargo's job object; spawned children otherwise
// keep the build script (and `cargo build`) waiting until they exit.
So the malicious build script has a helpful comment (???), written in a familiar “terse nouns verbing” style (!!!).
Would it be gauche to speculate? Maybe some script kiddy sweet-talked Fable into dropping its safeguards, or maybe Anthropic is doing a training run for Fable 5.1 and the air-gaps aren’t gapping.
It provides sandboxing for arbitrary CLI commands using Seatbelt / SBPL on macOS and Landlock LSM + seccomp-bpf on Linux. You can use it to protect local dependency builds, or integrate it into GitHub Actions to add an extra layer of protection to CI.
Feel free to give it a try — I’d love to hear your feedback.
tancop
We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler.
In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the binary instead of uploading all your CI secrets and deleting the whole hard drive.
show comments
vatsachak
All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.
show comments
hoppp
The rust ecosystem is going to be hit by malware just like the NPM ecosystem. I have been saying it for years. They made the same mistakes or even worse mistakes because all it takes is a compromised serde to take the entire ecosystem down.
show comments
tsimionescu
> arrayref is a small crate of four macros.
Why do so many languages fall into this horrible practice?
Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for dependencies and will warn about new install scripts (without executing them).
Are there any plans to more seriously develop the standard library in Rust? Or is the plan to remain in this status quo where users of Rust import nonsense and the dependency tree explodes (or users are forced to invent their own wheel?).
Are there any comparisons between the state of the stdlib in C++ vs. Rust? I’d think that would serve as an excellent jumping off point to start chipping away.
show comments
christophilus
Rust seems barely better than Node in this regard. Go or .Net or anything with a robust standard library seems like the way to go for most projects.
show comments
fnoef
Oh, so it's not only "JavaScript bad and npm bad". Apparently, if your language uses third party dependency registry, you are prone to malicious code, regardless if it's Javascript or not.
Use containers for development. And reduce the amount of third party deps you import into your projects. This is only going to get worse.
show comments
xdavidliu
> The genuine arrayref and append-only-vec crates are maintained by droundy, whose account appears to have been compromised.
That name looked familiar to me; I believe it's the same David Roundy who was an academic at Reed College who wrote DARCS, which is version control software. I used DARCS when I started grad school around 2010 before switching to git.
Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users.
It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.
show comments
hsaliak
At least it’s safe
dematz
Jumping off the title and ignoring contents of post, as is customary:
look at this graph and guess which languages use each number of dependencies for their website: https://www.youtube.com/watch?v=E82ly38YEEQ&t=325s
I won't spoil the claim in the video about what the dependency number is correlated with, and I'm not even sure how true it is in general, but it's very interesting.
vlovich123
I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.
show comments
somerandomness
wow, what did payload do?
FartyMcFarter
This is quite the egg on the face, given that Rust proponents keep telling us how it's great for writing secure software.
colingauvin
I hate cargo and npm. Why do we keep settling on arbitrary code execution in our build process?
freakynit
ahh... we now have nodejs ecosystem attack techniques migrating to other systems as well...
Why this still happens? Why after many previous supply-chain attacks maintainers of package repositories still allow anyone uploading packages and pushing updates without security audit?
show comments
ecshafer
These very small dependencies that are then later causing issues either due to malicious nature or incompetence, have become pervasive in computing (for some reason). I think that these should be less of an issue now than ever. Outside of the largest, most critical dependencies, you really shouldn't be pulling in small libraries anymore. Just generate the code via AI. AI is not great at large scale programming I think, but its amazing at snippets of code. Something I ran into recently, I needed to use FFT2 on some matrices, and what I was using didn't have an existing solution. Converting some numpy fft2 tests to my target language, and having a full native implementation of fft2, and an accompanying test suite so it will behave exactly like numpy fft2. A few minutes and a few thousand lines of code later, I have a trusted implementation. Saves me an external dependency, some weird glue code, and an attack vector.
GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. [1]
The bad package version has also just disappeared from crates.io [2] with no indication its been yanked. There's no security advisory there either [3] "No advisories found for this crate."
I feel crates.io was unprepared for a security incident like this since they're managing the response [4]
[1]: https://web.archive.org/web/20260820145918/https://github.co...
[2]: https://crates.io/crates/arrayref/versions
[3]: https://crates.io/crates/arrayref/security (I'd give an Wayback link but that's also broken https://web.archive.org/web/20260820150747/https://crates.io...)
[4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomm...
I think we should be taking a more “batteries included” approach to language and library design. The entire reason we’re in this mess is because we’ve decided it’s ok or maybe even preferable if stdlibs are rail thin, rendering base languages near-unusable.
I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total.
There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.
That would make it unnecessary to pull in foreign dependencies in the overwhelming majority of projects. What few do get pulled in becomes lightweight, easily verifiable syntactic sugar or libraries with purposes too niche to be worth targeting.
Of course this approach can go wrong too. You could easily end up with a monster like Boost, but that comes down to project administration keeping creep under control and proper modular design.
Thread on the post from main rust blog: https://news.ycombinator.com/item?id=49372853
Direct post link: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
Initial report: https://github.com/rustsec/advisory-db/issues/3161
Other vendor posts:
* https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-...
* https://research.jfrog.com/post/arrayref-proc-macro1-crates-...
* https://www.aikido.dev/blog/two-popular-rust-crates-arrayref...
Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹.
¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high.
Also most of these dependencies provide a breadth of features that the end package does probably not need.
Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster.
Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
From the article: “[for Windows victims,] the [malicious] build script [fetches the attacker’s remote payload,] writes [it] to %TEMP%\rust-setup.ps1 and starts [it] through a VBScript launcher under wscript.exe, with a comment in the source explaining why:”
And the comment is:
So the malicious build script has a helpful comment (???), written in a familiar “terse nouns verbing” style (!!!).Would it be gauche to speculate? Maybe some script kiddy sweet-talked Fable into dropping its safeguards, or maybe Anthropic is doing a training run for Fable 5.1 and the air-gaps aren’t gapping.
When several supply-chain attacks hit the npm ecosystem a few months ago, I built SBE: https://github.com/tyrchen/sbe.
It provides sandboxing for arbitrary CLI commands using Seatbelt / SBPL on macOS and Landlock LSM + seccomp-bpf on Linux. You can use it to protect local dependency builds, or integrate it into GitHub Actions to add an extra layer of protection to CI.
Feel free to give it a try — I’d love to hear your feedback.
We need effect based languages now. It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles. If anyone from epic is reading this please give us a timeline for open sorucing the Verse compiler.
In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the binary instead of uploading all your CI secrets and deleting the whole hard drive.
All those folks telling me to update my dependencies, this is why I don't do it. It's not laziness, it's undeniable foresight.
The rust ecosystem is going to be hit by malware just like the NPM ecosystem. I have been saying it for years. They made the same mistakes or even worse mistakes because all it takes is a compromised serde to take the entire ecosystem down.
> arrayref is a small crate of four macros.
Why do so many languages fall into this horrible practice?
We really need Cargo RFC #3923 https://github.com/rust-lang/rfcs/pull/3923
It would allow projects to avoid newly published dependency versions until a configurable waiting period has elapsed.
npm has had a similar min-release-age feature for years.
Post on the Rust blog: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
Discussion: https://news.ycombinator.com/item?id=49372853
Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for dependencies and will warn about new install scripts (without executing them).
There is an open issue for this: https://github.com/rust-lang/cargo/issues/13681
Are there any plans to more seriously develop the standard library in Rust? Or is the plan to remain in this status quo where users of Rust import nonsense and the dependency tree explodes (or users are forced to invent their own wheel?).
Are there any comparisons between the state of the stdlib in C++ vs. Rust? I’d think that would serve as an excellent jumping off point to start chipping away.
Rust seems barely better than Node in this regard. Go or .Net or anything with a robust standard library seems like the way to go for most projects.
Oh, so it's not only "JavaScript bad and npm bad". Apparently, if your language uses third party dependency registry, you are prone to malicious code, regardless if it's Javascript or not.
Use containers for development. And reduce the amount of third party deps you import into your projects. This is only going to get worse.
> The genuine arrayref and append-only-vec crates are maintained by droundy, whose account appears to have been compromised.
That name looked familiar to me; I believe it's the same David Roundy who was an academic at Reed College who wrote DARCS, which is version control software. I used DARCS when I started grad school around 2010 before switching to git.
What does the malicious code actually do?
Rust finally got hit... This was motivating me to swap away from Rust towards because of the huge number of dependencies. It seemed inevitable. Ginger bill was right, https://www.gingerbill.org/article/2025/09/08/package-manage...
I am surprised this took so long.
Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users.
It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward.
At least it’s safe
Jumping off the title and ignoring contents of post, as is customary: look at this graph and guess which languages use each number of dependencies for their website: https://www.youtube.com/watch?v=E82ly38YEEQ&t=325s
I won't spoil the claim in the video about what the dependency number is correlated with, and I'm not even sure how true it is in general, but it's very interesting.
I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.
wow, what did payload do?
This is quite the egg on the face, given that Rust proponents keep telling us how it's great for writing secure software.
I hate cargo and npm. Why do we keep settling on arbitrary code execution in our build process?
ahh... we now have nodejs ecosystem attack techniques migrating to other systems as well...
damn!
I got to watch this attack unfold pretty much in real time as my agents worked the issue. Here is my writeup https://acje.github.io/systems/watching_a_supply_chain_attac...
Why this still happens? Why after many previous supply-chain attacks maintainers of package repositories still allow anyone uploading packages and pushing updates without security audit?
These very small dependencies that are then later causing issues either due to malicious nature or incompetence, have become pervasive in computing (for some reason). I think that these should be less of an issue now than ever. Outside of the largest, most critical dependencies, you really shouldn't be pulling in small libraries anymore. Just generate the code via AI. AI is not great at large scale programming I think, but its amazing at snippets of code. Something I ran into recently, I needed to use FFT2 on some matrices, and what I was using didn't have an existing solution. Converting some numpy fft2 tests to my target language, and having a full native implementation of fft2, and an accompanying test suite so it will behave exactly like numpy fft2. A few minutes and a few thousand lines of code later, I have a trusted implementation. Saves me an external dependency, some weird glue code, and an attack vector.