Shai-Hulud Returns: Over 300 NPM Packages Infected • Hacker News Board

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

#601

Post by nickserv » Mon, Nov 24, 2025, 7:06 PM UTC

ryandrake wrote: post #388

tim1994 wrote: post #371

Earlier quoted context omitted.

Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.

> Because updates don't just include new features but also bug and security fixes. This practice needs to change, although it will be almost impossible to get a whole ecosystem to adopt. You shouldn’t have to take new features (and associated new problems) just to get bug fixes and security updates. They should be offered in parallel. We need to get comfortable again with parallel maintenance branches for each major…

I maintain both commercial and open source libs. This is a non starter in both cases. It would easily double if not triple the workload.

For open source, well these are volunteer projects on my own time, you are always welcome to fork a given version and backport any fixes that land on main/master.

For commercial libs, our users are not willing to pay extra for this service, so we don't provide it. They would rather stay on an old version and update the entire code base at given intervals. Even when we do release patch versions, there is surprisingly little uptake.

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

#602

Post by vedhant » Mon, Nov 24, 2025, 7:16 PM UTC

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

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

#603

Post by throwaway1389z » Mon, Nov 24, 2025, 7:16 PM UTC

What is going on with this website though? It gives cursor stutter and slow scrolling. It seems like we now need an insane amount of CPU to read static text. What a regression.

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

#604

Post by vedhant » Mon, Nov 24, 2025, 7:18 PM UTC

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

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

#605

Post by dzonga » Mon, Nov 24, 2025, 7:18 PM UTC

twistedpair wrote: post #469

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…

pnpm on the backend, frontend use nobuild.

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

#606

Post by lesuorac » Mon, Nov 24, 2025, 7:19 PM UTC

vedhant wrote: post #602

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

To me this is asking the question of "what's the safest way to drink from a polluted river".

The answer is really, don't.

NPM and the JS eco-system has really gone down a path of zero security and they're paying the price for it.

If you really need libraries from NPM and whatnot, vendorize them so you're relying on known-safe files and don't arbitrarily update them without re-verification.

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

#607

Post by mfro » Mon, Nov 24, 2025, 7:21 PM UTC

ashishb wrote: post #595

mfro wrote: post #594

Earlier quoted context omitted.

Good question with a lot of possible answers. You can take sandboxing as far as you want, really. I typically just use bubblewrap (linux)

I have a perfect set up in inside docker that works. I would love to know why bubblewrap is a superior alternative. Here's mine https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849...

My understanding is that docker escapes are not all that difficult, and your aliases really aren’t doing much to harden the container. but I am not an expert on the matter. I’m sure there is plenty of info online

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

#608

Post by vedhant » Mon, Nov 24, 2025, 7:22 PM UTC

lesuorac wrote: post #606

vedhant wrote: post #602

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

To me this is asking the question of "what's the safest way to drink from a polluted river". The answer is really, don't. NPM and the JS eco-system has really gone down a path of zero security and they're paying the price for it. If you really need libraries from NPM and whatnot, vendorize them so you're relying on known-safe files and don't arbitrarily update them without re-verification.

This is true. Today its npm, tomorrow it could be some other language. Shouldnt we focus on solving it at the root?

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

#609

Post by Aperocky » Mon, Nov 24, 2025, 7:22 PM UTC

vedhant wrote: post #604

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

To not use npm. Or create a package manager like npm. Or believe in philosophy that we should have as many small dependencies as possible.

If you must use npm, containerize/VM it? treat it as if you're observing malware.

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

#610

Post by silverlight » Mon, Nov 24, 2025, 7:24 PM UTC

timgl wrote: post #510

silverlight wrote: post #397

Earlier quoted context omitted.

Did the client side JS being infected produce any issues which would have affected end users? As in if a web owner were on an affected version and deployed during the window would the end user of their site have had any negative impact?

No, just the host that was running the package (the exploit was pretty generic and not targeted at PostHog specifically). In fact, so far we think there were 0 production deployments of PostHog because the package was only live for a little bit.

Glad to hear the impact was so muted. Thank you for the response!