what commercial tools are enterprises using today to defend against such attacks? Do they really work? I mean, do they report/block malware after the fact or detect proactively. Because if the latter then, package registries should really be removing reported packages, right?

At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion.

It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.

OW. That's gonna leave a mark.

It sucks that we have this glass-jaw dependency system, which is really the main reason these supply chain attacks work.

Really hard to clean up, too. These days, you (being the blackhat) would likely send agents to leverage every compromised repo/app/Web site, almost the instant it comes online, so even if the original mess is cleaned up, there's still a ton of knock-on compromises.

echo "min-release-age=5" >> ~/.npmrc

This should be your default minimum if you work with node.

Updated my docs covering these attacks since 2025:

1. NPM Supply Chain Attack Techniques: https://npm-supply-chain-attack-techniques.pagey.site/

2. NPM Ecosystem Threat Report: https://npm-supply-chain-attacks-25-26.pagey.site/

Does anyone happen to have a grep or similar that helps me check if this is showing up anywhere in the trillions of files in node_modules (or pnpm store)?

Once again, I ask myself: should we start "shaming" developers who don't use isolation? It still seems I am the exception and most people run their dev environment with full permissions. Why?

I also wrote an article (https://evertheylen.eu/p/shame-devs-without-isolation/) to flesh out my thoughts, but I'd be really happy to discuss this in the comments.

I am kind of surprised GitHub doesn't seem to have built a simple classifier for public repos to proactively lock the account of anyone uploading such obviously fishy things (for their own good, at least before the repo is publicly findable), so it can't be used as a rendezvous.

Surely Github's software is good enough that an intern can slop the 80/20 together in a day? It would be an actually good use of AI spending.

You know with all this AGI swirling around nowadays that is stronger than nation state hackers you think one of these companies would demonstrate just how capable they are by defending public infrastructure.

Unless...

Maybe in 6 months.

Oh boy, it's a big one.

Where is the fbi in this? Why has no one been arrested? This is a massive crime.

I mean what are these devs doing that they are day-1 updating npm packages still?

How many instances of this are required before npm package maintainers learn?

No way to prevent this says only package manager where this regularly happens

ad slop post

We (StepSecurity) published a full analysis of both payload stages: https://www.stepsecurity.io/blog/chaindrop-npm-worm

Some additional detail from our analysis:

1. Provenance did not fail, it worked as designed and still shipped malware. The initial 11 packages were published through npm OIDC Trusted Publishing with valid SLSA attestations. The attacker compromised the maintainer's GitHub account and let the projects' own release workflows publish. Provenance proves which commit was built, not that the commit was authorized.

2. There is a booby trap on remediation: the worm installs a watcher that fires an attacker payload when the stolen GitHub token gets revoked. Remove the token monitor first, then rotate.

3. Persistence goes beyond node_modules. It writes .claude/settings.json (SessionStart hook) and .vscode/tasks.json (runOn: folderOpen), each re-executing the dropper. Check repo dotfiles too.

4. No C2 domain to sinkhole: exfil endpoints resolve at runtime from an Ethereum contract. Observed domain is npm-cache.com, but the operator can rotate it and push new code to infected hosts.

If you're auditing: look for setup.mjs, a 727,680 byte Math_Symbol.js (math_init.js in the second wave), and "preinstall": "node setup.mjs" in package.json. Careful, regenerate-unicode-properties ships a legitimate 1 KB Math_Symbol.js; the malicious one is over 700 KB.

Full IOC and package list in the post, updated as the campaign develops.

The cheapest mitigation almost nobody deploys: a version cooldown. These worms get caught fast — this one was flagged same-day, and the article's own timeline shows detection racing ahead of spread. If your CI simply refuses to adopt any version published in the last N days (Renovate supports this natively via minimumReleaseAge), you convert "worm spreads through the ecosystem in hours" into "worm must survive N days of public scrutiny before it can reach you." You give up almost nothing: how often does your product genuinely need a dependency version that's 48 hours old?

Combine that with the workflow split insanitybit describes — build/test jobs holding zero publish credentials, a separate publish job that only touches a finished artifact — and the wormable path is mostly closed without waiting for npm to redesign itself.

None of this is "sufficient" in rcxdude's sense, and that's fine. Sufficiency isn't the bar during an active outbreak; raising the attacker's cost per hop is.

[flagged]

I think npm can use chatgpt/claude for each published package to detect these types of attack? And if it sees they can restrict the package from making any changes.

aikido.dev: SAST, AI code analysis and therefore a website that uses 100% CPU and prevents scrolling.

To the point of the article: I don't know why GitHub still allows the release feature. It is complete insanity. Tar archives must be constructed manually and checked for leaked keys etc.

I have a suspicion that a lot of these supply chain compromises are done by the security researchers at security vendors, selling software to protect the software supply chain. Spreading fear to create demand for their products.

Like in the good ole days of Windows 98 and antivirus era, a lot of advanced virus techniques in the wild came from the people who used to work for AV companies

> Update — August 4, 2026, 13:37 CEST: At least 868 packages (across 1381 versions) have been compromised by the worm, with a combined total of over 2 billion monthly installs at the time of writing.

This is such lazy or click baiting writing. Who cares how many installations there are per month normally? The high install numbers are almost certainly from running in CI where such secrets don’t exist. How many installs actually occur in a non CI environment and of those how many were the compromised version?