HN Reader

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time.

People who publish software packages tend to be at least somewhat technical people. Can package publishing platforms PLEASE start SIGNING emails. Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform.

Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks.

And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.

At least third major compromise in two weeks. (last comment: https://news.ycombinator.com/item?id=45172225) (before that: https://news.ycombinator.com/item?id=45039764)

Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing.

You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-user with your public key. Even if your NPM account gets taken over, the attacker does not have your private key, so they cannot publish valid packages as you.

But because these platforms don't enforce code and artifact signing, and their tools aren't verifying those signatures, attackers just have to figure out a way to upload their own poison package (which can happen in multiple ways), and everyone is pwnd. There must be a validated chain of trust from the developer's desktop all the way to the end user. If the end user can't validate the code they were given was signed by the developer's private key, they can't trust it.

This is already implemented in many systems. You can go ahead and use GitHub and 1Password to sign all your commits today, and only authorize unsealing of your private key locally when it's needed (git commits, package creation, etc). Then your packages need to be signed too, public keys need to be distributed via multiple paths/mirrors, and tools need to verify signatures. Linux distributions do this, Mac packages do, etc. But it's not implemented/required in all package managers. We need Npm and other packaging tools to require it too.

After code signing is implemented, then the next thing you want is 1) sign-in heuristics that detect when unusual activity occurs and either notifies users or stops it entirely, 2) mandatory 2FA (with the option for things like passkeys with hardware tokens). This will help resist phishing, but it's no replacement for a secure software supply chain.

> This website contained a *pixel-perfect copy* of the npmjs.com website.

Not sure how this emphasis is of any importance, you brain doesn't have a pixel perfect image of the website, so you wouldn't know whether it's a perfect replica or not.

Let the silicon dummies in the password manager do the matching, don't strain your brain with such games outside of entertainment

So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though.

I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?

> According to the npm statistics, nobody has downloaded these packages before they were deprecated

Is this actually accurate? Packages with weekly downloads in the hundreds of thousands, yet in the 4+ hours that the malicious versions were up for, not a single person updated any of them to the latest patch release?

Just for context. DuckDB team is consistently ignores any security practices.

The single one method how to install DuckDB on laptop is to run

`curl https://install.duckdb.org | sh`

I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091

As you can see that it isn't single slip due to "human factor", but DuckDB management consistently puts users at risk.

I've been critical of blockchain in the past because of the lack of use cases, but I've gotta say crypto functions pretty well as an underlying bug bounty system. This probably could have been a much more insidious and well hidden attack if there wasn't a quick payoff route to take.

Maybe email software should add an option to make links unclickable, or show a box with the clear link (and highlight the domain) before letting the user go through it.

They already make links go through redirects (to avoid referrer headers?) so it's halfway there. Just make the redirect page show the link and a go button instead of redirecting automatically. And it would fix the annoyance that is not being able to see the real domain when you hover the link.

Is this related to npm debug and chalk packages being compromised?

https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...

I guess it's hands off the npm jar for a week or three 'cause I am expecting a bunch more packages to be affected at this point.

What is funny is again how many "young developers" had fun at old timers package managers like Debian being so slow to release new versions of packages.

But never ever anyone was rooted because of malware that was snuck into an official .deb package.

That was the concept of "stable" in the good old time, when software was really an "engineering" field.

How do these things mostly happen for npm? Why not (much) PyPI or Maven? Or do they?

Related. Others?

We all dodged a bullet - https://news.ycombinator.com/item?id=45183029 - Sept 2025 (273 comments)

NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 - Sept 2025 (719 comments)

> ... One of the maintainers read through this text and found it somewhat reasonable. He followed the link (now defunct) to a website hosted under the domain npmjs.help. This website contained a pixel-perfect copy of the npmjs.com website. He logged in using the duckdb_admin user and password, followed by 2FA. Again, the user profile, settings etc. were a perfect copy of the npmjs.com website including all user data. As requested by the email, he then re-set the 2FA setup.

This is absolutely wild that this did not raise _any_ red flags to this person.

red flag: random reset for 2FA ??? red flag: npmjs.help ??? red flag: user name and password not autofilled by browser ??? red flag: copy and pasting u/p combo into phishing site

If _developers_ can't even get this right. Why do we expect dumb users to get this right? We are so cooked.

For critical infra projects like this, making a release should require at least three signatures from different maintainers. In fact, I am surprised that this is not a common practice.

Should enforce passkeys not 2FA

Is there a way to configure npm that it only installs packages that are, like, a week old?

Using Security Keys/FIDO2 instead of TOTP codes completely solves trivial phishing attacks like this one.

npm actually does send these emails. They are about setting up 2FA though. And never have this sense of urgency.

"Hi, XXXX! It looks like you still do not have two-factor authentication (2FA) enabled on your npm account.

To enable 2FA, please follow the instructions found here."

I hate the janky password manager browser extensions but at least they make it hard to make this mistake.

Is it just me who think this could have been prevented if npm admins put in some sort of cool off period to only allow new versions or packages to be downloaded after being published by "x" amount of hours? This way the npm maintainer would get notifications on their email and react immediately? And if it is urgent fix, perhaps there can be a process to allow npm admin to approve and bypass publication cool off period.

Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here

Why the hell we use npm,

Every dependency is a backdoor, To make them malicious it only take s a small slip up

Serious question, how did the attacking site (npmjs.help) know the victim's 2fa? ie. How did they know what phone number to send the 2fa request to?

Comes with the territory considering that npm is defacto the number one enshittification dependency by now. But no worries - this will scale beautifully.

downvotes appreciated but also happy to see one or two urls that would prove me wrong

> malicious code to interfere with cryptocoin transactions

Any idea what the interference was?

Publishing could require clicking an email confirmation link, sent by npm.

> An attacker published new versions of four of duckdb’s packages that included malicious code to interfere with cryptocoin transactions

How can anyone publish their packages?

> This website contained a pixel-perfect copy of the npmjs.com website

This should not be considered high effort or a sophisticated attack. The attacker probably used a mitm proxy which can easily replicate every part of your site, with very little initial configuration. Evilginx is the most popular one I could think of

Disclosure: I'm the founder of https://socket.dev.

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.