Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

171–180 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#171
post #65

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens ­— https://itnext.io/no-way-to-prevent-this-says-only-developme... >

> Says Only Development Community Where This Regularly Happens We've had such issues on other places as well... Shai-Hulud got into Maven [1] and PHP Composer [2], typosquatters got into Maven [3], and it's not new either [4]. No one is safe from skiddies, much less from nation state actors. [1] https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spr... [2] https://semgrep.dev/blog/2026/malicious-intercom-php-pa…

Your example of security issues in Maven is... npm guys setting up processes to auto-publish infected npm packages into the Maven Central repository?

Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#174

> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages. I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library. 0 - https://docs.deno.com/runti…

Worth noting that nowadays nodejs std lib keeps growing and includes the aforementioned assertion and testing support.

https://nodejs.org/api/

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#175
post #165
post #164

Earlier quoted context omitted.

What about language exclusivity makes a package manager a security nightmare?

Now I have to wonder if someone is targeting Homebrew too, thanks

That isn't a language exclusive package manager. I mean things like npm and pip. It isn't necessarily that they're language exclusive, it's that they all tend to have features that aren't good security wise because they aid in developing in that language

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#176

Earlier quoted context omitted.

Yeah funny, but npm is not the only development community where this regularly happens. The Onion article this joke refers to [1] is funny because there is a very clear and obvious reason why the U.S. has far more gun deaths per capita. This doesn't apply for npm. [1] https://theonion.com/no-way-to-prevent-this-says-only-nation...

Oh? Edit: please explain. What other community has this rate of attacks? It's possible they are just detected or publicized less, too. Please help me understand what you're referring to.

I'd also like to know who monitors the casualties.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#177
post #163

What would be the required budget to host an alternative registry? I'm surprised any GAFAM still hasn't stepped-in and started building their alternative, at least for NPM to up its game in order not to become completely irrelevant.

at amazon, they maintain a private internal registry of packages with approved licenses and audits. this has been in place for several years. i assume other big corps enforce similar policies

Do you know if they are using any product like JFrog for this or rolling their own?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#178

> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages. I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library. 0 - https://docs.deno.com/runti…

To be fair, Node has `node:test` [0] and `node:assert/strict` [1] modules out of the box for several LTS versions now. `node --test` can easily replace Mocha and `node:assert/strict` is fine, but `chai` is still sometimes nicer (include ergonomics like `expect`). (Deno's @std includes an `expect` style assertion library.)

Of course, the trouble is that there are so many test runners in the Node ecosystem and many of them cannot be as easily replaced as Mocha, so the shift to the out-of-the-box test harness and assertion library will of course be painfully slow. People like the over-complicated nature of both Jest and Vitest for all sorts of reasons. Major companies thought Karma was a good idea. (I still don't understand why more developers didn't cringe at "Yo dog, I heard you like V8 for your unit tests, so we're gonna spin up a second, different copy of V8 from your existing V8 environment.")

[0] https://nodejs.org/api/test.html

[1] https://nodejs.org/api/assert.html#strict-assertion-mode

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#179
post #106
post #91

I can't wait for npm/github to do literally anything at all to mitigate these attacks. Literally anything. Have we considered a basic WAF-style block on some postinstall script strings? LLM-assisted code scanning on publish? Is there anyone home? No I suspect not.

Third parties can detect compromised packages. It’s ridiculous Microsoft doesn’t.

They will once they figure out how to charge for it (which GitHub is trying according to the security scanning banner they keep showing me).

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#180
post #171

Earlier quoted context omitted.

> Says Only Development Community Where This Regularly Happens We've had such issues on other places as well... Shai-Hulud got into Maven [1] and PHP Composer [2], typosquatters got into Maven [3], and it's not new either [4]. No one is safe from skiddies, much less from nation state actors. [1] https://thehackernews.com/2025/11/shai-hulud-v2-campaign-spr... [2] https://semgrep.dev/blog/2026/malicious-intercom-php-pa…

Your example of security issues in Maven is... npm guys setting up processes to auto-publish infected npm packages into the Maven Central repository? Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.

> Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.

RCE-on-build/upgrade can be done in Maven if you manage to compromise one of the major Maven plugins, they run at build time. The thing keeping maven safe for now is that most people pin the plugin and dependency versions, with the obvious side effect that it's truly annoying to get all your dependencies updated.

Post reply on HN