DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.

But the domain binding just isn't possible without technical means, hence I see that as my own top reason, I suppose :)

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.

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.