Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

171–180 of 797 posts

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

#171

Earlier quoted context omitted.

We chose to write our platform for product security analytics (1) with PHP, primarily because it still allows us to create a platform without bringing in over 100 dependencies just to render one page. I know this is a controversial approach, but it still works well in our case. "require": { "php": ">=8.0", "ext-mbstring": "*", "bcosca/fatfree-core": "3.9.1", "phpmailer/phpmailer": "6.9.3", "ruler/ruler": "0.4.0", "ma…

Ah yes PHP, the language known for its strong security...

Oh yes, let's remember PHP 4.3 and all the nostalgic baggage from that era.

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

#172

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

Okay then, tell me a way to prevent this.

An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series", as is the de-facto standard in NPM dependencies. Therefore, it's up to each dependency-user to validate newer versions of dependencies before publishing a new version of their own package. Lots of manual attention needed, so a slower pace of releases. This is a good thing!

Another example: all Debian packages are published to unstable, but cannot enter testing for at least 2-10 days, and also have to meet a slew of conditions, including that they can be and are built for all supported architectures, and that they don't cause themselves or anything else to become uninstallable. This allows for the most egregious bugs to be spotted before anyone not directly developing Debian starts using it.

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

#173

Earlier quoted context omitted.

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.

If everybody in your country drives on the right side of the road you could theoretically drive on the left. But you won't get very far like that. People use Node because of the availability of the packages, not the other way around.

> People use Node because of the availability of the packages, not the other way around.

That is not why I use Node. Incidentally, I also use Bun.js, and pnpm for most package management operations. I also use Typescript instead of raw JS.

I use Node and these related tools fundamentally because:

- I like the isomorphism of the code I write (same language for server and client)

- JS may have many warts, but IMO it has many advantages many other languages lack, it is rapidly improving, and TS makes it even more powerful and the bad part parts manageable. One ting that has stuck with me over the many years of using JS/TS is just how direct and free-of-ceremony everything is. Want a functional style? It supports it to some extent without much fuss. Want something akin to OOP? You can object literal with method-style function, "constructors" that are regular functions, even no-fuss prototypical inheritance, if you want to go that far. Also, no need for any complicated dependency injection (DI), you can just implement pure DI with regular functions, etc. I don't get why you hate JS/TS so much.

- I use Bun.js as an alternative to Node that has more batteries included, so that I can limit my exposure to too many external packages. I add packages only if I absolutely need them, and I audit them thoroughly. So, no, although I may use some packages, I am not on the Node ecosystem just because I want to go on a package consumption spree.

- I use pnpm for installing and managing package, and it by default prevents packages from taking any actions during installation; I just get their code.

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

#174

Is there a terminal AI assistant that doesn't have heaps of depenedancies and preferably no node? Claude and codex both require node. I'm a fan of the lightweight octofriend. But also node. I do not like installing node on systems that otherwise would not require it.

llama.cpp?

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

#175

I always (very naively, I fully get it) wonder if someone at GitHub could take a minute and check the logs (if there are any at this level) from a week ago or so and scan them for patterns? The code seems to grab a few files off of GitHub, use Github actions, etc. -- perhaps there's a pattern in there that shows the attacker experimenting and preparing for this? I assume most people at this level have VPNs and so for…

That's usually what those security companies do, they monitor all those repositories and look for patterns, then investigate anything suspicious.

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

#176

Earlier quoted context omitted.

The same way it always has been done - vendor your deps.

That literally makes no difference at all. You’ll just vendor the malicious versions. No, a lock file with only exact versions is the safe path here. We haven’t seen a compromise to existing versions that I know of, only patch/minor updates with new malicious code. I maintain that the flexibility in npm package versions is the main issue here.

You are using the word "vendoring" differently than i do, i mean some kind of private fork of the repository.

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

#177

Earlier quoted context omitted.

I feel like there are merits to your argument but that you have a larger anti-JS bias that's leaking through. Not that there aren't problems with Node itself, but as many people have pointed out, there are plenty of organizations writing in Node that aren't pwn'd by these sorts of attacks because we don't blindly update deps. Perfect is the enemy of good; dependency cooldown etc is enough to mitigate the majority of…

> I feel like there are merits to your argument but that you have a larger anti-JS bias that's leaking through. Familiarity breeds contempt.

The truth is typically somewhere in the middle. I feel you though. I'm that way with Ruby/Bundler.

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

#178
post #127

Earlier quoted context omitted.

That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. And what is wrong with writing your own util library that fits your use case anyway? In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. No one sane will add a third-party git submodule, wire it to the main Mak…

> That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here. Yeah, that's why I said that this is the other end of the pendulum. > In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. Oh I'm aware of that. My point still stands - that comes at a serious maintenance cost…

Wait what? That’s just fearmongering, how hard is it to add a few methods that split a string or pad it? It’s not rocket science.

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

#179
post #24

Earlier quoted context omitted.

Everyone needs to switch to pnpm and enable https://pnpm.io/settings#minimumreleaseage Pnpm also blocks preinstall scripts by default.

Nah - dependency cooldown is all the rage but it’s only effective if you have some noncompliant canary users. Once everyone is using it it will cease to be effective because nobody will be taking the first step/risk until everybody does.

The point of the cooldown is to allow time for vendor scans to complete and for compromised packages to be pulled. It's not about waiting for an end user to notice they've been compromised.

> Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI).

https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

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

#180
post #25

I guess you should never use the latest versions of libraries.

But you also need the latest versions to avoid zero-day attacks.

99% of releases do NOT fix zero-days. But 100% of releases have a small risk of introducing a backdoored build-script.

There's nothing wrong with pinning dependencies and only updating when you know for sure they're fixing a zero-day (as it will be public at that point).

Post reply on HN