Live data from Hacker News

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

socket.dev

681–690 of 1001 posts

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

#681

Earlier quoted context omitted.

> This is an eco system that has taken code reuse to the (unreasonable) extreme. Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.

The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package

The blessing and curse of frontend development is that there basically isn't a barrier to entry given that you can make some basic CSS/JS/HTML and have your browser render it immediately.

There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development"

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

#682

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

>> and keeping them to well-known and trustworthy (security-wise) creators. The true threat here isn't the immediate dependency though, it's the recursive supply chain of dependencies. "trustworthy" doesn't make any sese either when the root cause is almost always someone trustworthy getting phished. Finally if I'm not capable of auditing the dependencies it's unlikely I can replace them with my own code. That's like…

[deleted]

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

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

The article explicitly mentions a way to do this: Use NPM Package Cooldown Check The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks ar…

That's a feature of stepsecurity though, it's not built-in.

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

#684

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

Its much more feasible these days. These days for my personal projects I just have CC create only a plain html file with raw JS and script links.

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

#685

Earlier quoted context omitted.

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

It isn't feasible to audit every line of every dependency, just as it's not possible to audit the full behavior of every employee that works at your company. In both cases, the solution is similar: try to restrict access to vital systems only to those you trust,so that you have less need to audit their every move. Your system administrators can access the server room, but the on-site barista can't. Your HTTP server i…

> It isn't feasible to audit every line of every dependency, just as it's not possible to audit the full behavior of every employee that works at your company.

Your employees are carefully vetted before hiring. You've got their names, addresses, and social security numbers. There's someone you're able to hold accountable if they steal from you or start breaking everything in the office.

This seems more like having several random contractors who you've never met coming into your business in the middle of night. Contractors that were hired by multiple anonymous agencies you just found online somewhere with company names like gkz00d or 420_C0der69 who you've also never even spoken to and who have made it clear that they can't be held accountable for anything bad that happens. Agencies that routinely swap workers into or out of various roles at your company without asking or telling you, so you don't have any idea who the person working in the office is, what they're doing, or even if they're supposed to be there.

"To make thing easier for us we want your stuff to require the use of a bunch of code (much of which does things you don't even need) that we haven't bothered looking at because that'd be too much work for us. Oh, and third parties we have no relationship with control a whole bunch of that code which means it can be changed at any moment introducing bugs and security issues we might not hear about for months/years" seems like it should be a hard sell to a boss or a client, but it's sadly the norm.

Assuming that something is going to go wrong and trying to limit the inevitable damage is smart, but limiting the amount of untrustworthy code maintained by the whims of random strangers is even better. Especially when the reasons for including something that carries so much risk is to add something trivial or something you could have just written yourself in the first place.

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

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

pnpm just added this: https://pnpm.io/blog/releases/10.16

this btw would also solve social media. if only accounts required a month waiting period before they could speak.

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

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

When using Go, you don't get updated indirect dependencies until you update a direct dependency. It seems like a good system, though it depends on your direct dependencies not updating too quickly.

The auto-updating behaviour dependencies because of the `^` version prefix is the root problem.

It's best to never use `^` and always specify exact version, but many maintainers apparently can't be bothered with updating their dependencies themselves so it became the default.

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

#688

Blog author company's runner detects anomalies in them, but we shouldn't need a product for this. Detecting outbound network connection during an npm install is quite cheap to implement in 2025. I think it comes down to tenant and incentives, if security is placed as first priority as it should, for any computing service and in particular for supply chain like package management, this would be built in. One thing tha…

"Outbound network connection at npm install" is just one of many ways malware in NPM package can manifest itself.

E.g. malware might be executed when you test code which uses the library, or when you run a dev server, or on a deployed web site.

The entire stack is built around trusting a code, letting it do whatever it wants. That's the problem.

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

#689

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

>> and keeping them to well-known and trustworthy (security-wise) creators. The true threat here isn't the immediate dependency though, it's the recursive supply chain of dependencies. "trustworthy" doesn't make any sese either when the root cause is almost always someone trustworthy getting phished. Finally if I'm not capable of auditing the dependencies it's unlikely I can replace them with my own code. That's like…

> Finally if I'm not capable of auditing the dependencies it's unlikely I can replace them with my own code. That's like telling a vibe coder the solution to their brittle creations is to not use AI and write the code themselves.

In both cases, actually doing the work and writing a function instead of adding a dependency or asking an AI to write it for you will probably make you a better coder and one who is better able to audit code you want to blindly trust in the future.

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

#690

Earlier quoted context omitted.

npm will use your lockfile if it’s present, otherwise yeah it’s pretty much whatever is tagged and latest at the time (and the version doesn’t even have to change). If npm respected every upstream lockfile, then it could never share a single version that satisfied all dependencies. The bigger issue here is that npm has such unrestricted and unsupervised access to the entire environment at all.

> If npm respected every upstream lockfile, then it could never share a single version that satisfied all dependencies. I'm asking in the context of installing a single CLI tool into ~/bin or something. There's no requirement to satisfy all dependencies, because the only dependency I care about is that one CLI tool. All I want is an equivalent of what `cargo install --locked` does — use the top-level lockfile of the…

npm itself does not know that what you are installing is a CLI tool.

Good CLI tools are bundled before release so they are zero-dependency as far as npm is concerned, which is ideal imho for all CLI tools, but many don't do that.

Post reply on HN