by eranation
3 subcomments
- 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)
by insanitybit
2 subcomments
- 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.
- 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...
- 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
- There is some effort to make NPM more secure https://github.com/npm/cli/pull/9360.
by mellosouls
1 subcomments
- Should link to the original announcement I think:
https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...
by Sudhanshu2310
0 subcomment
- 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'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
by majorbugger
1 subcomments
- I would like to meet the person behind the "postinstall scripts" idea and try to understand how they thought it was a good idea.
- Npm is just borked by design. I hop it will take javascrip with it
by voidUpdate
2 subcomments
- 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
- This is a completely unexpected turn of events that no one could have possibly foreseen.
- If this is what will take for folks to move away from JS ecosystem, I'll take it.
by arianvanp
1 subcomments
- Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop
by general_reveal
4 subcomments
- That’s why I switched to Java.
- 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?
- 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.
by paulbjensen
0 subcomment
- Looks like RedHat got compromised by a Black Hat…
by ex-aws-dude
1 subcomments
- Has anyone thought of having an agent review all dependency upgrades before upgrading?
I feel like that would at least catch some of these
- 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.
by kogasa240p
0 subcomment
- Throw the JS ecosystem into the sun at this point.
by grugdev42
2 subcomments
- The joke is on you NPM! I only use CDNs for my JS libraries.
by replwoacause
0 subcomment
- 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/
- Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.
by Escapade5160
0 subcomment
- 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?
- man we gotta do smth with preinstall hooks atp
- This seems to be sinister
- The entire ecosystem is cursed
by kittikitti
0 subcomment
- 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/...
- 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
- Same actors again?
- When will npm issues stop ? This has become a big pain !
- Violence!
- The XML extension I use in VSCode is by Red Hat.
Oh dear. Here we go again.
- At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.
by hsibenMohamed
0 subcomment
- Salam
- '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_...
by dist-epoch
1 subcomments
- if RedHat is unable to secure their packages, what can we expect from mere mortals...
by buckle8017
2 subcomments
- Redhat's entire reason for existence is to prevent this.
by MadrasTh0rn
0 subcomment
- Fucking Microsoft
by niros_valtos
0 subcomment
- [flagged]
- [dead]
- [flagged]
by throwaway613746
0 subcomment
- [dead]
by calvinmorrison
0 subcomment
- [dead]
by throwaway613746
0 subcomment
- [dead]
by victorrpham
0 subcomment
- [dead]
- 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.
Hacker News