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: duckdb@1.3.3, @duckdb/duckdb-wasm@1.29.2, @duckdb/node-api@1.3.3, @duckdb/node-bindings@1.3.3. 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.
It was a relay. The fake site forwarded actions to the real npm, so the legit 2FA challenge was triggered by npm and the victim entered the code into the phishing page. The attacker captured it and completed the session, then added an API token and pushed malware. Passkeys or FIDO2 would have failed here because the credential is bound to the real domain and will not sign for npmjs.help.
We analyzed this DuckDB incident today. The attacker phished a maintainer on npmjs.help, proxied the real npm, reset 2FA, then immediately created a new API token and published four malicious versions. A short publish freeze after 2FA or token changes would have broken that chain. Signed emails help, but passkeys plus a publish freeze on auth changes is what would have stopped this specific attack.
There was a similar npm phishing attack back in July (https://socket.dev/blog/npm-phishing-email-targets-developer...). In that case, signed emails would not have helped. The phish used npmjs.org — a domain npm actually owns — but they never set DMARC there. DMARC is only set on npmjs.com, the domain they send email from. This is an example of the “lack of an affirmative indicator” problem. Humans are bad at noticing something missing. Browsers learned this years ago: instead of showing a lock icon to indicate safety, they flipped it to show warnings only when unsafe. Signed emails have the same issue — users often won’t notice the absence of the right signal. Passkeys and publish freezes solve this by removing the human from the decision point.
Some registrars make this easy. Think it was cloudflare that has a button for "Do not allow email from this domain". Saw it last time I set up a domain that I didn't want to send email from. I'm guessing you get that question if there is no MX records for the domain when you move to cloudflare.
A few concrete datapoints from our analysis of this incident that may help cut through the hand-waving:
1. This is the same campaign that hit Qix yesterday (https://socket.dev/blog/npm-author-qix-compromised-in-major-...). The injected payload is byte-for-byte behaviorally identical. It hooks fetch, XMLHttpRequest, and common wallet provider APIs and live-rewrites transaction payloads to attacker addresses across ETH, BTC, SOL, TRX, LTC, BCH. One tell: a bundle of very distinctive regexes for chain address formats, including multiple Solana and Litecoin variants.
2. Affected versions and timing (UTC) that we verified:
- duckdb@1.3.3 at 01:13
- @duckdb/duckdb-wasm@1.29.2 at 01:11
- @duckdb/node-api@1.3.3 at 01:12
- @duckdb/node-bindings@1.3.3 at 01:11
Plus low-reach test shots: prebid@10.9.1, 10.9.2 and @coveops/abi@2.0.1
3. Payout so far looks small. Tracked wallets sum to roughly $600 across chains. That suggests speed of discovery contained damage, not that the approach is harmless.
What would actually move the needle:
=== Registry controls ===
- Make passkeys or FIDO2 mandatory for high-impact publisher accounts. Kill TOTP for those tiers.
- Block publishing for 24 hours after 2FA reset or factor changes. Also block after adding a new automation token unless it is bound by OIDC provenance.
- Require signed provenance on upload for popular packages. Verify via Sigstore-style attestations. Reject if there is no matching VCS tag.
- Quarantine new versions from being treated as “latest” for automation for N hours. Exact-version installs still work. This alone cuts the blast radius of a hijack.
=== Team controls ===
- Do not copy-paste secrets or 2FA. Use autofill and origin-bound WebAuthn.
- Require maker-checker on publish for org-owned high-reach packages. CI must only build from a signed tag by an allowed releaser.
- Pin and lock. Use `npm ci`. Consider an internal proxy that quarantines new upstream versions for review.
=== Detection ===
- Static heuristics catch this family fast. Wallet address regex clusters and network shims inside non-crypto packages are a huge tell. If your tooling sees that in a data engine or UI lib, fail the build.
Lastly, yes, training helps, but the durable fix is making the easy path the safe path.
Running AI coding setups in containers (or even just VMs) seems like a solid default, and I’d love to see tooling move in that direction by default—less as a hard security perimeter, more as a safety net for people trying to move fast.
Re: the article’s conclusion—I get the skepticism. For what it’s worth, the product came after years of trying to solve the problem of package security and maintainer funding in the open. At some point, it felt like the best way to make a dent was to build something dedicated to it.
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.