Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

551–560 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#551
post #346

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

CI fights this. But that’s peanuts compared to feature branches and nothing compared to lack of a monolith.

We had so many distinct packages on my last project that I had to massively upgrade a tool a coworker started to track the dependency tree so people stopped being afraid of the release process.

I could not think of any way to make lock files not be the absolute worst thing about our entire dev and release process, so the handful of deployables had a lockfile each that was only utilized to do hotfix releases without changing the dep tree out from underneath us. Artifactory helps only a little here.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#552

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

What does it do with packages that download binaries for specific architecture in the post script?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#553
post #7

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

Agreed, rust's cargo model is basically the worst part of that ecosystem right now. I've had developers submit pretty simple cli tools with hundreds and hundreds of dependencies. I guess there wasn't any lessons learned from the state of NPM.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#554
post #193

Earlier quoted context omitted.

That's the goal, but it's not feasible in e.g. professional settings. Much easier said than done, unfortunately.

Sure it is: don't do it. It's not like there isn't automated tooling for this, but you can also like... I don't know, look at your diffs and not commit secrets? I've never committed a secret before, and I've been working with AWS for ten years now. But I don't "git commit -a" and I triple-check my diffs.

Shai Hulud isn't about accidentally committing secrets, nobody is suggesting that's what's happening. Not sure which comment thread you're reading.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#555

Earlier quoted context omitted.

That's not an apple-to-apple comparison, since Rust is a low-level language, and also because `reqwest` builds on top of `tokio`, an async runtime, and `hyper`, which is also a HTTP server, not just a HTTP client. If you check `ureq`, a synchronous HTTP client, it only adds 43 packages. Still more, but much less.

And in Go I can build a production-ready HTTPS (not just HTTP) server with just the standard library and a few lines of code. (0 packages). That Rust does not have standard implementations of commonly-used features (such as an async runtime) is problematic for supply chain security, since then everyone is pulling in dozens (or hundreds) of fragmented 3rd-party packages instead of working with a bulletproof standard l…

And this is exactly why Go is winning: because it's actually rather easy to write "pure Go" utilities (no dependencies outside the standard library), which statically compile to boot (avoiding shared libraries).

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#557
> bun_environment.js is a highly obfuscated malicious JavaScript file. It is over 10MB in size and contains a significant amount of built-in logic for information theft.

That seems a bit silly. Even on the beefy boi I used to work on a 10MB hiccup in deployable size would have been sufficient to make me look.

I released one of the packages I work on last night so of course this drew my eye. I assume checking the unpacked size hasn’t gotten ridiculous confirms that your code is not infected yeah? And looks like it’s past time for me to set up a separate account for release management.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#558

Perhaps it's time to organize a curated "stable" stream for npm packages. If I want more stability for my OS I can choose Debian-stable rather than Ubuntu-nightly. But for npm, there doesn't seem to be the same choice available. Either I sign up to the fire-hose or I don't. I can choose to only upgrade once a month, but there's a chance I'm still getting a package that dropped 5 minutes before.

Upgrading once a month is insane at any rate, I could see the point in upgrading maybe once a year. For stable projects, you're very much fine upgrading only when there's a vulnerability or you need something from a newer release. Upgrade when you actually need to and use stable versions that have been out for a while, no need to hamster wheel it.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#559
post #547

And this, kids, is why you should vendor your dependencies

Vendoring wouldn't really affect this at all. If anything it would keep you vulnerable for longer because your vendored copy keeps "working" after the bad package got removed upstream. There's a tiny chance that somebody would've caught the 10MB file added in review but that's already too late - the exploit happened on download, before the vendored copy got sent for review.

But you would have code reviewed it

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#560
post #543

Earlier quoted context omitted.

> NPM is too insecure for production CLI usage. NPM was never "too insecure" and remains not "too insecure" today. This is not an issue with npm, JavaScript, NodeJS, the NodeJS foundation or anything else but the consumer of these libraries pulling in code from 3rd parties and pushing it to production environments without a single review. How this still fly today, and have been since the inception of public "easy to…

They didn't deploy the code. That's not how this exploit works. They _downloaded_ the code to their machine. And npm's behavior is to implicitly run arbitrary code as part of the download - including, in this case, a script to harvest credentials and propagate the worm. That part has everything to do with npm behavior and nothing to do with how much anybody reviewed 3P deps. For all we know they downloaded the new ve…

Thank you.
Post reply on HN