11 ms·

Malicious Rust crate Arrayref runs a build-time payload

• AccountForSale 1mo ago
  [flagged]
• Booyaka101 1mo ago
  [dead]
• tgma 1mo ago
  On the bright side, at least the exploit is memory safe.
• freakynit 1mo ago
  ahh... we now have nodejs ecosystem attack techniques migrating to other systems as well...
  • pixl97 1mo ago
    It's not very surprising as the node attacks were very effective at gathering credentials.
• praseodym 1mo ago
  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 https://github.com/rust-lang/cargo/issues/13681
  • weinzierl 1mo ago
    Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker. I share the dislike for arbitrary build scripts but restricting them will not help the supply chain issue in a significant way. Also there are several ways to control build.rs execution in the Cargo ecosystem as well, for example with cargo-deny.
    • vlovich123 1mo ago
      Disallow lists are ineffective - better to disallow by default and require opt in. Also, crates.io can defer serving up newly uploaded scripts that have a new build.rs / proc-macro dependency and warn publicly that a version introduces it. Restricting build scripts 100% will help mitigate the impact, just not if you only deny it once. And they can develop other things like sandboxing for build scripts by default and escaping that to be the exception that has to be explicitly allowed.
    • praseodym 1mo ago
      You’re right about attackers being able to change runtime code. pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security
      • faern 1mo ago
        > pnpm has a cooldown period for new dependencies Cargo has `min-publish-age` in nightly, and it's currently heading towards stabilization: https://github.com/rust-lang/cargo/pull/17335 https://github.com/rust-lang/cargo/pull/17335
    • Aeolos 1mo ago
      The problem is that build scripts run automatically without user consent or intevention. `cargo add` is sufficient to compromise you, before you have a chance to even vet the code.
• aftbit 1mo ago
  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.
  • Retr0id 1mo ago
    It usually takes some time for an updated dependency to actually get shipped to users in a release, by which time there's a good chance the attack has been noticed.
  • crote 1mo ago
    > Why do none of these hijacks embed runtime attacks? It seems like worming the build machines is the goal, rather than compromising downstream users. Developer machines are quite juicy targets. They tend to have all sorts of credentials lying around, so it often isn't too difficult to escalate from that to compromising AWS/GCP/etc. On top of that there's very little preventing a compromise. Developers are inherently expected to run untrusted code, and the usual Linux / MacOS laptop probably isn't even running any kind of anti-virus protection. Want to compromise the downstream app? Now you also need to pass Play Protect & friends. > It seems like we should be building and testing everything in bubblewrap or some other sandbox going forward. Yes, we really should. It is frankly a miracle that it has taken so long for fetch-time / install-time code execution to start blowing up in our faces. If we are spending so much effort on run-time isolation, why are we completely ignoring all those practices during development?
    • ptx 1mo ago
      Why are developers "inherently expected to run untrusted code"? Running untrusted code on developer machines seems like a terrible idea, given that it will compromise everything they build or deploy and (as you mentioned) all their credentials.
      • brazukadev 1mo ago
        because cloning repos and installing dependencies is what developers do daily. 90% of more don't care or even know that doing so they are risking getting hacked.
• Panzerschrek 1mo ago
  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?
  • surajrmal 1mo ago
    Who is funding this security audit? Are folks supposed to volunteer their free time? It's a difficult coordination problem. The best folks have come up is to delay adopting new releases by a few days and hope your dependency is popular enough that a security firm audits it for you in that timespan. If you have enough money I suppose you can start employing llms to audit things for yourself.
    • bcjdjsndon 1mo ago
      > Who is funding this security audit? Are folks supposed to volunteer their free time? Same people who keep the whole rust project going, a lot of those are volunteers aren't they? Not mad to think they could do the same for core packages at least
      • aw1621107 1mo ago
        > Same people who keep the whole rust project going, a lot of those are volunteers aren't they? Sure, but from my understanding the Rust project is generally "bottom-up" in that volunteers generally work on what they want to rather than submit their time into a pool for some kind of higher-level management to direct.
      • mirashii 1mo ago
        It’s absolutely mad and extremely entitled to expect that a volunteer group of developers do an order of magnitude or more additional work for no additional pay or benefits to themselves.
        • mabini 1mo ago
          [flagged]
• praseodym 1mo ago
  Post on the Rust blog: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/ https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... Discussion: https://news.ycombinator.com/item?id=49372853 https://news.ycombinator.com/item?id=49372853
• ramimac 1mo ago
  Thread on the post from main rust blog: https://news.ycombinator.com/item?id=49372853 https://news.ycombinator.com/item?id=49372853 Direct post link: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/ https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... Initial report: https://github.com/rustsec/advisory-db/issues/3161 https://github.com/rustsec/advisory-db/issues/3161 Other vendor posts: * https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-chain-attack https://www.stepsecurity.io/blog/arrayref-rust-crate-supply-... * https://research.jfrog.com/post/arrayref-proc-macro1-crates-io/ https://research.jfrog.com/post/arrayref-proc-macro1-crates-... * https://www.aikido.dev/blog/two-popular-rust-crates-arrayref-and-append-only-vec-compromised-in-supply-chain-attack https://www.aikido.dev/blog/two-popular-rust-crates-arrayref...
• christophilus 1mo ago
  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.
  • ajross 1mo ago
    Cargo (and PyPI) is undeniably better than NPM, which is just shockingly bad for cultural reasons. Yet it's not safe, and it's subject to the same class of exploit, as we're seeing. Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software. And indeed Go and .NET and Java all qualify. But the gold standard here is Debian and all its downstreams.
    • nicoburns 1mo ago
      > the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software. I think we might be able to crowdsource audits. At least in the Rust ecosystem I'm confident that this is feasible with the right tooling.
      • rcxdude 1mo ago
        Cargo-crev already exists if you care to use it.
        • nicoburns 1mo ago
          It does, but the UX is pretty lacking compared to the regular package workflow.
    • imtringued 1mo ago
      There is a reason why software foundations like the Apache Software Foundation exist and this is one of the bigger ones. Turns out, it just doesn't make sense to be an independent open source developer of a critical dependency anymore. You can write the software yourself, but you can't publish it yourself. All the Rust library crate developers will have to get together and start their own software foundation. I personally don't believe the standard library argument is very convincing, because even with Java the latest newly added HTTP client has some blatant problems that require you to go with a wrapper like Methanol.
• demibabs 1mo ago
  What does the malicious code actually do?
  • FartyMcFarter 1mo ago
    Yeah I scanned the article and I couldn't find this either.
  • hmry 1mo ago
    I would like to know too, but the author's Github account seems to have been deleted, and the crates.io releases have been completely deleted too (not just yanked) so it seems impossible to view the file :/
• tsimionescu 1mo ago
  > arrayref is a small crate of four macros. Why do so many languages fall into this horrible practice?
  • bcjdjsndon 1mo ago
    Just like c++ thought threads wasn't a std library concern and then later changed they minds, rust will also change tac I predict
    • nicoburns 1mo ago
      Rust is actively incorporating more functionality into the stdlib. The functionality of this crate has been in std since 2024. The ecosystem is just slow to update (not everything is maintained, etc).
      • silverlinex 1mo ago
        [flagged]
        • chaps 1mo ago
          Are you okay?
          • silverlinex 1mo ago
            Better than you
            • chaps 1mo ago
              who's you?
  • rvz 1mo ago
    The languages that have a poor standard library support have this issue and other languages encourage you to import tons of libraries to fix the problem. This is why Javascript and Typescript suffer from this the most and has little to nothing to do with "popularity" and likely 9/10 of these npm packages import an external library. Golang on the other-hand is just as popular and has a stronger standard library which people build against and it is encouraged to use its standard library rather than rolling your own or importing another package to solve the problem.
• vatsachak 1mo ago
  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.
  • beej71 1mo ago
    As long as your versions don't have any security issues...
  • abbadadda 1mo ago
    What purpose does “undeniable” serve here? This tips over into hyperbole, in my opinion, whereas “it’s foresight” is much simpler and stronger. YMMV.
    • pluralmonad 1mo ago
      I think it was to make the tongue-in-cheek nature of the comment more apparent.
      • jfklgkdkdnn 1mo ago
        That’s undeniable.
  • pixl97 1mo ago
    I mean, yes, update your dependencies. But probably after a week or so after they've been release and tested by the first penguins willing to jump into the ocean.
    • kmeisthax 1mo ago
      Holding periods for new updates are a good idea, but I would also prefer having a tool that could provide diffs of the entire project state pre- and post-update; including transitive dependencies being added or removed. Git diffs won't show you that information, by design.
      • 1mo ago
• vlovich123 1mo ago
  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.
  • weinzierl 1mo ago
    Mitigation for what? Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker. I'm not particularly fond of arbitrary build scripts either, but restricting them will not help the supply chain issue in a significant way. Also there are several ways to control build.rs execution in the Cargo ecosystem, for example with cargo-deny.
    • vlovich123 1mo ago
      Defaults matter. It’s nice you can set this up using a plugin to protect yourself, but that doesn’t protect the ecosystem, most of which doesn’t use cargo deny. I also disagree a build scripts is a mild convenience. A build script always runs for anyone it’s a dependency for with full access and context and often has access to secrets in CI. A compromised runtime has more limited access and requires actual invocation of code paths (if you’re lying as a dependency that’s never executed, no exploit). Of course Rust should have language-level support for capabilities so that just invoking a function doesn’t grant it access to arbitrary disk access. But that’s a much more difficult change than tweaking the defaults for cargo.
  • praseodym 1mo ago
    As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.
    • vlovich123 1mo ago
      So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.
• fidotron 1mo ago
  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.
  • jfklgkdkdnn 1mo ago
    minimum-release-age
    • abbadadda 1mo ago
      [dead]
    • llleeeoooh 1mo ago
      is there a way to set up without using the nightly build?
    • xgulfie 1mo ago
      what if I need a dependency my teammate released 5 minutes ago
      • hnlmorg 1mo ago
        You add company packages to an exclusion list.
      • wotb 1mo ago
        It explains that in the link posted.
    • kibwen 1mo ago
      Cargo has been working on min-publish-age, and the PR to stabilize the feature is in its final comment period and currently expected to land in Rust 1.100: https://github.com/rust-lang/cargo/pull/17335#issuecomment-5329278335 https://github.com/rust-lang/cargo/pull/17335#issuecomment-5...
• ecshafer 1mo ago
  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.
  • deleted 1mo ago
    [deleted]
• jakubadamw 1mo ago
  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-script.html https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
  • Panzerschrek 1mo ago
    Sandboxing for build scripts can't work properly. If you sandbox too much, some necessary stuff can't be done. If you sandbox too little, it has no practical value.
    • lobofta 1mo ago
      So let each build script define its own level of sandboxing and then users can determine whether they are okay with that level or not, e.g. `cargo build --sandbox-level=...`
      • jurgenburgen 1mo ago
        That’s not solving the problem, that’s avoiding it by making it the users fault if they make a mistake.
        • kibwen 1mo ago
          Rust, like C, C++, and every other systems programming language, is all about giving users the power to make mistakes. The philosophical difference when it comes to Rust is simply that it tries to force the user to flip off the safety on the gun before letting you shoot yourself in the foot. A Cargo config option letting people opt-out of sandboxing would be fully in line with Rust's philosophy.
          • jurgenburgen 1mo ago
            Having a dangerous flag as a backwards compatibility flag is okay. I don’t think making users decide between multiple levels of sandboxing is constructive, they will just be trained to ignore it. This is the kind of decision users likely don’t understand without looking at the source code of a crate and it’s bad UX to push it to be their responsibility.
• purplethreads 1mo ago
  [flagged]
• abbadadda 1mo ago
  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.
  • kibwen 1mo ago
    The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate was made redundant by the new cfg_select macro. And half of every dependency graph that people wrong their hands over are actually first-party external crates provided by either the Rust organization itself or by known contributors to the project. When people say that Rust has a small standard library, mostly they seem to just mean that it doesn't include a webserver.
    • bel8 1mo ago
      It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing. I won't mention lack of date/time lib because that's complex and changes often. That's why projects end up with 100s of crates, sometimes 1000s. This might not be a well received fact in Rust community, but it's a fact nonetheless.
      • bilkow 1mo ago
        My personal opinion on each of those: JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs. regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trust std, you trust the rust-lang organization anyway), but without the issues of being in std (backwards compatibility and bloat). The only problem I see with that is that BurntSushi is still the owner of the package and as such can still publish new versions on his own (AFAIK crates.io currently requires at least one user owner, but that's something that can be solved by improving crates.io permissions). walkdir: It has been been postponed, due to the complexity of WalkDir, but may be added in the future. I agree this should be in std. https://web.archive.org/web/20260820171531/https://github.com/rust-lang/libs-team/issues/677#issuecomment-3428945051 https://web.archive.org/web/20260820171531/https://github.co... RNG: rand is still evolving, with breaking changes half a year ago. Preferred generators tend to change over time, so I don't see those getting into std (remember, it has to be maintained forever!). I could see the interface (traits) getting into std, but I see no advantage to it: it's maintained by rust-random, but even if you wanted it to be maintained by the same authors as the Rust language (let's say you trust them more than rust-random), you could just move it back to rust-lang-nursery or rust-lang. CLI arg parsing: not simple at all! The community's preferred solution has 70kLOC (with support for so many features), but there's also argh, pico-args, and others, each with their own tradeoffs. > That's why projects end up with 100s of crates, sometimes 1000s. Also because libraries are split up in many crates. For example, regex is split in 3 crates: regex, regex-syntax and regex-automata, and depends on other crates from the same author, such as aho-corasick. All that said, there are many crates, such as algorithms like aho-corasick, that I think could me moved into the rust-lang org, like regex was. See also: https://home.expurple.me/posts/a-big-standard-library-is-overkill/ https://home.expurple.me/posts/a-big-standard-library-is-ove...
• fnoef 1mo ago
  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.
  • mabini 1mo ago
    [flagged]
    • swiftcoder 1mo ago
      > Just wondering, whenever things go wrong with Rust - why do you all (Rust devs) point the finger at JavaScript? I know it is almost a sport to point fingers at the "evil rust evangelists" on HN at this point, but a quick look at the fnoef's comment history would show you that they are not a rust person. Your account, on the other hand, is a sock puppet created specifically to bitch about rust. Pot, meet kettle?
      • mabini 1mo ago
        [flagged]
      • mabini 1mo ago
        [dead]
    • ux266478 1mo ago
      You're literally replying to someone saying npm is unfairly called out. Rust developers aren't the ones who have problems with it. Otherwise they likely wouldn't be using Rust in the first place. I don't see anyone saying JavaScript is worse about it either, more that they're the same. Why are you getting so defensive about it?
  • insanitybit 1mo ago
    If it weren't a registry it would be ./configure scripts and makefiles. The issue is that sandboxing technology is kinda shit (especially x-plat) and languages don't build it in by default.
• tancop 1mo ago
  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.
  • burnt-resistor 1mo ago
    More than that, we need capability-based languages. No capability passed to it, no permission.
    • kibwen 1mo ago
      First we need capability-based OSes, like we should have had decades ago if worse-is-better hadn't stuck us with Unix. I don't need to care whether or not a program was written in a capability-aware language if the OS fundamentally takes care of that for me.
      • ptx 1mo ago
        FreeBSD does this with Capsicum: https://wiki.freebsd.org/Capsicum https://wiki.freebsd.org/Capsicum
      • grommz 1mo ago
        HarmonyOS is a capability based OS. I don't know why anyone in China is still using Rust. The biggest social engineering hack was for the Rust team to convince developers that it is a safe language.
        • pjmlp 1mo ago
          Actually HarmonyOS NEXT is getting its language as well, Cangjie. https://cangjie-lang.cn/en https://cangjie-lang.cn/en https://cangjie-lang.cn/en/docs?url=%2F1.0.0%2Fuser_manual%2Fsource_en%2Ffirst_understanding%2Fbasic.html https://cangjie-lang.cn/en/docs?url=%2F1.0.0%2Fuser_manual%2...
• cosmic_cheese 1mo ago
  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.
  • yoyohello13 1mo ago
    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.
    • 0cf8612b2e1e 1mo ago
      On the other hand, there are some bad Go standard libraries that are frozen in time.
      • rirze 1mo ago
        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...)
        • lesuorac 1mo ago
• hbbio 1mo ago
  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.
  • dwroberts 1mo ago
    My experience has been that it has a major advantage, in that freeze + offline actually work properly. You can collect the dependencies you need once, put them in version control and never ever talk to remote registry again
    • LtWorf 1mo ago
      You mean leave all CVEs open?
      • dwroberts 1mo ago
        I guess that’s more of a problem if you use all-encompassing frameworks, but normally the things I’m using are very small components where the CVEs either don’t exist or are inconsequential/unexploitable for the programs I’m building
        • LtWorf 1mo ago
          So you don't track them, have no way of tracking them and just hope for the best. I hope no customer of yours asks for an SBOM :D
          • dwroberts 1mo ago
            Updating every dependency for every kind of CVE is a brute force method for people and organisations that don’t understand the attack surface of the programs they’re producing
• aselimov3 1mo ago
  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-managers-are-evil/ https://www.gingerbill.org/article/2025/09/08/package-manage...
  • Ygg2 1mo ago
    Honestly, Ginger Bill is plain wrong. Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.
    • beanjuiceII 1mo ago
      yep which people have already done in odin
    • aselimov3 1mo ago
      Well I think the main important argument here is you shouldn't use the package management. A third party package manager would be even more concerning to use imo. I generally try to stay away from the typescript world so unfamiliar with nuances of NPM.
      • Ygg2 1mo ago
        Sure. And people shouldn't steal people's credentials and publish malicious artifacts, yet here we are. Just because you expect people to behave like X doesn't mean they will. In this case people will automate packaging of artifacts. NPM was a third party manager (it's not part of EcmaScript nor was it part of Node.js at start) and so is Maven. Reputation matters more than origin. Those who do not know history are doomed to rediscover it.
  • jooops1 1mo ago
    The author proposes to reinvent the wheel and depend on stale dependencies, which are EOL. Neither of that is an acceptable solution with LLM-based Agents being able to produce exploit(ExploitGym) chains in minutes from known bugs. The other issue is that Rust's forces the user to provide more information and APIs are usually kept generic for systems programmer, so standardizing things is not as straight-forward compared to Go where you can assume a memory-management, a virtual thread runtime and mostly ignore dynamic dispatching.
• cube00 1mo ago
  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.com/droundy/arrayref https://web.archive.org/web/20260820145918/https://github.co... [2]: https://crates.io/crates/arrayref/versions https://crates.io/crates/arrayref/versions [3]: https://crates.io/crates/arrayref/security 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/crates/arrayref/security https://web.archive.org/web/20260820150747/https://crates.io...) [4]: https://github.com/rustsec/advisory-db/issues/3161#issuecomment-5354024485 https://github.com/rustsec/advisory-db/issues/3161#issuecomm...
  • qwertox 1mo ago
    > GitHub really needs something finer-grain then just pretending the repo never existed during these incidents. Google should read this too. They simply remove Android apps and Chrome extensions without a single word. No page explaining why they removed it, if i was at risk.
  • landr0id 1mo ago
    [3] is no longer true. They're definitely not unprepared for an incident like this. It's not the first time they've done it and they published an update to their process in Feb: https://blog.rust-lang.org/2026/02/13/crates.io-malicious-crate-update/ https://blog.rust-lang.org/2026/02/13/crates.io-malicious-cr... Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.
    • cube00 1mo ago
      > They're definitely not unprepared for an incident like this. We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised. `cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit` > Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill. The GitHub issue was opened 8 hours ago. The cargo.io team also acknowledged it 8 hours ago. [2] > [3] is no longer true. Previously published versions shouldn't just disappear from the list. There's still nothing there to indicate a version was yanked. [1]: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/#what-you-need-to-do https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... [2]: https://rust-lang.zulipchat.com/#narrow/channel/318791-t-crates-io/topic/arrayref.20hacked/near/617626315 https://rust-lang.zulipchat.com/#narrow/channel/318791-t-cra...
• dematz 1mo ago
  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 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.
• acje 1mo ago
  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_attack/ https://acje.github.io/systems/watching_a_supply_chain_attac...
• naniel 1mo ago
  [dead]
• never_inline 1mo ago
  I am surprised this took so long.
• hsaliak 1mo ago
  At least it’s safe
• kunalsin9h 1mo ago
  damn!
• FartyMcFarter 1mo ago
  This is quite the egg on the face, given that Rust proponents keep telling us how it's great for writing secure software.
• hoppp 1mo ago
  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.
  • leecommamichael 1mo ago
    Here's a suggestion, do you think it could be this simple? If you write a package-manager, don't execute any of the downloaded code in an automated fashion. No hooks, no build-time metaprograms. If your language _needs_ metaprogramming to function, it's a huge secondary issue that I don't know how to solve. You can try to make a meta-program annotation which disables side-effects, but the metaprogram ultimately must write memory which expands the amount of code generated. All risk is introduced when the person downloading cannot preview the content in a safe place.
    • zarzavat 1mo ago
      Unfortunately it doesn't solve the problem because malicious code can still end up compiled into the user's program which they will promptly execute, possibly in production... Supply chain attacks are not a problem that can be solved by a single silver bullet, however the biggest benefit comes from a combination of minimum release age + fresh 2FA required for every publish + automated scanning. This makes it considerably more difficult to pull off a supply chain attack and should be the baseline security for all package managers.
    • jaen 1mo ago
      The only safe solution is to review all the code's changes (or trust someone else to do it). Forbidding compile/build-time shenaningans is trivially bypassable and has already been bypassed in the NPM ecosystem by just making the library code itself (not the build scripts) malicious - eg. do the bad thing when the code is loaded/tested, assuming the language has static constructors.
• deleted 1mo ago
  [deleted]
• xdavidliu 1mo ago
  > 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.
• killme2008 1mo ago
  We really need Cargo RFC #3923 https://github.com/rust-lang/rfcs/pull/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.
  • killme2008 1mo ago
    It's a pity that progress has been so slow. https://github.com/rust-lang/cargo/issues/17009 https://github.com/rust-lang/cargo/issues/17009
• tyrchen 1mo ago
  When several supply-chain attacks hit the npm ecosystem a few months ago, I built SBE: https://github.com/tyrchen/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.
• colingauvin 1mo ago
  I hate cargo and npm. Why do we keep settling on arbitrary code execution in our build process?
• cjg007 1mo ago
  [flagged]
• somerandomness 1mo ago
  wow, what did payload do?
• fwlr 1mo ago
  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.
  • nottorp 1mo ago
    Eh, just because the likes of Anthropic are only threatening you with their latest model, it doesn't mean older models can't do exploits...
• frdev1786855380 1mo ago
  [flagged]
• wowczarek 1mo ago
  Nothing to do with Rust as a programming language, but meanwhile in the world of [language without a package manager], a monkey puppet glances awkwardly to the left.
• ammarabouzor 1mo ago
  I think we'll see more investment in scanning changes (with static code analysis tools and AI) before publishing on package registries like crates.io.
• Animats 1mo ago
  At build time - ouch. Nothing in the output code shows a problem, so the usual threat scanners won't see it.
• myshapeprotocol 1mo ago
  [dead]
• ggamezar 1mo ago
  Safe rust might not be that safe due its package manager?
• olejorgenb 1mo ago
  cargo_min_publish_age RFC: https://rust-lang.github.io/rfcs//3923-cargo-min-publish-age.html https://rust-lang.github.io/rfcs//3923-cargo-min-publish-age...
• germandiago 1mo ago
  This is becoming so common in package managers. I usuaally pik and compile my dependencies in Conan and store them in my own repo for the case of C++.
• decentstates 1mo ago
  This is an developer environment worm, the problem is the terminal has no data-isolation. Your development tools should not be able to access your keys. I have built a model for providing data-isolation on nixos: https://decentstat.es/posts/shai-halud-nix-housing/ https://decentstat.es/posts/shai-halud-nix-housing/ (non vibecoded)
• willtemperley 1mo ago
  Surely non-sandboxed build scripts are just a terrible idea. Both Cargo and npm should look at what Swift Package Manager (SPM) is doing. It’s not perfect but there’s a noticeable absence of supply chain attacks involving SPM, probably partly because it doesn’t use a mutable registry, but I suspect attacks are just more difficult. On the rare occasion a build script is involved it’s run in a sandboxed plugin.
  • wronex 1mo ago
    Why would a malicious library author limit their maliciousness to the build script?
    • deleted 1mo ago
      [deleted]
    • willtemperley 1mo ago
      They wouldn't, but build scripts are a particularly effective attack vector.
    • 0rzech 1mo ago
      They won't, but the less attack vectors, the better.
• waterTanuki 1mo ago
  > append-only-vec > This is a pretty simple type, which is a vector that you can push into, but cannot modify the elements of. The data structure never moves an element once allocated, so you can push to the vec even while holding references to elements that have already been pushed. This is the left-pad of rust. Reconsider your life decisions if you need to pull in an external dependency replicable with 30 lines of code: use std::vec::Vec; #[derive(Debug)] pub struct AppendOnlyVec<T> { inner: Vec<T>, } impl<T> AppendOnlyVec<T> { pub fn new() -> Self { Self { inner: vec![], } } pub fn push(&mut self, element: T) { self.inner.push(element); } pub fn clear(&mut self) { self.inner.clear(); } }
  • speedstyle 1mo ago
    > The data structure never moves an element once allocated Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.
    • waterTanuki 1mo ago
      > Yours will reallocate every so often, invalidating element references. append_only_vec requires only &self to push, Then the crate is lying about its intentions or performing black magic using RefCell under the hood to go behind the user's back. A vec is a vec. If I don't want re-allocations I will use .with_capacity() and cap it or use a plain array. Also the data has to be changed somewhere to happen, and I'd rather the API be honest and give me &mut self than lie and say &self.
      • speedstyle 1mo ago
        The point of the crate, the readme you quoted, is > you can push to the vec even while holding references to elements that have already been pushed. Expressing this in Rust (without leaking references to a dropped container) means taking &self. It's true that the container struct itself (chunk pointers, len) is mutated, but the compiler has no distinction between this and the pointee data, so you use ..Cell. It does allocate, there's no capacity limit, but it guarantees stable pointers to existing items.
• mitrii 1mo ago
  [flagged]
• copperwire 1mo ago
  Shipping real proc-macro2 source inside the typosquat so builds keep working is devious. Most people would never notice a transitive dependency changing names slightly.
• pjjpo 1mo ago
  I recently found a rust library that downloads and runs Bazel transparently. Lost a lot of faith in the safety of the Rust ecosystem...
• somarugaberthol 1mo ago
  But I was told this was an uniquely non-specific thing and that Cargo was so much better at this?
• robertJk 1mo ago
  ok
• a022311 1mo ago
  > The requirement `1.0.107` is a caret range, and with only `1.0.106` and `1.0.107` ever published it resolves to the malicious `1.0.107`. Uhh no it isn't? This seems to be a pretty low quality article
• anonyfloss 1mo ago
  I have learnt that, when I account for time spent auditing dependencies, writing my own implementations becomes quite attractive