I agree that per dependency is the right granularity, and this always held the Deno model back. Another good idea from Deno: it won't run an npm package's pre-install or post-install scripts unless you approve that package. pnpm 10 adopted the same default, as well as npm 12 afterwards.
The Go binary was also compromised, but there's almost no information what the compromised binary did. Did it drop a python script? Did it do direct scanning?
If trivy docker image was used, what's the scope (it does not include python).
This is the fourth supply chain compromise on npm in just over a week.
If you don't follow this space closely, here's the bigger picture: these are part of an organized campaign that's hitting popular packages and slipping in malware.
What makes this campaign different is how aggressive it is: the payload doesn’t just run locally -- it actively hunts for developer and CI/CD credentials, spins up rogue GitHub Actions, and uses those to keep propagating. That’s a step beyond the usual crypto miner or info stealer.
npm and other package registries have become the weakest link in modern software. Every developer depends on them, yet a single compromised dependency can cascade into thousands of downstream apps and companies.
Founder of socket.dev here. “AI detected potential malware” is what we call the alerts generated by our automated malware detection engine that runs on all newly published open source packages in real-time. However, these alerts are reviewed by our threat research team and once a human has confirmed the finding, we upgrade it to “Known malware”.
At this point (given we just published research about this) we've upgraded this threat to Known malware.
So in short:
- “AI detected potential malware” = automated system found something suspicious
- “Known malware” = human confirmed it’s real
The wording is intentional because not every automated hit ends up being true malware. It’s better to give developers early visibility into possible threats, even if they turn out to be benign, than to miss a real attack.
npm stats lag. We observed installs while the malicious versions were live for hours before removal. Affected releases we saw: [email protected], @duckdb/[email protected], @duckdb/[email protected], @duckdb/[email protected]. Same payload as yesterday’s Qix compromise. Recommend pinning and avoiding those versions, reviewing diffs, and considering a temporary policy not to auto-adopt fresh patch releases on critical packages until they age.
Strongly agree on artifact signing, but it has to be real end-to-end. If the attacker can trigger your CI to sign with a hot key, you still lose. What helps: 1) require offline or HSM-backed keys with human approval for release signing, 2) enforce that published npm artifacts match a signed Git tag from approved maintainers, 3) block publishes after auth changes until a second maintainer re-authorizes keys. In today’s incident the account was phished and a new token was used to publish a browser-side wallet-drainer. Proper signing plus release approvals would have raised several hard gates.
reply