Active Npm Supply Chain Attack: Tinycolor and 40 Packages Compromised
Key topics
A recent supply chain attack compromised 40 packages in the NPM ecosystem, including Tinycolor, and the community is discussing the implications and potential mitigations. The attack highlights the ongoing security concerns in the NPM ecosystem.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
37m
Peak period
9
6-9h
Avg / period
3
Based on 36 loaded comments
Key moments
- 01Story posted
Sep 15, 2025 at 7:29 PM EDT
4 months ago
Step 01 - 02First comment
Sep 15, 2025 at 8:06 PM EDT
37m after posting
Step 02 - 03Peak activity
9 comments in 6-9h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 17, 2025 at 1:45 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
So on balance I guess I'll ignore it. What a time to be a developer.
At this point (given we just published research about this) we've upgraded this threat to Known malware.
So in short:
- “AI detected potential malware” = automated system found something suspicious
- “Known malware” = human confirmed it’s real
The wording is intentional because not every automated hit ends up being true malware. It’s better to give developers early visibility into possible threats, even if they turn out to be benign, than to miss a real attack.
Code signing could and should have been implemented years ago. It's not a panacea but just part of defense in depth.
I can't trust npm whatsoever to do the right thing at this point.
pnpm refuses to run install scripts from packages you haven’t manually authorized, which helps a bit.
You can put a fingerprint on the package dependency itself, though, so if you add a fingerprint to anything you approve the install script for, you will get that level of safety.
Pnpm should be considered for hobby use cases only.
If you do not have time to review a library, then do not use it.
Nobody has time to review every package they'll use, especially when not all sub dependencies have fully pinned versions.
If you have time to review every package, every time it updates, you might as well just write it yourself.
Yes, this is a problem, no reviewing every dependency is not the damn solution
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
And then hardware compromises…
I don't mean install anything. I mean, it's not a problem particular to the JS ecosystem.
"just give up" is not a valid strategy.
https://codeberg.org/stagex/stagex
Also now as someone that runs a security consulting firm, we absolutely have clients that review 100% of dependencies even when it is expensive.
Both are valid options.
Normalized negligence is still negligence.
On the other hand, yes, an attack at code level, or a legit bug wouldn't be prevented.
supply chain is and has been the new gold mine for bad actors it seems
- Prevent publishing new package versions for 24–48 hours after account credentials are changed.
- Require support for security keys.
Except NPM rejected this over and over going back to 2013.
https://github.com/npm/npm/pull/4016
I'd love to see npm adopt keyless signing like PyPi are doing with https://peps.python.org/pep-0740/.
Also GnuPG is not PGP.
My team and I dual PGP sign all packages in stagex with smartcards after confirmed determinstic builds. It works great, and avoids trust in any single party or computer. We even do this for all our python packages as pip will not allow it.
It is a single command with a rust binary to setup a PGP smartcard out of the package, with a backup. (keyfork) All devs should be PGP signing releases, reviews, and commits so we have a paper trail blackhats cannot inject themselves into.
There are no excuses other than misconceptions and misinformation on this topic being normalized.
But the fact is it hasn't worked for package repos like PyPi, and it won't for npm, because in a distributed, low-trust ecosystem like npm, you can't easily bind identities to PGP keys or have any confidence in the key management practices of package signers.
And of course "keyless" signing isn't literally keyless. But tools like sigstore remove the need for the management of long-lived keys and can bind a signature to an identity verified by a trusted IdP, solving some of the main issues with adopting PGP signatures.
NPM has bigger problems - no adults in the room! For example, they've been rejecting signed packages since 2014 or thereabouts?
Expect npm repos to be overflowing with AI-submitted crap that will lower the signal substantially due to not having any sort of identify via signing.