Malicious Rust crate Arrayref runs a build-time payload • Hacker News Board

Re: Malicious Rust crate Arrayref runs a build-time payload

#231

Post by ChrisSD » Thu, Aug 20, 2026, 6:12 PM UTC

mike_hearn wrote: post #213

swiftcoder wrote: post #93

Earlier quoted context omitted.

build.rs by design can run absolutely anything. There tons of build.rs scripts that invoke a whole-ass C compiler toolchain to build and link C dependencies... It isn't so much a question of sandboxing build.rs, as fundamentally changing the way that foreign dependencies are integrated into the rust toolchain (i.e. moving from a rust-centric system like Cargo to something more general like buck2)

Worth noting that the JVM ecosystem doesn't have this issue because there is no notion of installing dependencies, and the package managers are just downloaders with nothing else. No build.rs equivalent. To solve the problem of native/C dependencies, they just bundle pre-compiled libraries as data files. Rust could do the same thing.

But then that shifts the issue. You've now got an opaque binary blob being injected into programs. What if it is malicious?

Re: Malicious Rust crate Arrayref runs a build-time payload

#232

Post by cube00 » Thu, Aug 20, 2026, 6:12 PM UTC

thayne wrote: post #217

maximegarcia wrote: post #200

Earlier quoted context omitted.

Call it how you want, the point is that it should not disappear like this. Maybe yanked has the meaning you said, but in Ruby yanked has the meaning OP said and that is what we want. How to call it then : Yanked hard vs yanked soft ?

Crates.io currently says: > A new version of the arrayref crate was published with a direct dependency on proc-macro1, which would execute a malicious build script. > This compromised version was published on 2026-08-20 and removed approximately 86 minutes later, with no evidence of actual usage. I don't know what more you want. Do you want the malicious version to continue to be available?

> I don't know what more you want.

The version page [1] should show that for 86 minutes there was a version 0.3.10, it was malicious and was deleted with a link to the advisory. I get this takes time so even a generic "deleted" entry until they have time to link in the advisory would also be fine so we know something is happening.

Presumably even "deleted" crate versions still have some metadata left behind in the backend so this should be surfaced.

[1]: https://crates.io/crates/arrayref/versions

Re: Malicious Rust crate Arrayref runs a build-time payload

#233

Post by smw » Thu, Aug 20, 2026, 6:12 PM UTC

echelon wrote: post #223

nemothekid wrote: post #220

Earlier quoted context omitted.

> 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. The big reason is money & time. Maybe less so today if you are happy with an AI generated stdlib, but I don't thi…

Python is batteries included, but all the batteries have corroded. Look at C++'s long in the tooth STL. You don't want to marry a language to fast aging libraries you have to support for eternity. Better libraries always naturally emerge. Rust's decision here is fine. The only thing I'd like to see is the ability to programmatically limit transitive dependency count or depth in Cargo. I'd also like crates to specify…

I think maybe the right answer is to have a standardized, curated group of libraries pegged at some sort of LTS release that only backports security fixes. However, someone would need to pay for creating and maintaining this -- and then you wonder where the money would come from?

Re: Malicious Rust crate Arrayref runs a build-time payload

#234

Post by [deleted] » Thu, Aug 20, 2026, 6:16 PM UTC

fnoef wrote: post #73

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.

[deleted]

Re: Malicious Rust crate Arrayref runs a build-time payload

#235

Post by TZubiri » Thu, Aug 20, 2026, 6:16 PM UTC

cosmic_cheese wrote: post #78

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 tot…

>I think we should be taking a more “batteries included” approach

https://www.youtube.com/watch?v=GZOuz-SG7-g

Funny how you skipped "I should build my own batteries" and when straight to "increasing and centralizing the duties of your main gratis 'vendor'".

Re: Malicious Rust crate Arrayref runs a build-time payload

#236

Post by frollogaston » Thu, Aug 20, 2026, 6:17 PM UTC

fnoef wrote: post #73

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.

It's funny how left-pad was always brought up as a JS supply chain vuln when that wasn't even malware

Re: Malicious Rust crate Arrayref runs a build-time payload

#237

Post by tyrchen » Thu, Aug 20, 2026, 6:18 PM UTC

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.

Re: Malicious Rust crate Arrayref runs a build-time payload

#238

Post by sfdsfef3f3f » Thu, Aug 20, 2026, 6:18 PM UTC

Mawr wrote: post #216

sfdsfef3f3f wrote: post #53

Earlier quoted context omitted.

Go has a stronger standard library for certain use cases like basic CRUD web applications, but a lot of the Go standard library is also extremely low quality (flag, container, image, json, log, math, path, regexp, sync, time). Many of these aren't usable outside of toy use cases and have weird edge cases all over the place. Over time many will probably get new incompatible versions just like json. The container packa…

FYI, json/v2 just dropped: https://go.dev/doc/go1.27#jsonv2 and log/slog has been a thing since 1.21: https://go.dev/doc/go1.21#slog > a lot of the Go standard library is also extremely low quality Now adjust your definition of "a lot" to include all other languages instead of apparently arbitrarily deciding that "a lot" means at best 10 and pretending that "weird edge cases all over the place" isn't normal. I also w…

> Another frequently made suggestion straight from la-la land is just writing perfect code from the get-go.

The code in those packages is so far from perfect it's absurd. Like most Go developers, you just have extremely low standards.

Re: Malicious Rust crate Arrayref runs a build-time payload

#239

Post by kergonath » Thu, Aug 20, 2026, 6:19 PM UTC

lesuorac wrote: post #192

rirze wrote: post #167

Earlier quoted context omitted.

which, as painful as it may be, is ok. Better to have a safe functional stdlib library than a exposed external crate (which then asks the question; what's the replacement...)

Those aren't the only two choices. We also have the classic example of PHP with numerous not safe stdlib ways to use mysql. To me the answer is still to vendor your dependencies and don't be on the bleeding edge of updates unless you're willing to invest the time into validating them.

> We also have the classic example of PHP with numerous not safe stdlib ways to use mysql.

I think it goes without saying that emulating PHP is rarely a good decision.

Re: Malicious Rust crate Arrayref runs a build-time payload

#240

Post by pjmlp » Thu, Aug 20, 2026, 6:20 PM UTC

0cf8612b2e1e wrote: post #160

yoyohello13 wrote: post #85

Earlier quoted context omitted.

This was actually the main thing that put me off of Rust. I get the argument for a small std lib. I just also don’t agree it’s worth it. Go seems to handle having a batteries included standard lib just fine.

On the other hand, there are some bad Go standard libraries that are frozen in time.

Yeah, but I will take a not great library that works everywhere the compiler does, than be at the whims of which platforms are supported by 3rd party libraries.

I can use most of the clunky Python, Java, .NET and if it must be, Go, standard libraries, than hunting down for dependencies with platform tier support and such.