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

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

socket.dev

Post reply on HN
Print view View original

711–720 of 1001 posts

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

#711

Post by jonquest »

mandevil wrote: post #647
latexr wrote: post #636

Earlier quoted context omitted.

The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself . Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.

This might be fine for some utility functions which you can tell at a glance have no errors, but for anything complex, if you copy you don't get any of the bug/security fixes that upstream will provide automatically. Oh, now you need a shim of this call to work on the latest Chrome because they killed an api- you're on your own or you have to read all of the release notes for a dependency you don't even have! But tak…

The massive amount of transitive dependencies is exactly the problem with regard to auditing them. There are successful businesses built solely around auditing project dependencies and alerting teams of security issues, and they make money at all because of the labor required to maintain this machine.

It’s not even a judgement call at this point. It’s more aligned with buckling your seatbelt, pointing your car off the road, closing your eyes, flooring it and hoping for a happy ending.

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

#712

Post by poly2it »

user3939382 wrote: post #182
progx wrote: post #121

Earlier quoted context omitted.

One downvote is not enough.

One upvote is not enough. We need enough upvotes to fix the problem. You can’t shape a big pile of shit into success. HTTP and JS will never serve as a proper application framework.

Would you care to elaborate? What solution do you propose, and how would it be implemented? How would removal of JavaScript and HTTP solve the dependency malware issue being discussed?

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

#713

Post by worik »

lucideer wrote: post #81
codemonkey-zeta wrote: post #31

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…

The Rust folks are in denial about this

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

#714

Post by jitix »

rectang wrote: post #423
ncruces wrote: post #381

Earlier quoted context omitted.

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

It's not unreasonable to trust large numbers of trustworthy dependency authors. What we lack are the institutions to establish trust reliably. If packages had to be cryptographically signed by multiple verified authors from a per-organization whitelist in order to enter distribution, that would cut down on the SPOF issue where compromising a single dev is enough to publish multiple malware-infested packages.

It IS unreasonable to trust individual humans across the globe in 100+ different jurisdictions pushing code that gets bundled into my application.

How can you guarantee a long trusted developer doesn't have a gun pointed to their head by their authoritarian govt?

In our B2B shop we recently implemented a process where developers cannot add packages from third party sources - only first party like meta, google, spring, etc are allowed. All other boilerplate must be written by developers, and on the rare occasion that a third party dependency is needed it's copied in source form, audited and re-hosted on our internal infrastructure with an internal name.

To justify it to business folks, we presented a simple math where I added the man-hours required to plug the vulnerabilities with the recurring cost of devsecops consultants and found that it's cheaper to reduce development velocity by 20-25%.

Also devsecops should never be offshored due to the scenario I presented in my second statement.

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

#715

Post by voxelghost »

LelouBil wrote: post #606
theodorejb wrote: post #276

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package…

I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or c…

Its only JS devs that constantly rebuild their system with full dependcy update, so they are the most attractive target.

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

#716

Post by esafak »

kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

> One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies.

You can do it:

https://github.blog/changelog/2025-07-01-dependabot-supports...

https://docs.renovatebot.com/configuration-options/#minimumr...

https://www.stepsecurity.io/blog/introducing-the-npm-package...

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

#717

Post by travisgriggs »

kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

Use less dependencies :)

And larger dependencies that can be trusted in larger blocks. I'll bet half of a given projects dependencies are there to "gain experience with" or be able to name drop that you've used them.

Less is More.

We used to believe that. And then W3C happened.

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

#718

Post by lukaslalinsky »

weinzierl wrote: post #452
rlpb wrote: post #376

Earlier quoted context omitted.

This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.

"exactly the same software supply chain problem" While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified. There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with cr…

I'd argue it's more of a culture thing, not technical thing.

In both JavaScript and Rust, it's normal/encouraged to just add a tiny dependency to the package manager. The communities even pride themselves, that they have such good package managers to allow this.

It's this "yeah, there is a crate for this tiny function I need, let's just include it" mentality that makes the ecosystem vulnerable.

People need to be responsible for whatever they include, either pay the price by checking all versions up front, or pay it by risking shipping a vulnerable program that it's much harder to retract than a JavaScript frontend.

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

#719

Post by hshdhdhj4444 »

smaudet wrote: post #703
2muchcoffeeman wrote: post #462

Earlier quoted context omitted.

Have we all forgotten the left-pad incident? This is an eco system that has taken code reuse to the (unreasonable) extreme. When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

I found it funny back when people were abandoning Java for JavaScript thinking that was better somehow...(especially in terms of security) NPM is good for building your own stack but it's a bad idea (usually) to download the Internet. No dep system is 100% safe (including AI, generating new security vulns yay). I'd like to think that we'll all stop grabbing code we don't understand and thrusting it into places we don…

It’s not clear to me what this has to do with Java vs JavaScript (unless you’re referring to the lack of a JS standard library which I think will pretty much minimize this issue).

In fact, when we did have Java in the browser it was loaded with security issues primarily because of the much greater complexity of the Java language.

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

#720

Post by johnny22 »

WorldMaker wrote: post #297
skydhash wrote: post #204

Earlier quoted context omitted.

Stuff like Babel, React, Svelte, Axios, Redux, Jest… should be self contained and not depend on anything other than being a peer dependency. They are core technological choices that happens early in the project and is hard or impossible to replace afterwards.

- I feel that you are unlikely to need Babel in 2025, most things it historically transpiled are Baseline Widely Available now (and most of the things it polyfilled weren't actually Babel's but brought in from other dependencies like core-js, which you probably don't need either in 2025). For the rest of the things it still transpiles (pretty much just JSX) there are cheaper/faster transpilers with fewer external dep…

Last i checked react's new compiler still depends on babel! :(
Post reply on HN