Self Propagating NPM Malware Compromises over 40 Packages

33 jamesberthoty 12 9/16/2025, 11:22:03 AM stepsecurity.io ↗

Comments (12)

madeofpalk · 40s ago
My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise.

How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

l___l · 1m ago
Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
dist-epoch · 17s ago
There are, but they have huge performance penalties.

Stuff like intents "this math library is not allowed to access the network".

gchamonlive · 14m ago
We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?
liveoneggs · 6m ago
It's the entire blase nature of js development in general.
koakuma-chan · 6m ago
> is there something fundamentally wrong with NPM?

Its users don't check who the email is from

dist-epoch · 7m ago
It's just where the users and the juicy targets are.

NPM packages are used by huge Electron apps like Discord, Slack, VS Code, the holy grail would be to somehow slip something inside them.

guidedlight · 42s ago
We don't see these attacks nearly as severe or frequent on Maven, which is a much older package management solution. Maven users would be far more attractive targets given corporates extensively run Java.
anthk · 5m ago
Every NPM turd should be run with bubblewrap or a similar sandbox toolkit at least.
freakynit · 12m ago
New day, new npm malware. Sigh..
motorest · 6m ago
> 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?

diggan · 2m ago
So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has?

There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting here? Someone sits and reviews every published package and rejects it if the package doesn't fit your ideal?