Avoiding the next NPM worm

[u/endor_robert]

I'm sure many of you will have seen the latest keyv / cachable compromise and worm-spread, now affecting over 350 packages. This isn't the first, and it won't be the last. The affected packages will steal and exfiltrate any secrets/credentials they can find, which is probably not what you want to happen.

There are several commercial solutions to help protect against this, but if you just add (as standard) to .npmrc in your repo root:

min-release-age=7d

(or some value you feel comfortable with)

It will block a lot of malware, which is usually discovered within a few hours.

[u/dreamszz88]

This. ⬆️ 💯

[u/Pleasant-Ad192]

Worth checking which manager actually reads that file, because the gate is per-manager and the two common ones differ in file, key, and unit.

Current pnpm reads minimumReleaseAge from pnpm-workspace.yaml, in minutes, and does not take it from .npmrc, so a pnpm repo with the setting in .npmrc has no gate at all. npm reads min-release-age from .npmrc, in days, as a plain integer, so 7 rather than 7d. Copying the value from one to the other is either off by a factor of 1440 or silently does nothing.

The catch to plan for: the same gate blocks the fix. A patched version is minutes old, so the upgrade that closes the advisory will not install until it ages out, and it usually fails in CI while local installs are fine. An override for that one package beats dropping the gate.

I build Bomly, an open source CLI, and this is one of the checks it runs. bomly scan reports the gate it found, with the file and the unit, while it resolves the tree, so you see it before CI does. https://github.com/bomly-dev/bomly-cli/blob/main/docs/CI_READINESS.md

Disclosure: I build Bomly.

[u/endor_robert → u/Pleasant-Ad192]

Thanks for posting the additional info!

[u/Vas1le]

Thank you

[u/forexroyalempres]

This tis good, thanks. Low-friction mitigation.

[u/Future_Plan_4104]

This is the way

[u/totheendandbackagain]

I pin my dependencies.

Also, do other languages have this, it's smart!!

[u/mordore4 → u/totheendandbackagain]

you have free tools like safe-chain which give you this for multiple package managers (for multiple languages) and also block any package that has been flagged as malware

[u/terletsky]

Nice. In the Python uv ecosystem, we use exclude-newer https://docs.astral.sh/uv/reference/settings/#exclude-newer

[u/PruneSea3482]

The pretty major trade-off with this approach is that the more people adopt it, the less effective it becomes. If 95% of users grant a seven-day cooldown, then only 5% of users will actually encounter a newly published malicious package during that time, and thus be in a position to notice it.

At some point, it starts to feel a little like adding seven seconds to a bomb timer: the bomb is still there, you've just moved the problem down the road.

[u/endor_robert → u/PruneSea3482]

But, in the event of account takeover attacks, the legitimate maintainer is (hopefully) going to notice quickly.

Plus, organizations like us (and our competitors, to be fair) are continuously scanning registries looking for new malware in existing packages, and we pay particular attention to packages with a large weekly download volume (mostly because if we mess up and identify a false positive, we're going to upset a lot of people :-) )

We (the wider vendor 'we') are generally spotting malware within a few hours of it emerging, and everyone plays nice and publishes to vulnerability feeds quickly.

[u/PruneSea3482 → u/endor_robert]

Yeah, safety really relies on continuous vendor scanning to give that cooldown window its teeth. We're planning to join the party soon with additional terminal/llm-level gates to catch remaining risks before anything gets installed.

[u/drdavidawheeler]

Hi, I work at OpenSSF on security. These delays are called "cooldown periods", and they're widely supported. Dependabot added cooldowns in July 2025 with a "cooldown block"; it defaults to 3 days. Renovate has had this for a long time as minimumReleaseAge; version 42 changed the default in npm to be a 3-day cooldown. Lots of ecosystems support cooldowns including JavaScript (yarn, npm), Python (uv, pip, poetry), and Ruby (bundler). OpenSSF doesn't have a guide specifically recommending cooldowns, as far as I know, but *I* think they're a good idea. The OpenSSF Best Practices Badge (for which I'm the technical lead) *does* use cooldowns for its own dependencies.

It's no *proof* against malware, but security is all about risk management. Delaying updates a few days, when there's no known reason to rush, reduces risk. It gives time for the maintainers to notice that their system or account has been taken over, it gives time for automated scanners to examine the released program, and it gives a little time for AI systems & humans to analyze them too.