Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't.
Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
show comments
dmix
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).
1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.
2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.
3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.
(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.
There are some vendors in this space that you can and should evaluate as well.
It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
show comments
kitd
Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns.
Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.
exabrial
NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
majorbugger
I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
king_zee
I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
show comments
voidUpdate
One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
show comments
rochak
If this is what will take for folks to move away from JS ecosystem, I'll take it.
show comments
indy
This is a completely unexpected turn of events that no one could have possibly foreseen.
arianvanp
Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop
show comments
czbond
Podman? Podman for OSX comes with a login item from "Red Hat, Inc". Anyone know how to check if this subcomponent utilizes these npms?
wg0
Question - is there no way to catch these criminals?
show comments
general_reveal
That’s why I switched to Java.
show comments
phishin
Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.
show comments
paulbjensen
Looks like RedHat got compromised by a Black Hat…
ex-aws-dude
Has anyone thought of having an agent review all dependency upgrades before upgrading?
I feel like that would at least catch some of these
kogasa240p
Throw the JS ecosystem into the sun at this point.
Pxtl
The combined features that make npm particularly vulnerable:
1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower.
2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server.
3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.
Noaidi
Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.
Escapade5160
Can someone give a tldr on why this happens so much with npm ? I can't recall seeing this with any other package manager. Is npm just the default used these days and therefore sees this more often?
grugdev42
The joke is on you NPM! I only use CDNs for my JS libraries.
show comments
replwoacause
It's becoming laughable how frequently this is happening. Wow.
freakynit
Lol.. yet again npm and install-scripts abuse at play.
I'm refactoring all my personal and research projects to utilize pure HTML/CSS without any dependency of JavaScript. This was always on the table but the cybersecurity risks from all programming languages and frameworks have increased due to AI.
I know of fundamental issues with JavaScript and see no reason why it's still standard on all web browsers.
rvz
This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again.
So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.
When will npm issues stop ? This has become a big pain !
what_hn
Same actors again?
bpavuk
Violence!
m3kw9
At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.
hsibenMohamed
Salam
MadrasTh0rn
Fucking Microsoft
dist-epoch
if RedHat is unable to secure their packages, what can we expect from mere mortals...
show comments
buckle8017
Redhat's entire reason for existence is to prevent this.
show comments
_pdp_
Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes?
All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with.
In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.
'No Way to Prevent This,' Says Only package manager Where This Regularly Happens
Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
How to set them up?
- use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days).
https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
Just some suggestions:
1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.
2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.
3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.
(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.
There are some vendors in this space that you can and should evaluate as well.
I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns.
https://www.redhat.com/en/lightwell
Should link to the original announcement I think:
https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...
Npm is just borked by design. I hop it will take javascrip with it
We have done the complete analysis and there are 32 packages share the same publishing pipeline. https://safedep.io/redhat-cloud-services-hit-by-mini-shai-hu...
Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.
NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
If this is what will take for folks to move away from JS ecosystem, I'll take it.
This is a completely unexpected turn of events that no one could have possibly foreseen.
Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop
Podman? Podman for OSX comes with a login item from "Red Hat, Inc". Anyone know how to check if this subcomponent utilizes these npms?
Question - is there no way to catch these criminals?
That’s why I switched to Java.
Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.
Looks like RedHat got compromised by a Black Hat…
Has anyone thought of having an agent review all dependency upgrades before upgrading?
I feel like that would at least catch some of these
Throw the JS ecosystem into the sun at this point.
The combined features that make npm particularly vulnerable:
1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower.
2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server.
3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.
Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.
Can someone give a tldr on why this happens so much with npm ? I can't recall seeing this with any other package manager. Is npm just the default used these days and therefore sees this more often?
The joke is on you NPM! I only use CDNs for my JS libraries.
It's becoming laughable how frequently this is happening. Wow.
Lol.. yet again npm and install-scripts abuse at play.
Updated:
1. All exploitation techniques used since May 2025: https://npm-supply-chain-attack-techniques.pagey.site/
2. All attacks that happened since May 2025: https://npm-supply-chain-attacks-25-26.pagey.site/
This seems to be sinister
The entire ecosystem is cursed
I'm refactoring all my personal and research projects to utilize pure HTML/CSS without any dependency of JavaScript. This was always on the table but the cybersecurity risks from all programming languages and frameworks have increased due to AI.
I know of fundamental issues with JavaScript and see no reason why it's still standard on all web browsers.
This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if another malicious security update happens again.
So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.
[0] https://github.com/RedHatInsights/javascript-clients/commit/...
man we gotta do smth with preinstall hooks atp
The XML extension I use in VSCode is by Red Hat.
Oh dear. Here we go again.
Oooh now I'm wondering if this may have contributed to their Docker image distribution service getting disrupted earlier today... https://status.redhat.com/incidents/jn6r256zc62c
When will npm issues stop ? This has become a big pain !
Same actors again?
Violence!
At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.
Salam
Fucking Microsoft
if RedHat is unable to secure their packages, what can we expect from mere mortals...
Redhat's entire reason for existence is to prevent this.
Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes?
All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with.
In fact, the entire situation has been exacerbated by coding agents because now practically everything happens on a single device that touches hundreds of different production systems with full production credentials.