Malicious Rust crate arrayref runs a build-time payload

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.

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.

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.

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.