Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

221–230 of 797 posts

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

#221
post #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.

There are companies like Helix Guard scanning registries. They advertise static analysis / LLM analysis, but honeypot instances can also install packages & detect certain files like cloud configs being accessed

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

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

Using C++ daily, whenever I do js/ts are some javascript variant, since I don't use it daily, and update becomes a very complex task. frameworks and deps change APIs very frequently.

It's also very confusing (and I think those attack vectors benefit exactly from that), since you have a dependency but the dep itself dependent on another dep version.

Building basic CapacitorJS / Svelte app as an example, results many deps.

It might be a newbie question, but, Is there any solution or workflow where you don't end up with this dependency hell?

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

#224

Does NPM use any automatic scanners? Just scanning for eval/new Function/base64 and other tokens often used by malware, and requiring a manual review, could already help. Also package manager should not run scripts.

Static scanning won't help. You can write this["eval"]() instead of eval(), therefore you can write this["e" + "v" + "a" + "l"](), and you can substitute (!![]+[])[!+[]+!+[]+!+[]] for "e", (![]+[])[+!+[]] for "a" (and so on: https://jsfuck.com/)

In this Turing-equivalent world, you can only know what actually executes (e.g. eval, fetch) by actually executing all code in the package and then see what functions got executed. Then the problem is the same as virus analysis; the virus can be written to only act under certain conditions, it will probe (e.g. look at what intepreter fingerprints, get the time of day, try to look at innocuous places in filesystem or network, measure network connection times, etc), so that it can determine it is in a VM being scanned, and go dormant for that time.

So the only thing that actually works is if node and other JS evaluators have a perfect sandbox, where nothing in a module is allowed (no network, no filesystem) except to explicit locations declared in the module's manifest, and this is perfectly tracked by the language, so if the module hands back a function for some other code to run, that function doesn't inherit the other code's network/fs access permissions. This means that, if a location is not declared, the code can't get to it at scanning time nor install time nor any time in the future.

This still leaves open the door for things like a module defining GetGoogleAnalyticsURL(params) that occasionally returns "https://badsite.com/copyandredirect?ga=...", to get some other module to eventually make a credential-exfiltrating network call, even if it's banned from making it directly or indirectly...

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

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

This is a reason why so many enterprises use C#. Most of the time you just use Microsoft made libraries and rarely brings in 3rd party.

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

#226
post #173

Earlier quoted context omitted.

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 ha…

Would you consider your use cases typical for the average Node.js ecosystem denizen?

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

#227

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…

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.

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

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

My code editor works in a sandbox. It's difficult because Linux doesn't provide it and one has to write it manually using shell scripts, random utilities. For example, I had also to write a limited FUSE emulation of /proc to allow code editor work without access to real /proc which contains lot of unnecessary information. And if it's a "professional" setting, the company could hire a part-time developer for writing t…

Good luck selling that to thousands of managers. That's my point. It's easy to list things that should be done. It's harder to get them greenlit.

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

#229

Earlier quoted context omitted.

Sorry, but that had me laughing out loud. No, they haven't. I should know, I check those companies for a living. This is one of the most often flagged issues: unaudited Node.js dependencies. "Oh but we don't have the manpower to do that, think about how much code that is".

When I last looked (as a consulting dev in a bank or three, horrified) absolutely they had not!

If this was in the US, all financial institutions need to audit their code to comply with NIST SP 800-53.

If they haven’t, it would be ethically dubious for you to not report it.

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

#230
post #198

Earlier quoted context omitted.

C standard library is also very small. The issue is not the standard library. The issue is adding libraries for snippets of code, and in the name of convenience, let those libraries run code on the dev machine.

The issue is that our machines run 1970s OSes with a very basic security model, and are themselves so complex that they’re likely loaded with local privilege escalation attack vectors. Doing dev in a VM can help, but isn’t totally foolproof.

It’s a good security model because everyone has the decency to follow a pull model. Like “hey, I have this thing, you can get it if you’re interested”. You decide the amount of trust you give to someone.

But NPM is more like “you’ve added me to your contact list, then it’s totally fine for me to enter your bedroom at night and wear your lingerie because we’re already BFF”. It’s “I’m doing whatever I want on your computer because I know best and you’re dumb” mentality that is very prevalent.

It’s like how zed (the editor) wants to install node.js and whatever just because they want to enable LSP. The sensible approach would have been to have a default config that relies on $PATH to find the language server.

Post reply on HN