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)

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.

There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers.

That bit that's getting less conversation is the tools on the package maintainer side:

- MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-...

- trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers

And as of recently, staged publishing, essentially combining the best of both those features: https://docs.npmjs.com/staged-publishing

Now you can: - Publish from CI, without static credentials

- AND require a maintainer to approve it using MFA before it actually goes live to the registry

If you want you can still use something like GitHub Actions Environments protection to require multiple approvals, or a time delay, on the CI side.

We need to encourage the community to adopt these publishing protections or this will continue to be an issue.

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.

Hmm, same day as RH and IBM announce Project Lightwell to help detect and fix supply chain vulns.

https://www.redhat.com/en/lightwell

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. :)

About a week ago, I uninstalled Node from my laptop, which felt great. :)

I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir.

Cooldowns and allow-listing of installer scripts are good additions to layered security, especially for CI. However, I think the fundamental thing that needs to change is the OS permissions model. The default of trusting third-party software with everything your user has access is no longer workable.

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

Should link to the original announcement I think:

https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

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.

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.

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

NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.

Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.

If this is what will take for folks to move away from JS ecosystem, I'll take 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...

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

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/...

This is a completely unexpected turn of events that no one could have possibly foreseen.

In addition with my usual rant about the current situation with most devs that now want to use dependencies in prod almost the day that they are released, there is something else that I just realized. A big part of the problem might be attributed to Github and the modern CI/CD frameworks.

Before, the source code was located somewhere, and the CI was usually located somewhere else, and slightly unrelated. At first, the CI job was to build ("privately") the artefacts, and they were manually released and deployed by maintainers and owner of software projects.

Then, it became the norm to have the CI located within the VCS file and the VCS located source code controlling the CI. For example having "script"/"description" of the CI actions located within the VCS itself.

Then, Github killed the CI/CD software market by offering "actions" almost for free and totally integrated within Github that was already widely used.

But still, for a long time people were wary to put tokens and security keys in Github and "public" CI/CD jobs and services.

And then, a few years ago, it became the gold standard also... You would look ridiculous to manually sign and deploy new releases with well guarded keys. What is expected from you is to have all your aws, github, ... secret api keys loaded in Github, and have your deployment and infrastructure provisioning automated with ("public") github accounts. All to be deployable in a second of a change being pushed.

So, obviously, the moment a hacker get control of a Github account or Github API keys, it is game over for the entire infrastructure.

Here I only referenced Github, but the bad things that it taught us became the norm and now these patterns are replicated everywhere (Gitlab, ...)

Given they use nx my bet is on developer laptop compromise through the nx vscode extension that also compromised GitHub engineer's laptop

That’s why I switched to Java.

Red Hat security bulletin on this incident: https://access.redhat.com/security/vulnerabilities/RHSB-2026...

Quote:

> The affected packages are frontend libraries that are compiled and bundled into some container images during the Red Hat product build process.

So you might be affected if you deployed any Red Hat container images built after the compromise, I guess. (I doubt anyone besides Red Hat is using the affected packages directly.)

I'll be honest, I have always found the "trusted" publishing concept quite suspect -- the boiled-down argument is that developers are too incompetent to manage their own keys. Yes, there are obviously problems with storing plaintext publishing keys and tokens in $HOME, but that isn't the only solution. You can use hardware keys for signing (I would wager a lot of open source maintainers have at least one Yubikey or NitroKey kicking around -- they used to give them away at conferences) and for upload tokens you can even just password-protect them or require them to log in each time.

The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means.

The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens.

I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).

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/

I also commented on the other issue flagged: https://github.com/RedHatInsights/platform-frontend-ai-toolk...

Also detonated the payload: https://leitwacht.eu/blog/valid-provenance-malicious-package

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.

Podman? Podman for OSX comes with a login item from "Red Hat, Inc". Anyone know how to check if this subcomponent utilizes these npms?

Looks like RedHat got compromised by a Black Hat…

It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.

Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.

GitHub repo (800+ stars) on a list of tips for protecting against npm supply chain attacks: https://github.com/bodadotsh/npm-security-best-practices

undefined

undefined

The entire ecosystem is cursed

There is some effort to make NPM more secure https://github.com/npm/cli/pull/9360.

The joke is on you NPM! I only use CDNs for my JS libraries.

undefined

Question - is there no way to catch these criminals?

Throw the JS ecosystem into the sun at this point.

At some point, they need a new system for these "packages", you've got to be insane to install any of these right now.

Human society, and our technology, is a fragile system built on our hubris, a cheap replacement for the Divine Eye of Providence.

Cool down sounds good until everyone does it and the issue isn't caught until afterwards

As a dev mostly working on Node. Those are scary title to read

It's becoming laughable how frequently this is happening. Wow.

if RedHat is unable to secure their packages, what can we expect from mere mortals...

This seems to be sinister

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?

man we gotta do smth with preinstall hooks atp

Redhat's entire reason for existence is to prevent this.

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?

When will npm issues stop ? This has become a big pain !

Violence!

'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_...

The XML extension I use in VSCode is by Red Hat.

Oh dear. Here we go again.

perfect time to drop a reminder: vendoring might seem annoying, but it's way safer than trusting a remote registry.

Fucking Microsoft

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]

Salam

Has anyone thought of having an agent review all dependency upgrades before upgrading?

I feel like that would at least catch some of these

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.

Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved

It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitely not because no one has really tried

Then, when someone finally turns their attention to you and walks in: fire whoever needs to be fired, patch that specific hole, maybe spend a bunch of money on a different system, assure the overseers that it’s handled, and move on with business as usual

It’s cheaper in the long-run, it makes stockholders happy, it relieves the bosses and their bosses, and for the most part there are “no security holes”.

Until now, of course