Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

51–60 of 797 posts

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

#51
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…

There are ecosystems that have package managers but also well developed first party packages.

In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.

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

#52
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…

Node is the embodiment of move and break things. Probably will not build anything that should last more than a few months on node.

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

#53

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…

> Serious question: should someone develop new technologies using Node any more? Please, no. It is an absolutely terrible eco system. The layercake of dependencies is just insane.

Node the technology can be used without blindly relying on the update features of npm. Vet your dependency trees, lock your dependency versions at patch level and use dependency cooldown.

This is something you also need to do with package managers in other languages, mind you.

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

#54

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...

But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.

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

#55

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...

I don't buy this line of reasoning. There are zero/one day vulnerabilities that will get extra time to spread. Also, if everyone switches to the same cooldown, wouldn't this just postpone the discovery of future Shai-Huluds?

I guess the latter point depends on how are Shai-Huluds detected. If they are discovered by downstreams of libraries, or worse users, then it will do nothing.

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

#56
post #16

Very concerning, so that was what the "impending disaster" was as I first noted. [0] Quite worrying that this happened again to the NPM ecosystem. Really looking forward to a deeper post-mortem on this. [0] https://news.ycombinator.com/item?id=46031864

It will keep happening until someone takes responsibility and starts maintaining the whole of the node eco system. This is probably a viable start-up idea: Node but audited.

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

#57

Could npm adopt a reverse domain naming system similar to Java's for Maven libraries? com.foo.bar That would require domain verification, but it would add significant developer friction. Also mandatory Dune reference: "Bless the maker and his water"

I don't see how this solves the problem?

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

#58
post #41

Earlier quoted context omitted.

The packages were published using a compromised key directly, not through our ci/cd. We rolled the key, and published a new clean version from our repo through our CI/CD: https://github.com/PostHog/posthog-js/actions/runs/196303581...

Why do you keep using token auth? This is unacceptable negligence these days. NPM supports GitHub workflow OIDC and you can make that required, disabling all token access.

Yep, we are moving to workflow OIDC as the next step in recovery.

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

#59

Earlier quoted context omitted.

The concern is not 'could' happen, but _does_ happen. I know this could occur in many places. But where it seems highly prevalent is NPM. And I am genuinely thinking to myself, is this making using npm a risk?

Just use dependency cooldown. It will mitigate a lot of risk.

If you started your Node project yesterday, wouldn't that mean you'd get the fix later?

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

#60

Earlier quoted context omitted.

If they have a HTTP API using standard authentication methods it's not that difficult to create a simple wrapper. Granted a bit more work if you want to do things like input/output validation too, but there's a trade-off between ownership there and avoiding these kinds of supply-chain attacks.

> Granted a bit more work if you want to do things like input/output validation too, A bit? A proper input validator is a lot of work.

If you aim for 100% coverage of the API you're integrating with, sure. But for most applications you're going to only be touching a small surface area, so you can validate paths you know you'll hit. Most of the time you probably don't need 100% parity, you need Just Enough for your use-case.
Post reply on HN