Live data from Hacker News

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

101–110 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#101
post #32

Earlier quoted context omitted.

as much as i can yes. I try to avoid JS, as it is a horrible language, by design. That does include TS, but it at least is useable, but barely - because it still tied to JS itself.

out of sincere curiosity, which one is a great programming language to you?

depends on use case, i don't think one language can fit all cases. 100% correctness is required for systems, but it is a hindrance in non-critical systems. or robust type systems require high compilation times which hurt iterating on the codebase.

systems? rust - but it is still far from perfect, too much focus on saving few keystrokes here and there.

general purpose corporate development? c# - despite current direction post .net 5 of stapling together legacy parts of .net framework to .net core. it does most things good enough.

scripting, and just scripting? python.

web? there's only one, bad, option and that's js/ts.

most hated ones are in order: js, go, c++, python.

go is extremely infuriating, there was a submission on HN that perfectly encapsulated my feelings about it, after writing it for a while: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#102

post-install seems like it shouldn't be necessary anyway, let alone need shell access. What are legitimate JS packages using this for?

Does that even matter?

The malware could have been a JS code injected into the module entry point itself. As soon as you execute something that imports the package (which, you did install for a reason) the code can run.

I don't think that many people sandbox their development environments.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#103

Earlier quoted context omitted.

Until you go get malware Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code. What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This h…

> Until you go get malware While technically true, I have yet to see Go projects importing thousands of dependencies. They may certainly exist, but are absolutely not the rule. JS projects, however... We have to realize, that while supply chain attacks can happen everywhere, the best mitigations are development culture and solid standard library - looking at you, cargo. I am a JS developer by trade and I think that t…

Here's an example off the top of my mind:

https://github.com/go-gitea/gitea/blob/main/go.sum

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#104
post #93
post #76

Earlier quoted context omitted.

JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards. It is full of gotchas that serves 0 purpose nowadays. Also remember that it is basically a Lisp wearing Java skin on top, originally designed in less than 2 wee…

> JS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards. What some people see as a fault, others see as a feature :) For me, that's there to prevent entire websites from breaking because some small widget in the bot…

>it's there to prevent entire websites from breaking because some small widget in the bottom right corner breaks, for example.

the issue is that it prevents that, but also allows you to send complete corrupt data forward, that can create horrible cascade of errors down the pipeline - because other components made assumption about correctness of data passed to them.

Such display errors should be caught early in development, should be tested, and should never reach prod, instead of being swept under the rug - for anything else other than prototype.

but i agree - going fully functional with dynamic types beats average JS experience any day. It is just piling up more mud upon giant mudball,

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#106

Earlier quoted context omitted.

JavaScript does have some pretty insane dependency trees. Most other languages don’t have anywhere near that level of nestedness.

Don't they? I just went to crates.io and picked a random newly updated crate, which happened to be pixelfix, which fixes transparent pixels in pngs. It has six dependencies and hundreds of transient dependencies, may of which appear to be small and highly specific a la left-pad. https://crates.io/crates/pixelfix/0.1.1/dependencies Maybe this package isn't representative, but it feels pretty identical to the JS ecosys…

It depends on `image` which in turn depends on a number of crates to handle different file types. If you disable all `image` features, it only has like 5 dependencies left.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#107

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…

Could you say more about what mitigations you’re thinking of?

I ask because think the directionality is backwards here: I’ve been involved in packaging ecosystem security for the last few years, and I’m generally of the opinion that PyPI has been ahead of the curve on implementing mitigations. Specifically, I think widespread trusted publishing adoption would have made this attack less effective since there would be fewer credentials to steal, but npm only implemented trusted publishing recently[1]. Crates also implemented exactly this kind of self-scoping, self-expiring credential exchange ahead of npm.

(This isn’t to malign any ecosystem; I think people are also overcorrect in treating this like a uniquely JavaScript-shaped problem.)

[1]: https://github.blog/changelog/2025-07-31-npm-trusted-publish...

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#108
post #5

New day, new npm malware. Sigh..

> New day, new npm malware. Sigh.. This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?

Why are people using React to write simple ecommerces?

Why are React devs pulling object utils from lodash instead of reimplementing them?

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#109

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…

I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages).

But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.

Post reply on HN