Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

391–400 of 797 posts

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

#391

Post by wavemode »

Ygg2 wrote: post #55
darkamaul wrote: post #26

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.

Your line of reasoning only makes sense if literally almost all developers in the world adopt cooldowns, and adopt the same cooldown.

That would be a level of mass participation yet unseen by mankind (in anything, much less something as subjective as software development). I think we're fine.

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

#392

Post by hedora »

rglover wrote: post #313

This is a good sign that it's time to get packages off of NPM and come up with an alternative. For those who haven't heard of or tried Verdaccio [1], it may be an option. Relatively easy to point at your own server via NPM once you set it up. [1] https://verdaccio.org/

I've had decent luck running it locally, but claude keeps screwing up the cool-down settings in my monorepo.

This is probably a common problem. Has anyone gotten verdaccio to enforce cool-down policies?

I also waste a ton of time because post-install scripts are disabled. Being able to cut them off from network access, and just run a local server with 2-4 week cool-down would help me sleep better at night + simplify the hell out of my build.

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

#393

Post by atherton94027 »

wongarsu wrote: post #100
TheFlyingFish wrote: post #70

Earlier quoted context omitted.

I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the si…

I wouldn't call the Rust stdlib "small". "Limited" I could agree with. On the topics it does cover, Rust's stdlib offers a lot . At least on the same level as Python, at times surpassing it. But because the stdlib isn't versioned it stays away from everything that isn't considered "settled", especially in matters where the best interface isn't clear yet. So no http library, no date handling, no helpers for writing ma…

> On the topics it does cover, Rust's stdlib offers a lot. At least on the same level as Python, at times surpassing it.

Curious, do you have specific examples of that?

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

#394

Post by euph0ria »

bilalq wrote: post #278
timgl wrote: post #4

co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were: - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest versio…

You're probably already planning this, but please setup an alarm to fire off if a new package release is published that is not correlated with a CI/CD run.

Very nice way of putting it, kudos!

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

#395

Post by auxiliarymoose »

afdbcreid wrote: post #348
TheFlyingFish wrote: post #316

Earlier quoted context omitted.

Requests is a great example of my point, actually. Creating a brand-new Python venv and running `uv add requests` tells me that a total of 5 packages were added. By contrast, creating a new Rust project and running `cargo add reqwest` (which is morally equivalent to Python's `requests`) results in adding 160 packages, literally 30x as many. I don't think languages should try to include _everything_ in their stdlib, a…

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

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

#396

Post by mx7zysuj4xew »

TheFlyingFish wrote: post #70
sph wrote: post #7

Earlier quoted context omitted.

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…

I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the si…

It won't, it's a culture issue

Most rust programmers are mediocre at best and really need the memory safety training wheels that rust provides. Years of nodejs mindrot has somehow made pulling into random dependencies irregular release schedules to become the norm for these people. They'll just shrug it off come up with some "security initiative* and continue the madness

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

#397

Post by silverlight »

timgl wrote: post #4

co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were: - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest versio…

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?

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

#398

Post by joshstrange »

Yokohiii wrote: post #390
joshstrange wrote: post #362

Earlier quoted context omitted.

> Version locking wont help you all the time, i.e. if you build fresh envs from scratch. I'm confused on this. I would imagine it would protect/help you as long as releases are immutable which they are for most package managers (like npm). > Vendoring literally just means grabbing the source code from origin and commit it to your repo after a review. Hmm, I don't think it always necessarily means grabbing the source,…

You are right about version locking, bullshit on my side, not sure what I was thinking. I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy.

> I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy.

Fair, in the instances I ran into it was code that was downloaded and unzipped into a "js-library-name" folder but then the code was edited, even worse, the `.min.js` version wasn't touched, just the original one which led to some fun when someone "helpfully" switched to the min versions that didn't have the edit. IMHO, if you want to edit a library then you should be forking and/or making it super obvious that this is not "stock" library X. We also ran into issues with "just updated library Y" and only later realizing someone had modified the older version.

But yes, if it's deliberate and obvious then I don't have an issue modifying, just as long as the team understands it's "their" code now and there is no clean upgrade path in the future.

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

#399

Post by geodel »

TheDong wrote: post #304
galangalalgol wrote: post #227

Earlier quoted context omitted.

Network without async works fine in std. However, rand, serde, and num_traits always seem to be present. Not sure why clap isn't std at this point.

> Not sure why clap isn't std at this point. The std has stability promises, so it's prudent to not add things prematurely. Go has the official "flag" package as part of the stdlib, and it's so absolutely terrible that everyone uses pflag, cobra, or urfave/cli instead. Go's stdlib is a wonderful example of why you shouldn't add things willy-nilly to the stdlib since it's full of weird warts and things you simply shou…

> and it's so absolutely terrible that everyone uses pflag, ../

This is just social media speak for inconvenient in some cases. I have used flag package in lot of applications. It gets job done and I have had no problem with it.

> since it's full of weird warts and things you simply shouldn't use.

The only software that does not have problem is thats not written yet. This is the standard one should follow then.

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

#400

Post by jonfw »

plomme wrote: post #346
darkamaul wrote: post #26

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.

There is a Goldilocks effect. Dependency just came out a few minutes ago? There is no time for the community to catch the vulnerability, no real coverage from dependency scans, and it's a risk. Dependency came out a few months ago? It likely has a large number of known vulns
Post reply on HN