HN Reader

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated.

This happened even if you had pinned dependencies and were on top of security updates.

We need some deeper changes in the ecosystem.

https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7...

>Saved by procrastination!

Seriously, this is one of my key survival mechanisms. By the time I became system administrator for a small services company, I had learned to let other people beta test things. We ran Microsoft Office 2000 for 12 years, and saved soooo many upgrade headaches. We had a decade without the need to retrain.

That, and like other have said... never clicking links in emails.

That post fails to address the main issue, its not that we don't have time to vet dependencies, its that nodejs s security and default package model is absurd and how we use it even more. Even most deno posts i see use “allow all” for laziness which i assume will be copy pasted by everyone because its a major pain of UX to get to the right minimal permissions. The only programming model i am aware if that makes it painful enough to use a dependency, encourages hard pinning and vetted dependency distribution and forces explicit minimal capability based permission setup is cloudflares workerd. You can even set it up to have workers (without changing their code) run fully isolated from network and only communicate via a policy evaluator for ingress and egress. It is apache licensed so it is beyond me why this is not the default for use-cases it fits.

Dodged a bullet indeed

I find it insane that someone would get access to a package like this, then just push a shitty crypto stealer.

You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit?

You can exfiltrate API keys, add your SSH public key to the server then exfiltrate the server's IP address so you can snoop in there manually, if you're on a dev's machine maybe the browser's profiles, the session tokens common sales websites? My personal desktop has all my cards saved on Amazon. My work laptop, depending on the period of my life, you could have had access to stuff you wouldn't believe either.

You don't even need to do anything with those, there's forums to sell that stuff.

Surely there's an explanation, or is it that all the good cybercriminals have stable high paying jobs in tech, and this is what's left for us?

Not a security expert but I don’t think that requesting a reset of your 2FA credentials is reasonable.

I would be very worried about my 2FA provider if they asked me to do this.

And so I would not rate this phishing email a 10/10 at all.

I know this isn't really possible for smaller guys but larger players (like NPM) really should buy up all the TLD versions of "npm" (that is: npm.io, npm.sh, npm.help, etc). One of the reasons this was so effective is that the attacker managed to snap up "npm.help"

As the post mentions wallets like MetaMask being the targets, AFAIK MetaMask in particular might be one of the best protected (isolated) applications from this kind of attack due to their use of LavaMoat https://x.com/MetaMask/status/1965147403713196304 -- though I'd love to read a detailed analysis of whether they actually are protected. No affiliation with MetaMask, just curious about effectiveness of seemingly little adopted measures (relative to scariness of attacks).

Added: story dedicated to this topic more or less https://news.ycombinator.com/item?id=45179889

"there is no way to prevent this", says the only ecosystem where this regularly happens

> If you were targeted with such a phishing attack, you'd fall for it too and it's a matter of when not if. Anyone who claims they wouldn't is wrong.

I like to think I wouldn't. I don't put credentials into links from emails that I didn't trigger right then (e.g. password reset emails). That's a security skill everyone should be practicing in 2025.

Really feels like these big open packages repos need a better security solution. Or at least a core subset of carefully vetted ones.

Same issue with python, rust etc. It’s all very trust driven

Now imagine if someone combined Jia Tan patience with swiss-cheese security like all of our editor plugins and nifty shell user land stuff and all that.

Developer stuff is arguably the least scrutinized thing that routinely runs as mega root.

I wish I could say that I audit every elisp, neovim, vscode plugin and every nifty modern replacement for some creaky GNU userland tool. But bat, zoxide, fzf, atuin, starship, viddy, and about 100 more? Nah, I get them from nixpkgs in the best case, and I've piped things to sh.

Write a better VSCode plugin for some terminal panel LLM gizmo, wait a year or two?

gg

Is it possible to do the thing proposed in the email without clicking the link?

I just try to avoid clicking links in emails generally...

Related. Others?

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware - https://news.ycombinator.com/item?id=45179939 - Sept 2025 (209 comments)

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

It seems to me that having an email client that simply disables all the links in the email is probably a good idea. Or maybe, there should be explicit white-listing of domains that are allowed to be hyperlinks.

“We all dodged a massive bullet”

I don’t think we did. I think it is entirely plausible that more sophisticated attacks ARE getting into the npm ecosystem.

> These kinds of dependencies are everywhere and nobody would even think that they could be harmful.

Tons of people think these kind of micro dependencies are harmful and many of them have been saying it for years.

His email client even puts a green check mark next to the fake NPM email. UX fail.

> With that in mind, at a glance the idea of changing your two-factor auth credentials "for security reasons" isn't completely unreasonable.

No?

How do you change your 2FA? Buy a new phone? A new Yubikey?

> all the malware did was modify the destination addresses of cryptocurrency payments mediated via online wallets like MetaMask

A clarification: Despite MetaMask depending on the compromised packages it was not directly affected because: 1) packages were not updated while the compromise was live 2) MetaMask uses LavaMoat for install-time and run-time protections against compromised packages

However the payload did attempt to compromise other pages that interact with wallets like MetaMask.

Disclaimer: I worked on LavaMoat

LavaMoat: https://github.com/lavamoat/lavamoat

I don't know what series of events transpired that resulted in common, slightly irregular use of the word "kindly" by scammers, but I'm glad it happened. Immediate red flag, every time.

How would any normal person know that npmjs.help is phising, but npmjs.com is valid?

“A utility function that determines if its argument can be used like an array”

I see the JavaScript ecosystem hasn’t changed since leftpad then.

"Batteries included" ecosystems are the ultimate defense against the dark arts. Your F100 first party vendor might get it wrong every now and then, but they have so much more to lose than a random 3rd party asshole who decides to deploy malicious packages.

The worst thing I can recall from the enterprisey ecosystems is the log4j exploit, which was easily one of the most attended to security problems I am aware of. Every single beacon was lit for that one. It seems like when an NPM package goes bad, it can take a really long time before someone starts to smell it.

We need a permission system for packages just like with Android apps. The text coloring package suddenly needs a file access permission for the new version? Seems strange.

I had a minor scare some time ago with npm. Can't remember the exact details, something like I had a broken symlink in my homedir and nodemon printed an error about the symlink! My first thought was it's a supply chain attack looking for credentials!

Since then I've done all my dev in an isolated environment like a docker container. I know it's possible to escape the container, but at least that raises the bar to a level I'm comfortable with.

This has so many dimensions.

An authentication environment which has gotten so complex we expect to be harassed by messages say "your Plex password might be compromised", "your 2FA is all fucked up", etc.

And the crypto thing. Xe's sanguine about the impact, I mean, it just the web3 degens [1] that are victimized, good innocent decent people like us aren't hurt. From the viewpoint of the attacker it is all about the Benjamins and the question is: "does an attack like this make enough money to justify the effort?" If the answer is yes than we'll see more attacks like this.

There are just all of these things that contribute to the bad environment: the urgent emails from services you barely use, the web3 degens, etc.

[1] if it's an insult it is one the web3 community slings https://www.webopedia.com/crypto/learn/degen-meaning/

We haven't been saved by procrastination. We literally were saying "oh that's a new version, we are always behind anyway". Of course everything was still checked, but actually having the latest version on packages is almost never needed and we rather update when we have to (because version is old) instead of when there is a new version. Nothing new is that awesome.

At this super-wide level of near-miss, you must assume Jia Tan 3.0 will be coming for your supply chains.

In case you missed it:

NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 - Sept 2025 (697 comments, including exemplary comments from the project maintainer)

For a very long time I have also used unique emails for each respective service that involves in email. When I sign up for npm it is something like email_npm@example.com . This makes it very easy to whitelist and also spot phishing emails because if an email for npm is coming to mail_cccoffee@example.com it screams that something is wrong. It is not bulletproof by any means but an additional layer that costs me almost nothing but requires effort on the part of attackers.

Stuff like this is why I stay away from everything that touches NPM, but I guess not everyone has the freedom to make that decision.

Gmail could have easily placed a red banner like

> "Warning! This is the first time you have received a message from sender support@npmjs.help. Please be careful with links and attachments, and verify the sender's identity before taking any action."

Sometimes I think I'm a stubborn old curmudgeon for staunchly refusing to use node, npm, and the surrounding ecosystem. Pick and choose specific packages if I really have to.

Then there's days like this.

>> It sets a deadline a few days in the future. This creates a sense of urgency, and when you combine urgency with being rushed by life, you are much more likely to fall for the phishing link.

Procrastination is a security strategy.

Agree with most that this could have been way way worse. No doubt next time it will be.

I keep expecting some new company to bring out this revolutionary idea of "On prem: your machine, your libraries, your business."

This article makes one faulty assumption that I think is really common - the author says it could be much worse, which implicitly assumes that we have noticed and caught every other time something like this has happened.

Internally, we only noticed this because it caused a bunch of random junk to get barfed out into some CI logs.

You really can’t say that nobody has ever done this better. Maybe they just did it so well that nobody noticed.

Would recommend less click-baity: "NPM attack - we all dodged a bullet"

I wrote the first commit for slice-ansi in 2015 to solve a baby problem for a cli framework I was building, and worked with Qix a little on the chalk org after it. It's wild looking back and seeing how these things creep in influence over time.

Does the Go ecosystem have a similar security screening process as NPM? This was caught because a company was monitoring a centralized packaging distribution platform, but I worry about all those golang modules spread across GitHub without oversight..

Trying to read this on Brave on Android and I couldn't get past Anubis. Does anyone else observe the same?

Great write up. I can understand the indignation at the exploit, but I believe it’s an A+ exploit for the chosen attack vector.

Not only is it “proof of concept” but it’s a low risk high reward play. It’s brilliant really. Dangerously so.

> Even then, that wouldn't really stand out to me because I've seen companies use new generic top level domains to separate out things like the blog at .blog or the docs at .guide, not to mention the .new stack.

This is very much a 'can we please not' situation, isn't it? (Obviously it's not something that the email recipients can (usually) control, so it's not a criticism of them.) It also has to meaningfully increase the chance that someone will eventually forget to renew a domain, too.

"saved by procrastination!" made me smile.

One of the common cases of being offline first, disconnected etc. pays off.

Don't rush. Work on Hawaiian clock!

Always use password manager to automatically fill in your credentials. If password manager doesn't find your credentials, check the domain. On top of that, you can always go directly to the website, to make any needed changes there, without following the link.

Dat domain name.

Yeah, stop those cute domain names. I never got the memo on Youtu.be, I just had “learn” it was okay. Of course people started to let their guard down because dumbasses started to get cute.

We all did dodge a bullet because we’ve been installing stuff from NPM with reckless abandon for awhile.

Can anyone give me a reason why this wouldn’t happen in other ecosystems like Python, because I really don’t feel comfortable if I’m scared to download the most basic of packages. Everything is trust.

"A little duplication is better than a little dependency"

- Golang Proverb (also applies to any other programming language...)

There's only one thing that would throw me off this email and that is DMARC. But I didn't get the email, so who is to say if I actually would have been caught.

Lazy conclusion. People can and have been validating dependencies. We need an npm proxy with validated dependencies.

WebAuthN/fido/passkey should be mandatory to publish a package with >N downloads. Email and TOTP codes can be MITMd.

`Object.getPrototypeOf(obj)[Symbol.iterator] !== undefined`

There I fixed it. Now I don't even need the package array-ish!

How much money did the attackers make?

> One of the important things to take away from this is that every dependency could be malicious. We should take the time to understand the entire dependency tree of our programs, but we aren't given that time. At the end of the day, we still have to ship things.

That's why you need vuln scanners and not upgrade to the latest thing as soon as released.

Not all of us

This reads like a joke that's missing the punchline.

The post's author's resume section reinforces this feeling:

I am a skilled force multiplier, acclaimed speaker, artist, and prolific blogger. My writing is widely viewed across 15 time zones and is one of the most viewed software blogs in the world.

I specialize in helping people realize their latent abilities and help to unblock them when they get stuck. This creates unique value streams and lets me bring others up to my level to help create more senior engineers. I am looking for roles that allow me to build upon existing company cultures and transmute them into new and innovative ways of talking about a product I believe in. I am prioritizing remote work at companies that align with my values of transparency, honesty, equity, and equality.

If you want someone that is dedicated to their craft, a fearless innovator and a genuine force multiplier, please look no further. I'm more than willing to hear you out.

Why is it always NPM?

Allowing just anybody to rent npmjs.help feels like aiding and abetting.

This phishing email is full of red flags. Here are example red flags from that email:

- Update your 2FA credentials

What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.

- It's been over 12 months since you last 2FA update

Again - meaningless nonsense. There's no such thing as a 2FA update. Maybe the recipient was thinking "password update" - but updating passwords regularly is also bad practice.

- "Kindly ask ..."

It would be very unusual to write like that in a formal security notification.

- "your credentials will be temporarily locked ..."

What does "temporarily locked" mean? That's not a thing. Also creating a sense of urgency is a classic phishing technique and a red flag.

- A link to change your credentials

A legit security email should never contains a link to change your credentials.

- It comes from a weird domain - .help

Any nonstandard domain is a red flag.

I don't use NPM, and if this actually looks like an email NPM would send, NPM has serious problems. However security ignorant companies do send emails like this. That's why the second layer of defense if you receive an email like this and think it might be real is to just log directly into (in this case) NPM and update your account settings without clicking links in the email.

NEVER EVER EVER click links in any kind of security alert email.

I don't blame the people who fell for this, but it is also concerning that there's such limited security awareness/training among people with publish access to such widely used packages.

Wow! This site uses anubis with the meta-refreshed based challenge that doesn't require javascript. So I can actually read the article in my old browser. It's so rare for anubis deployals to be setup with any configuration beyond the defaults. What a delight.

Most phishing emails are so bad, it’s quite terrifying when you see a convincing one like this.

Email is such an utter shitfest. Even tech-savvy people fall for phishing emails, what hope do normal people have.

I recommend people save URLs in their password managers, and get in the habit of auto-filling. That way, you’ll at least notice if you’re trying to log into a malicious site. Unfortunately, it’s not foolproof, because plenty of sites ask you to randomly sign into different URLs. Sigh…

> Formatting text with colors for use in the terminal ... > These kinds of dependencies are everywhere and nobody would even think that they could be harmful.

The first article I ever read discussing the possibility of npm supply chain attacks actually used coloured text in terminal as the example package to poison. And ever since then I have always been associated coloured terminal in text with supply chain attack

Is there a tool that you can put between your npm client and npm web servers that serves package versions that are month old and possibly also tracks discovered malware and never serves infected versions?

We didn't dodge anything, this is just 1 of 1000 publicly found and reported on

The problem here is that a single dev account can make updates to a prod codebase, or in the case of NX a single CI/CD token. Something with 5 Million downloads per week should not be controlled by one token if it takes me 3 approvals to get my $20 lunch reimbursement. At the very least have an LLM review every PR to prod.

Why are furries smart? It's like God telling us "yes, but...."

> bluesky useooooors >furry >sexual nickname

The is the main reason why if you ever get a password reset email you ALWAYS go to the site directly and NEVER through the link provided in the email.

It's typical phishing email... and if the author when though any type of cybersecurity training, they would see that the email wasn't that great.

The sense of urgency is always the red flag.

Daily reminder that no one can easily impersonate you if you sign your commits and make it easy to discover and verify your authentic key with keyoxide or similar.

My open source projects were not affected but close call. I was using 2 of the dependencies (as sub-dependencies) but older versions. Seems that my philosophy of minimizing the number of dependencies and looking up dependency authors is paying off.

I saw this kind of thing coming years ago. I never understood why people were obsessed with using tiny dependencies to save them 4 lines of code. These useless dependencies getting millions of weekly downloads always seemed very suspicious to me.

I might need bloggers to not use "web 3" as a term.

With the way things are going, I can't tell at a glance whether they mean crypto, VR, or AI when they say "web 3."

Related:

NPM debug and chalk packages compromised

https://news.ycombinator.com/item?id=45169657

wow - people still get fooled by _phishing_ emails? I understand aging boomers with decreasing visual acuity, and deteriorating me tal state. But, the younger generations falling for these spearfish email attempts is wild.

We are cooked.

Isn't it a bit crazy that phishing e-mails still exist? Like, couldn't this be solved by encrypting something in a header and using a public key in the DNS to unencrypt it?

Besides the ecosystem issues, for the phishing part, I'll repost what I responded somewhere in the other related post, for awareness

---

I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA:

TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough.

I don't understand how most of the anti-phishing advice focuses on that, it's useless to borderline counter-productive.

What really helps against phishing :

1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try.

2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not.

That is all there is. Any other method, any other "indicator" helps but is error-prone, which means someone somewhere will get phished eventually. Particularly if stressed, tired, or in a hurry. It just happened to be you this time.

> This post and its online comment sections are blame-free zones

The author is claiming control over other comment sections? Where is this entitlement coming from? They hide that behind some fictional persona, as if that changes anything.

The author then proceeds to list several reasons someone would fall for this, carefully ignoring the most important detail of the email, being its address. The absolute very first step of detecting email phishing is looking at the address.

Obviously the blame is on NPM for having a system that can be defeated by clicking a bad email, but the JS ecosystem has no interest in doing things right and there's no point in putting our heads in the sand about basic security practices.

Article:

> This is frankly a really good phishing email ... This is a 10/10 phishing email ..

Phishing email:

> As part of our on going commitment to account security, we are requesting that all users update their Two-Factor-Authentication (2FA) credentials ...

What does that even mean? What type of 2FA needs updating? One 2FA method supported is OTP. Can't see a reason that would legitimately ever need to be updated, so doesn't really pass the sniff test that every single user would need to "update 2FA".

Is this not a good use case for AI in your email client (local-only to avoid more opportunities for data to leak)?

Have the client-embedded AI view the email to determine if it contains a link to a purported service. Remotely verify if the service URL domain is valid, by comparing to the domains known for that service

If unknown, show the user a suspected phishing message.

This will occasionally give a false positive when a service changes their sending domain, but the remote domain<->service database can then be updated via an API call as a new `(domain, service)` pair for investigation and possible inclusion.

I feel like this would mitigate much of the risk of phishing emails slipping past defenses, and mainly just needs 2 or 3 API calls to service once the LLM has extracted the service name from the email.