We all dodged a bullet
xeiaso.net
Related: NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657
xeiaso.net
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...
I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason.
As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage.
NPM will often have different source then the github repo source. How does anyone even trust the system?
I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix.
No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.
The difficulty comes in trying to change the entire culture.
“Stop doing that!”
“But I wanna!”
Other languages has similar package managers as npm, but with much less issues, so it can be fixed without changing the package manager completely.
It is an ecosystem and culture that learned nothing from the debacle of left pad. And it is an affliction that many organizations face and it is only going to get worse with the advent of AI assisted coding (and it does not have to be).
There simply arent enough adults in the room with the ability to tell the children (or VC's and business people) NO. And getting an "AI" to say no is next to impossible unless you're probing it on a "social issue".
And before you know it, you have a multitude of distributions to choose from, each with their own issues...
Source available beats open source from a security perspective.
The alternative is C++, where every project essentially starts by reinventing the wheel, which comes with its own set of vulnerabilities.
I'm saying this without a clear idea of how to fix this very real problem.
Sure, in 1995.
Most C++ projects nowadays belong to some fairly well understood domain and for every broad domain there is usually one or two large 'ecosystem' libraries that come batteries included. Huge monolithic dependency with well stablished governance instead of 1000 small ones.
Examples of such ecosystems are Qt, LLVM, ROOT, tensorflow, etc. For smaller projects that want something slightly more than a standard library but not belonging to a clear ecosystem like the above you have boost, folly, abseil, etc.
Most of these started by someone deciding to reinvent the wheel decades ago, but there's no real reason to do that in 2025.
None of it will help you when you're executing the binaries you built, regardless of which language they were written in.
Lavamoat would, if you get to the point of running your program with lavamoat-node or built with the lavamoat webpack plugin: https://lavamoat.github.io/guides/getting-started/
Sure it would... isn't that the whole point of Deno? The binary can't exfiltrate anything if you don't let it connect to the net.
The obscurity of languages other than JavaScript will only work as a security measure for so long.
Whenever you download an open-source program and you don't have to compile it first, you're at risk of running code that is not necessarily what's in the publicly-available source code.
This can even apply to source code itself when distributed through two different channels, as we saw in the xz backdoor attempt. (The release tarball contained different code to the repository.)
I don't know anything about the npm ecosystem, what's the benefit of importing these libraries compared to including these code in the project?
I am a consumer of apps using npm, not a developer, and I simply don’t like the auto updates and seeing a zillion things updated. I use uv and Python a lot, and I get a similar uneasy feeling there also, but (perhaps incorrectly) I feel more in control.
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.
"Hey, is it still broken? No? Great!"
Better defense would be to delete or quarantine the compromised versions, fail to build and escalate to a human for zero-day defense.
Reading the code content of emergency patches should be part of the job. Of course, with better code trust tools (there seem to have been some attempts at that lately, not sure where they’re at), we can delegate that and still do much better than the current state of things.
They stop working before can use them.
> A zero-day exploit is a cyberattack vector that takes advantage of an unknown or unaddressed security flaw in computer software, hardware or firmware. "Zero day" refers to the fact that the software or device vendor has zero days to fix the flaw because malicious actors can already use it to access vulnerable systems.
If I never install the infected software, I'm not vulnerable, even if no one knows of its existence.
That said, you could argue that because it's a zero day and no one caught it, it can lie dormant for >2 weeks so your "just wait awhile" strategy might not work if no one catches it in that period.
But if you're a hacker, sitting on a goldmine of infected computers... do you really want to wait it out to scoop up more victims before activating it? It might be caught.
No one bothers finding 0-days in software which no one has installed.
https://docs.renovatebot.com/configuration-options/#minimumr...
Renovate uses signals like your CI to work out whether things break before an automerge occurs - does that mean your CI didn't catch the breakage? Or something I've missed?
(there's also the "merge confidence" that can help here)
(I'm soon to be working at Mend on Renovate full time)
Dependabot has recently added this functionality too - it's called `cooldown`
https://docs.github.com/en/code-security/dependabot/working-...
(I'm soon to be working at Mend on Renovate full time, but have been a big fan of Renovate over other tools for years)
Such a feature can be added.
At $PAST_DAYJOB we've adopted Docker "only" around 2016, and importantly, we've used it almost identically to how we used to deploy "plain" uWSGI or Apache apps: a bunch of VMs, run some Ansible roles, pull the code (now image), restart, done.
The time to move to k8s is when you have a k8s-sized problem. [Looks at Github: 760 releases, 3866 contributors.] Yeah, not now.
If you're worried about vulnerabilities in older software these days, Windows has built-in security features that can help with that, from the sandbox to controlled folders access (intended for ransomware protection, I believe; I use it to prevent my media server from modifying tags)
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?
Because the way this was pulled off, it was going to be found out right away. It wasn't a subtle insertion, it was a complete account take over. The attacker had only hours before discovery - so the logical thing to do is a hit and run. They asked what is the most money that can be extracted in just a few hours in an automated fashion (no time to investigate targets manually one at a time) and crypto is the obvious answer.
Unless the back doors were so good they weren't going to be discovered even though half the world would be dissecting the attack code, there was no point in even trying.
That could have netted the attacker something much more valuable, but it is pure hit or miss and it requires more skill and patience for a payoff.
VS blast out some crypto stealing code and grab as many funds as possible before being found out.
> Lots of people/organisations are going to be complacent and leave you with valid credentials
You'd get non-root credentials on lots of dev machines, and likely some non-root credentials on prod machines, and possibly root access to some poorly configured machines.
Two factor is still in place, you only have whatever creds that NPM install was ran with. Plenty of the really high value prod targets may very well be on machines that don't even have publicly routable IPs.
With a large enough blast radius, this may have worked, but it wouldn't be guaranteed.
And very, very happy that we're proxying all access to npm through Artifactory, which allowed us to block the affected versions and verify that they were in fact never pulled by any of our builds.
It might get missed, but I sure notice any time account emails come through even if it's not saying "your password was reset."
is that so? from the email it looks like they MITM'd the 2FA setup process, so they will have qix's 2FA secret. they don't have to immediately start taking over qix's account and lock him out. they should have had all the time they need to come up with a more sophisticated payload.
A decade ago my root/123456 ssh password got pwned in 3-4 days. (I was gonna change to certificate!)
Hetzner alerted me saying that I filled my entire 1TB/mo download quota.
Apparently, the attacker (automation?) took over and used it to scrape alibaba, or did something with their cloud on port 443. It took a few hours to eat up every last byte. It felt like this was part of a huge operation. They also left a non-functional crypto miner in there that I simply couldn't remove.
So while they could cryptolock, they just used it for something insidious and left it alone.
What gets me is everyone acknowledges this, yet HN is full of comments ripping on IT teams for the restrictions & EDR put in place on dev laptops.
We on the ops side have known these risks for years and that knowledge of those risks are what drives organizational security policies and endpoint configuration.
Security is hard, and it is very inconvenient, but it's increasingly necessary.
To wit: I have an open ticket right now from an automated code review tool that flagged a potential vulnerability. I and two other seniors have confirmed that it is a false alarm so I asked for permission to ignore it by clicking the ignore button in a separate security ticket. They asked for more details to be added to the ticket, except I don’t have permissions to view the ticket. I need to submit another ticket to get permission to view the original ticket to confirm that no less than three senior developers have validated this as a false alarm, which is information that is already on another ticket. This non-issue has been going on for months at this point. The ops person who has asked me to provide more info won’t accept a written explanation via Teams, it has to be added to the ticket.
Stakeholders will quickly treat your entire security system like a waste of time and resources when they can plainly see that many parts of it are a waste of time and resources.
The objection isn’t against security. It is against security theater.
It might not be sensible for the organization as a whole, but there’s no way to determine that conclusively, without going over thousands of different possibilities, edge cases, etc.
I have already documented, in writing, in multiple places, that the automated software has raised a false alarm, as well as providing a piece of code demonstrating that the alert was wrong. They are asking me to document it in an additional place that I don't have access to, presumably for perceived security reasons? We already accept that my reasoning around the false alarm is valid, they just have buried a simple resolution beneath completely stupid process. You are going to get false alarms, if it takes months to deal with a single one, the alarm system is going to get ignored, or bypassed. I have a variety of conflicting demands on my attention.
At the same time, when we came under a coordinated DDOS attack from what was likely a political actor, security didn't notice the millions of requests coming from a country that we have never had a single customer in. Our dev team brought it to their attention where they, again, slowed everything down by insisting on taking part in the mitigation, even though they couldn't figure out how to give themselves permission to access basic things like our logging system. We had to devote one of our on calls to walking them through submitting access tickets, a process presumably put in place by a security team.
I know what good security looks like, and I respect it. Many people have to deal with bad security on a regular basis, and they should not be shamed for correctly pointing out that it is terrible.
The ops person obviously can’t do that on your behalf, at least not in any kind of organizational setup I’ve heard of.
So the solution to an illogical, kafkaesque security process is to bypass the process entirely via authority?
You are making my argument for me.
This is exactly why people don’t take security processes seriously, and fight efforts to add more security processes.
Edit: I didn’t comment on all those other points, so it seems irrelevant to the one question I asked.
Ops are the ones who imposed those constraints. You can't impose absurd constraints and then say you are acting reasonable by abiding by your own absurd constraints.
I'm not dumping on the ops person, but the ops and security team's processes. If you as a developer showed up to a new workplace and the process was that for every code change you had to print out a diff and mail a hard copy to the committee for code reviews, you would be totally justified in calling out the process as needlessly elaborate. Anyone could rightly say that your processes are increasing friction while not actually serving the purpose of having code reviewed by peers. You as a developer have a responsibility to point out that the current process serves no one and should be changed. That's what good security and ops people do too.
In the real world case I am talking about, we can easily foresee that the end result is that the exemption will be allowed, and there will be no security impact. In no way does the process at all contribute to that, and every person involved knows it.
My original post was about how people dislike security when it is actually security theater. That is what is going on here. We already know how this issue ends and how that can be accomplished (document the false alarm, and click the ignore button), and have already done the important part of documenting the issue for posterity.
The process could be: you are a highly paid developer who takes security training and has access to highly sensitive systems so we trust your judgment, when you and your peers agree that this isn't an issue, write that down in the correct place, click the ignore button and move on with your work.
All of the faff of contacting different fiefdoms and submitting tickets does nothing to contribute to the core issue or resolution, and certainly doesn't enhance security. If anything, security theater like this leads to worse security since people will try to find shortcuts or ways of just not handling issues.
All their EDR crud runs on Windows, but as a dev I'm allowed to run WSL but the tools do not reach inside WSL so if that gets compromised they would be none the wiser.
There is some instrumentation for linux servers and cloud machines, but that too is full of blind spots.
And as a sibling comment says, a lot of the policies are executed without anyone being able to explain their purpose, being able to grant "functionally equivalent security" exceptions or them even making sense in certain contexts. It feels like dealing with mindless automatons, even though humans are involved. For example a thing that happened a while ago: We were using scrypt as KDF, but their scanning flagged it as unknown password encryption and insisted that we should use SHA2 as a modern, secure hashing function. Weeks of long email threads, escalation and several managers suggesting "just change it to satisfy them" followed. That's a clear example of mindless rule-following making a system less secure.
Blocking remote desktop forwarding of security keys also is a fun one.
Putting it another way: if I'm a random small-time burglar who happens to find himself in Walter White's vault, I'm stuffing as much cash as I can fit into my bag and ignoring the barrel of methylamine.
The damage from this hack could have been far worse if it was stealing real money people rely on to feed their kids.
Sure, if someone takes my grocery money, that’s a real loss, and that’s why I don’t carry large sums of cash. But that isn’t what happened here.
Can you explain what you meant so I can understand? I think you had a point, I just don’t think that the risk of the kind of attack in TFA is comparable to someone getting their grocery money stolen, because the financial situation for that individual in-person theft can’t really occur on the same scale as the attack in TFA, and even if it could, that’s kind of on the end user for carrying more cash than they can defend.
Not always. Many banks will claim e.g. they don't have to cover losses from someone who opened a phishing email, never mind that the bank themselves sends out equally suspicious "real" emails on the regular.
Also even if it's covered that money comes from somewhere - ultimately out of the pockets of regular folks who were just using their bank accounts, even if the insurance mechasims mean it's spread out more widely.
https://techcrunch.com/2018/02/16/zelle-users-are-finding-ou...
It appears they still have issues with (more advanced forms of) fraud:
https://thecyberexpress.com/zelle-lawsuit-2025-scam-hit-us-f... (this page won't stop reloading, but I think it's my adblock configuration) https://www.morningstar.com/news/marketwatch/20241221198/mor...
The plot of Office Space might offer clues.
Also isn't it crime 101 that greedy criminals are the ones who are more likely to get caught?
Even if you steal other stuff, you're going to need to turn it all into cryptocurrency anyway, and how much is an AWS key really going to bring in.
There are criminals that focus on extracting passwords and password manager databases as well, though they often also end up going after cryptocurrency websites.
There are probably criminals out there biding their time, waiting for the perfect moment to strike, silently infiltrating companies through carefully picked dependencies, but those don't get caught as easily as the ones draining cryptocurrency wallets.
> one-in-a-million opportunity
step 1: live in a place where the cops do not police this type of activity
step 2: $$$$
A couple hundred grand is not what these attackers are after.
For anything else you need a fiat market, which is hard to deal with remotely.
But (1) how do you do that with hundreds or thousands of SSH/API keys and (2) how do you actually make money from it?
So you get a list of SSH or specific API keys and then write a crawler that can hopefully gather more secrets from them, like credit card details (how would that work btw?) and then what, you google "how to sell credentials" and register on some forum to broker a deal like they do in movies?
Sure sounds a hell of a lot more complicated and precarious than swapping out crypto addresses in flight.
OTOH, this modus operandi is completely inconsistent with the way they published the injected code: by taking over a developer's account. This was going to be noticed quickly.
If the payload had been injected in a more subtle way, it might have taken a long time to figure out. Especially with all the levenshtein logic that might convince a victim they'd somehow screwed up.
nobody cares about your trade secrets, or some nation's nuclear program, just take the crypto
Consumer financial fraud is quite big and relatively harmless. Industrial espionage, otoh, can potentially put you in the cross hairs of powerful and/or rouge elements, and so, only the big actors get involved, but in a targeted way, preferring to not leave much if any trace of compromise.
In the case of North Korea, it's really crazy because hackers over there can do this legally in their own country, with the support of their government!
And most popular npm developers are broke.
You wouldn't get targeted not because they cant but its not worth it
many state sponsored attack is well documented in a lot of book that people can read they don't want to add much record because its create buzz
Your ideas are potentially lubricative over time, but first it creates more work and risk for the attacker.
The attacker had access to the user's npm repository only.
Also, you underestimate how trivial this 'one-in-a-million opportunity' is; it's definitely not a one-in-a-million! Almost anybody with basic coding ability and a few thousand dollars could pull off this hack. There are thousands of libraries which are essentially worthless with millions of downloads and the author who maintains is basically broke and barely uses their npm account anymore. Anybody could just buy those npm accounts under false pretenses for a couple of thousands and then do whatever they want with tens of thousands (or even hundreds of thousands) of compromised servers. The library author is legally within their rights to sell their digital assets and it's not their business what the acquirer does with them.
But in the end, we should all rely on fewer dependencies. It's certainly the philosophy I'm trying to follow with https://mastrojs.github.io – see e.g. https://jsr.io/@mastrojs/mastro/dependencies
If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?). The rust tool will have three or four, the JavaScript over ten, sometimes ten alone to help with just building the typescript in dev. Worsened by the JavaScript dependencies own deps (and theirs, and theirs, all the way down to is_array or left_pad). Easily getting in the hundreds. In rust, that graph will list maybe ten more. Or, with some complex libraries, a total of several tens.
This attitude difference is also clear in Python community. Where the knee-jerk reaction is to add an import, rather than think it through, maybe copy paste a file, and in any case, being very conservative. Do we really need colors in the terminal output? We do? Can we not just create a file with some constants that hold the four ANSI escape codes instead?
I'm trying to argue that there's also an important cultural problem with supply chain attacks to be considered.
This has more to do with the popularity of a language than anything else, I think. Though the fact that Python and JS are used as "entry level" languages probably encourages some of these "lazy" libraries cough cough left-pad cough cough.
I object. You can get a full-blown web app rolling with Django alone. Here's it's list of external dependencies, including transitive: asgiref, sqlparse, tzdata. (I guess you can also count jQuery, if you're using the _builtin_ admin interface.)
The standard library is slowly swallowing the most important libraries & tools in the ecosystem, such as json or venv. What was once a giant yield-hack to get green threads / async, is now a part of the language. The language itself is conservative in what new features it accepts, 20yro Python code still reads like Python.
Sure, I've worked on a Django codebase with 130 transitive dependencies. But it's 7yro and powers an entire business. A "hello world" app in Express has 150, for Vue it's 550.
Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to expropriate the National Association of Pastoral Musicians. Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?
At least they're paying dozens of millions to buy a shitty ass .google that noone cares about because more and more browsers are hiding the URL bar. I'm glad ICANN can use it to buy drinks, hookers instead of being useful.
And then never even did anything with it.
I think you and I have drastically different ideas about how dramatic a response is warranted by the scenario of needing to buy a domain with a different three letters or maybe even four or more letters before the TLD.
> Dare I remind you that the whole left-pad situation was because Kik, the company, stole (with NPM's assistance because they were big enough and friends with the right people) the kik package ?
...and then the package was entirely removed, which would have been preventable by sane policies around making removal just not allow new dependencies to use it. You're also conflating a resource that's ostensibly free and perpetual for people to claim with one that's only rented for fixed periods of time for money.
That looks like a phishing attempt from someone using a random EC2 instance or something, but apparently it's legit. I think. Even the "heads-up" email they sent beforehand looked like phishing, so I was waiting for the actual invoice to see if they really started using that address, but even now I'm not opening these attached PDFs.
These companies tell customers to be suspicious of phishing attempts, and then they pull these stunts.
Yep. At every BigCo I've worked at, nearly all of the emails from Corporate have been indistinguishable from phishing. Sometimes, they're actual spam!
Do the executives and directors responsible for sending these messages care? No. They never do, and get super defensive and self-righteous when you show them exactly how their precious emails tick every "This message is phishing!" box in the mandatory annual phishing-detection-and-resistance training.
A week later some executive pushing the training emailed the entire company saying that it was unacceptable that nobody from engineering had logged into the training site and spun some story about regulatory requirements. After lots of back and forth they still wouldn't accept that it obviously looked like a phishing email.
Eventually when we actually did the training, it literally told us to check the From address of emails. I sometimes wonder if it was some weird kind of performance art.
“We got pwned but the entire company went through a certified phishing awareness program and we have a DPI firewall. Nothing more we could have done, we’re not liable.”
[0] ...so the payments serve the social function of enriching your buddy and improving your status in the whole favor economy thing...
Our infra guy then had to argue with them for quite a while to just email from their own domain, and that no, we're weren't going to add their cert to our DNS, and let a third party spoof us (or however that works, idk). Absolutely shocking lack of self awareness.
Title: "Expense report overdue - Please fill now"
Subject:
<empty body>
<Link to document trying it's best to look like google's attachment icon but was actually a hyperlink to a site that asked me to log in with my corporate credentials>
---
So like, obviously this is a stupid phishing email, right? Especially as at this time, I had not used my corporate card.
A few weeks later I got the finance team reaching out threatening to cancel my corporate card because I had charges on it with no corresponding expense report filed.
So on checking the charge history for the corporate card, it was the annual tax payment that all cards are charged in my country every year, and finance should have been well aware of. Of course, then the expense system initially rejected my report because I couldn't provide a receipt, as the card provider automatically deducts this charge with no manual action on the card owner's side...
Edit: nvm it seems it's not the case
You can't protect against people clicking links in emails in this way. You might say `npmjs-help.ph` is a phishy domain, but npmjs.help is a phishy domain and people clicked it anyway.
I agree that especially larger players should be proactive and register all similar-sounding TLDs to mitigate such phishing attacks, but they can't be outright prevented this way.
Domain: NPMJS.HELP (85 similar domains)
Registrar: Porkbun, LLC (4.84 million domains)
Query Time: 8 Sep 2025 - 4:14 PM UTC [1 DAY BACK] [REFRESH]
Registered: 5th September 2025 [4 days back]
Expiry: 5th September 2026 [11 months, 25 days left]
> 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.
Any time I feel like I'm being rushed, I check deeper. It would help if everyone's official communications only came from the most well known domain (or subdomain).
Heuristics like this one should be performed automatically by the email client.
Added: story dedicated to this topic more or less https://news.ycombinator.com/item?id=45179889
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.
It would be just as easy to argue that anyone who uses software and hasn't confirmed their security certifications include whatever processes you imagine avoids 'human makes 1 mistake and continues with normal workflow' error or holds updates until evaluated is negligent.
I've had emails like that from various places, probably legitimate, but I absolutely never click the bloody link from an email and enter my credentials into it! That's internet safety 101.
1. Like you, I never put credentials into links from emails that I didn’t trigger/wasn’t expecting. This is a generally-sensible practise.
2. Updating 2FA credentials is nonsense. I don’t expect everyone to know this, this is the weakest of the three.
3. If my credentials don’t autofill due to origin mismatch, I am not filling it manually. Ever. I would instead, if I thought it genuine, go to their actual site and log in there, and then see nothing about what the phish claimed. I’ve heard people talking about companies using multiple origins for their login forms and how having to deal with that undermines this aspect, but for myself I don’t believe I’ve ever seen that, not even once. It’s definitely not common, and origin-locked second factors should make that practice disappear altogether.
Now these three are not of equal strength. The second requires specific knowledge, and a phish could conceivably use something similar that isn’t such nonsense anyway. The first is a best practice that seems to require some discipline, so although everyone should do it, it is unfortunately not the strongest. But the third? When you’re using a password manager with autofill, that one should be absolutely robust. It protects you! You have to go out of your way to get phished!
The problem with this is that companies often send out legit emails saying things like "update your 2FA recovery methods". Most people don't know well enough how 2FA works to spot the difference.
The point of not assigning blame isn't to absolve people of the need to have their guard up but to recognise that everyone is capable of mistakes.
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.
To this day, I don't follow links in other kinds of emails. I mouse over the link to view the domain as a first step in determining how seriously to take the email. If the domain appears to match the known-good one, I copy the link and examine the characters to see if any Unicode lookalikes have been employed.
If the domain seems legitimate, or if I don't recognize it but the email is so convincing that I suspect the company truly is using a different domain (my bank has done this, frustratingly), I still don't click the link. I log in to my account on the known-good domain -- by typing it by hand into the browser's address bar -- and look for notifications.
If there are no notifications, then I might contact the company about the email to verify its authenticity.
If anyone reading thinks that seems like a lot of work, I agree with you! It stinks. But I humbly submit that it's necessary on today's Internet. And it's especially necessary if you're in charge of globally used software libraries.
To adopt the tone of the article's author, if they aren't willing to do that, they're wrong, and they're going to keep getting phished.
I think the vast vast majority of people would have fallen for it, it's a decent looking message, it has a sense of urgency and the domain doesn't look wildly wrong. Devs in theory might be more security aware, but also we work with a lot of different apps, systems and sites - mixed domains, weird deep-links, redirects we've all used (and possibly even deployed) such setups.
Add in most of my email is now through a corporate outlook, so domains aren't very visible it's all nestled behind "safelinks", and personal email is often on a phone so mousing over a link just isn't muscle memory anymore.
I think I'd be suspicious at the request, but possibly have clicked to see more, especially with the threat things might stop working soon. Maybe NPM/package platforms should be pushing security training to their biggest maintainers like your old corporation did, but for now they don't and the idea that people should be more aware of the risk is sort of the point.
Almost anyone would have fallen for that, thats why almost all of us need to be reminded to think of this stuff more.
When a lone developer is untrained and doesn't follow best practices, as happened here, the community rushes to their defense on the grounds of empathy: "We would ALL make this mistake." But what if we wouldn't? What if we're trained and have certain safety protocols and procedures that we hold ourselves to?
This is why, at the end of the day, I run my company on a more centralized ecosystem, for all its warts. At least there's the promise of standard practices and procedures and training, whether it's always perfectly fulfilled or not. With a community-driven ecosystem, you don't have that: You're relying on the standards of the community, a vague and nebulous group that doesn't necessarily have any security sense, as you rightly pointed out. I realize not everyone has the luxury of making that choice due to career/financial constraints.
I think that's overstated. This phishing attempt had some obvious red flags that many people here would have noticed, sure. So not everyone is going to fall for this phish.
But the principle is better expressed as "Everyone will fall for a phish", somewhere. Even you. Human engineering is human engineering and we're all fallible. All that's required is that someone figure out which mistakes you're likely to make.
Same issue with python, rust etc. It’s all very trust driven
The only solution would be to prevent all releases from being applied immediately.
No hardware keys, no new releases.
They have it implemented.
I created NPM account today and added passkey from my laptop and hardware key as secondary. As I have it configured it asked my for it while publishing my test package.
So the guy either had TOTP or just the pw.
Seems like should be easy to implement enforcement.
In the Java world, I know there’s been griping from mostly juniors re “why isn’t Maven easy like npm?” (I work with some of these people). I point them to this article: https://www.sonatype.com/blog/why-namespacing-matters-in-pub...
Maven got a lot of things right back in the day. Yes POM files are in xml and we all know xml sucks etc, but aside from that the stodgy focus on robustness and carefully considered change gets more impressive all the time.
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.
I just try to avoid clicking links in emails generally...
Definitely good practice .
The only real solution is to have domain-bound identities like passkeys.
Always manually open the website.
This week Oracle Cloud started enforcing 2FA. And surely I didn't click their e-mail link to do that.
My theory is that if that companies start using that workflow in the future, it’ll become even _easier_ for users to click a random link, because they’d go “wow! That’s so convenient now!”
I don't just generally try, I _never_ click links in emails from companies, period. It's too dangerous and not actually necessary. If a friend sends me a link, I'll confirm it with them directly before using it.
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
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.
As far as I can tell it isn't a joke per se, but it is tongue-in-cheek and the ego is often very real.
URLs are also getting too damn long
Do you think there would be the time to properly review applications to get on the whitelist?
If it's new, you should be more cautious. Except even those companies that should know better need you to link through 7 levels of redirect tracking, and they're always using a new one.
They could add anti-phish features which force confirmation before clicking a link to an uncommon domain. Startups could pay a nominal fee to get their domain reviewed and whitelisted.
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)
Passkeys are disruptive enough that I don't think they need to be mandated for everyone just yet, but I think it might be time for that for people who own critical dependencies.
Absolutely not.
https://www.malwarebytes.com/blog/news/2025/08/clickjack-att...
https://thehackernews.com/2025/08/dom-based-extension-clickj...
https://www.intercede.com/the-dangers-of-password-autofill-a...
There's strong evidence that the latter is a more common concern.
You don't have to believe me, read the links.
I don’t think we did. I think it is entirely plausible that more sophisticated attacks ARE getting into the npm ecosystem.
Tons of people think these kind of micro dependencies are harmful and many of them have been saying it for years.
Micro-dependencies are not the only thing that went wrong here, but hopefully this is a wakeup call to do some cleaning.
Absolutely. A lot of developers work on a large Enterprise app for years and then scoot off to a different project or company.
What's not fun is being the poor Ops staff that have to deal with supporting the library dependencies, JVM upgrades, etc for decades after.
Upgrading when falling off the train is serious drawback on moving fast..
I didn't think it'll make things perfect, not by a long shot. But it can make the exploits a lot harder to pull off.
If a package wants to access the filesystem, shell, OS API's, sockets, etc., those should be permissions you have to explicitly grant in your code.
function main(io) {
const result = somethingThatRequiresHttp(io.fetch);
// ...
}
function main(io) {
const result = something(readonlyFetch(onlyOurAPI(io.fetch))
}
function onlyOurAPI(fetch) {
return (...args) => {
const test = /^https:\/\/api.mydomain.example\//.exec(args[0]);
if (test == null) {
throw new ValueError("must only communicate with our API");
}
return fetch(..args);
}
}
function readonlyFetch(fetch) { /* similar but allowlist only GET/HEAD methods */ }
Shoutout to Ryan Dahl and Deno, where you write `#!/usr/bin/env deno --allow-net=api.mydomain.example` at the start of your shell script to accomplish something similar.
In my amateur programming-conlang hobby that will probably never produce anything joyful to anyone other than me, one of those programming languages has a notion of sending messages to "message-spaces" and I shamelessly steal Doug's idea -- message-spaces have handles that you can use to communicate with them, your I/O is a message sent to your main m-space containing a bunch of handles, you can then pattern-match on that message and make a new handle for a new m-space, provisioned with a pattern-matcher that only listens for, say, HTTP GET/HEAD events directed at the API, and forwards only those to the I/O handle. So then when I give this new handle to someone, they have no way of knowing that it's not fully I/O capable, requests they make to the not-API just sit there blackholed until you get an alert "there are too many unread messages in this m-space" and peek in to see why.
https://blog.plan99.net/why-not-capability-languages-a8e6cbd...
we could literally just take Go and categorize on "imports risky package" and we'd have a better situation than we have now, and it would encourage library design that isolates those risky accesses so people don't worry about them being used. even that much should have been table stakes over a decade ago.
and like:
>No language has such an object or such interfaces in its standard library, and in fact “god objects” are viewed as violating good object oriented design.
sure they do. that's dependency injection, and you'd probably delegate it to a dependency injector (your god object) that resolves permissions. plus go already has an object for it that's passed almost everywhere: context.
perfect isn't necessary. what we have now very nearly everywhere is the most extreme example of "yolo", almost anything would be an improvement.
hence: doesn't sound too bad
"truly needs": currently, yes. but that seems like a fairly easy thing to address with library packaging systems and a language that supports that. static analysis and language design to support it can cover a lot (e.g. go is limited enough that you can handle some just from scanning imports), and "you can ask for something you don't use, it just means people are less likely to use your library" for the exceptions is hardly a problem compared to our current "you already have every permission and nobody knows it".
I think I need to read up more on how to deal with (avoiding) changes to your public APIs when doing dependency injection, because that seems like basically what you're doing in a capability-based module system. I feel like there has to be some way to make such a system more ergonomic and make the common case of e.g. "I just want to give this thing the ability to make any HTTP request" easy, while still allowing for flexibility if you want to lock that down more.
On the other hand, it seems about as hard as I was imagining. I take for granted that it has to be a new language -- you obviously can't add it on top of Python, for example. And obviously it isn't compatible with things like global monkeypatching.
But if a language's built-in functions are built around the idea from the ground up, it seems entirely feasible. Particularly if you make the limits entirely around permissions around data communication -- with disk, sockets, APIs, hardware like webcams and microphones, and "god" permissions like shell or exec commands -- and not about trying to merely constrain resource usage around things like CPU, memory, etc.
If a package is blowing up your memory or CPU, you'll catch it quickly and usually the worst it can do is make your service unavailable. The risk to focus on should be exclusively data access+exfiltration and external data modification, as far as I can tell. A package shouldn't be able to wipe your user folder or post program data to a URL at all unless you give it permission. Which means no filesystem or network calls, no shell access, no linked programs in other languages, etc.
there are some rather obvious challenges, but a huge amount of the ones I've run across end up looking mostly like "it's hard to add to an existing language" which is extremely understandable, but hardly a blocker for new ones.
It didn't go well. The JVM did it's part well, but they couldn't harden the library APIs. They ended up playing whack-a-mole with a steady stream of library bugs in privileged parts of the system libraries that allowed for sandbox escapes.
There’s no reason a color parser, or a date library should require network or file system access.
A different idea: Special stack frames such that while that frame is on the stack, certain syscalls are prohibited. These "sandbox frames" could be enabled by default for most library calls, or even used by developers to handle untrusted user input.
Versus, when I've worked at places that eschew automatic dependency management, yes, there is some extra work associated with manually managing them. But it's honestly not that much. And in some ways it becomes a boon for maintainability because it encourages keeping your dependency graph pruned. That, in turn, reduces exposure to third-party software vulnerabilities and toil associated with responding to them.
And at least with a standardized package manager, the packages are in a standard format that makes them easier to analyze, audit, etc.
should it be higher friction than npm? probably yes. a permissions system would inherently add a bit (leftpad includes 27 libraries which require permissions "internet" and "sudo", add? [y/N]) which would help a bit I think.
but I'm personally more optimistic about structured code and review signing, e.g. like cargo-crev: https://web.crev.dev/rust-reviews/ . there could be a market around "X group reviewed it and said it's fine", instead of the absolute chaos we have now outside of conservative linux distro packagers. there's practically no sharing of "lgtm" / "omfg no" knowledge at the moment, everyone has to do it themselves all the time and not miss anything or suffer the pain, and/or hope they can get the package manager hosts' attention fast enough.
The more interesting comparison to me is, for example, my experience on C# projects that do and do not use NuGet. Or even the overall C# ecosystem before and after NuGet got popular. Because then you're getting closer to just comparing life with and without a package manager, without all the extra confounding variables from differing language capabilities, business domains, development cultures, etc.
I do agree that C is an especially-bad case for additional reasons though, yeah.
exceptions totally exist, I've seen them too. I just don't think they're enough to move the median away from "total chaotic garbage" regardless of the system
Leftpad as a library? Let it all burn down; but then, it's Javascript, it's always been on fire.
Before AI code generation, we would have called that copy-and-paste, and a code smell compared to proper reuse of a library. It's not any better with AI. That's still code you'd have to maintain, and debug. And duplicated effort from all the other code doing the same thing, and not de-duplicated across the numerous libraries in a dependency tree or on a system, and not benefiting from multiple people collaborating on a common API, and not benefiting from skill transfer across projects...
Smells are changing, friend. Now, when I see a program with 20000 library dependencies that I have to feed into a SAST and SCA system and continually point-version-bump and rebuild, it smells a hell of a lot worse to me than something self-contained.
At this point, I feel like I can protect the latter from being exploited better than the former.
I expect that your future CVEs will say otherwise. People outside your organization have seen those library dependencies, and can update them when they discover bugs or security issues, and you can automatically audit a codebase to make sure it's using a secure version of each dependency.
Bespoke AI-generated code will have bespoke bugs and bespoke security issues.
In the C world, anything that is not direct is often a very stable library and can be brought in as a peer deps. Breaking changes happen less and you can resolve the tree manually.
In NPM, there are so many little packages that even renowned packages choose to rely one for no obvious reason. It’s a severe lack of discipline.
Hey that was also on NPM iirc!
Nixing javascript in the frontend is a harder sell, sadly
Ruby, Python, and Clojure, though? They weren’t any better than my npm projects, being roughly the same order of magnitude. Same seems to be true for Rust.
Same with Java, if you avoid springboot and similar everything frameworks, which admittedly is a bit of an uphill battle given the state of java developers.
You can of course also keep dependencies small in javascript, but it's a very uphill fight where you'll have just a few options and most people you hire are used to including a library (that includes 10 libraries) to not have to so something like `if (x % 2 == 1)`
Just started with golang... the language is a bit annoying but the dependency culture seems OK
If you think npm.help is something it isn't, that's not something DKIM et al can help with.
I can think of 3 paths to improve situation (assuming that "everyone deploys cryptographic email infrastructure instantly" is not gonna happen).
1. The email client doesn't indicate DKIM at all. This is strictly worse than today, because then the attack could have claimed to be from npmjs.com.
2. You only get a checkmark if you have DKIM et al plus you're a "verified domain". This means only big corporations get the checkmark -- I hate this option. It's EV SSL but even worse. And again, unless npmjs.com was a "big corporation" the attacker could have just faked the sender and the user would not notice anything different, since in that world the authentic npmjs.com emails wouldn't have a checkmark either.
3. The checkmark icon is changed into something else, nothing else happens. But what? "DKIM" isn't the full picture (and would be horribly confusing too). Putting a sunflower there seems a little weird. Do you really apply this much significance to the specific icon?
The path that HTTPS took just hasn't been repeatable in the email space; the upgrade cycles are much slower, the basic architecture is client->server->server not client->server, and so on.
Few years ago? I have lock icon right now in my address bar
No?
How do you change your 2FA? Buy a new phone? A new Yubikey?
I agree that rotating 2FA should ring alarm bells as an unusual request. But that requires thinking.
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 see the JavaScript ecosystem hasn’t changed since leftpad then.
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.
I do think it's worth reducing the number of points of failure in an ecosystem, but relying entirely on a single library that's at risk of stagnating due to eternal backcompat obligations is not the way; see the standard complaints about Python's "dead batteries". The Debian or Stackage model seems like it could be a good one to follow, assuming the existence of funding to do it.
The article's author seems to be under the misapprehension that standard libraries should or have to be community-driven like Node's and that falling for phishing attacks is inevitable over a long enough period of time. Neither notion is accurate.
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.
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/
You still don't know then of course. When in doubt you shouldn't do the action that is asked through clicking on links in the mail. Instead go to the domain you know to be legit and execute the action there.
Having said all that, even the most aware people are only human. So it is always possible to overlook a detail like that.
The whole web is a darn mess! I have no ideas for solutions.
> But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't become malicious over time.
I expect him to know better.
Shouldn’t this be solved some other ways?
This is also easily avaidable by using password manager which will not autofill credentials on a page with a wrong domain.
Edit: And yes, I do this for every link emailed to me that does anythig more high stakes than point me to a newsletter article.
NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 - Sept 2025 (697 comments, including exemplary comments from the project maintainer)
> "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."
I keep expecting some new company to bring out this revolutionary idea of "On prem: your machine, your libraries, your business."
No bank, and almost no large corporations go directly to artifact/package repos. They all host them internally.
Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.
Then there's days like this.
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.
For more context on why I thought that link would have been helpful: In Go you download dependencies "straight" from the source[1], while in npm and other languages you download dependencies from a completely unrelated registry that can have any random code (i.e. whether the published artifact was built from the alleged source repository, is a flip of a coin).
So not having this kind of third party registry eliminates the point of failure that caused the issue commented in the article. The issue was caught because of a centralized place, yes, but it was also caused because npm dependencies are downloaded from a centralized place and because this centralized place only hosts artifacts unrelated to the source code itself; package authors can `npm publish` artifacts containing the exact source code from their repos if they want though. If.
With Go, having a mirror of the source code is still third party infra, but is more an optimization than anything else, and checksums are generated based on the source itself[2] (rather than any unrelated artifact). This checksum should match even for people not using any proxy, so if you serve different code to someone, there will be a mismatch between the checksum of the downloaded module and the checksum from the SumDB. This should catch force-pushes done to a git repository version tag, for example.
Also, Go downloads the minimum version that satisfies packages, so it's less likely that you'll download a (semver) "patch" release that someone pushed hours ago.
All this makes me both like and dislike how Go handles dependencies.
[1]: Well, from a mirror, unless you set `GOPROXY=direct`. Reasoning explained in next paragraph.
[2]: The checksum is calculated from a zip file, but it is generated in a deterministic way, and this checksum is also generated and validated locally when you download dependencies. More info at https://go.dev/ref/mod#zip-files and https://go.dev/ref/mod#go-mod-verify
Procrastination is a security strategy.
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.
Not only is it “proof of concept” but it’s a low risk high reward play. It’s brilliant really. Dangerously so.
Authentication-Results: aspmx1.migadu.com;
dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0r;
dkim=pass header.d=npmjs.help header.s=rwmt1 header.b=opuoQW+P;
spf=pass (aspmx1.migadu.com: domain of ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help designates 45.158.83.7 as permitted sender) smtp.mailfrom=ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help;
dmarc=pass (policy=none) header.from=npmjs.helpNPM debug and chalk packages compromised
One of the common cases of being offline first, disconnected etc. pays off.
Don't rush. Work on Hawaiian clock!
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.
- Golang Proverb (also applies to any other programming language...)
There I fixed it. Now I don't even need the package array-ish!
- 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.
> However security ignorant companies do send emails like this
exactly
> What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.
I didn't sit and read and parse the whole thing. That was mistake one. I have stated elsewhere, I was stressed and in a rush, and was trying to knock things off my list.
Also, 2FA can of course be updated. npm has had some shifts in how it approaches security over the years, and having worked within that ecosystem for the better part of 10-15 years, this didn't strike me as particularly unheard of on their part. This, especially after the various acquisitions they've had.
It's no excuse, just a contributing factor.
> It would be very unusual to write like that in a formal security notification.
On the contrary, I'd say this is pretty par for the course in corpo-speak. When "kindly" is used incorrectly, that's when it's a red flag for me.
> 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.
Yes, of course it is. I'm well aware of that. Again, this email reached me at the absolute worst time it could have and I made a very human error.
"Temporarily locked" surprises me that it surprises you. My account was, in fact, temporarily locked while I was trying to regain access to it. Even npm had to manually force a password reset from their end.
> Any nonstandard domain is a red flag.
When I contacted npm, support responded from githubsupport.com. When I pay my TV tax here in Germany (a governmental thing), it goes to a completely bizarre, random third party site that took me ages to vet.
There's no such thing as a "standard" domain anymore with gTLDs, and while I should have vetted this particular one, it didn't stand out as something impossible. In my head, it was their new help support site - just like github.community exists.
Again - and I guess I have to repeat this until I'm blue in the face - this is not an excuse. Just reasons that contributed to my mistake.
> NEVER EVER EVER click links in any kind of security alert email.
I'm aware. I've taught this as the typical security person at my respective companies. I've embodied it, followed it closely for years, etc. I slipped up, and I think I've been more than transparent about that fact.
I didn't ask for my packages to be downloaded 2.6 billion times per week when I wrote most of these 10 years ago or inherited them more than five ago. You can argue - rightfully - about my technical failure here of using an outdated form of 2FA. That's on me, and would have protected against this, but to say this doesn't happen to security-savvy individuals is the wrong message here (see: Troy Hunt getting phished).
Shit happens. It just happened to happen to me, and I happen to have undue control over some stuff that's found its way into most of the javascript world.
The security lessons and advice are all very sound - I'm glad people are talking about them - but the point I'm trying to make is, that I am a security aware/trained person, I am hyper-vigilant, and I am still a human that made a series of small or lazy mistakes that turned into one huge mistake.
Thank you for your input, however. I do appreciate that people continue to talk about the security of it all.
"This is a 10/10 phishing email."
It's not. But it doesn't mean I wouldn't also fall for it because I was tired/in a hurry or whatever else could let me drop my guard.
Humans are humans.
That's why you need vuln scanners and not upgrade to the latest thing as soon as released.
Wouldn't help in this case where someone bought a domain that looked a tiny bit like the authentic one for a very casual observer.
Let's say there's a company named Awesome...and i register the domain name of AwesomeSupport.com. I could be a total dark hat/evil hacker/neverdoweller....and this domain may not be infringing on any trademark, etc. And, then i can start using all the encryption you noted...which merely means that *my domain name* (the bad one) is "technically sound"...but of course, all that use of encryption fails to convey that i am not the legitimate Awesome company. So, how is the victim supposed to know which of the domains is legit or not? Especially considering that some departments of the real, legit Awesome company might register their own domain name to use for actual, real reasons - like the marketing department might register MyAwesome.com...for managing customer accounts, etc.
Is encryption necessary in digital life? Hellz yeah! Does it solve *all issues*? Hellz no! :-)
There aren't that many websites. The e-mail provider could have a list of "popular" domains, and the user could have their own list of trusted domains.
There is all sorts of ways to warn the user about it, e.g. "you have never interacted with this domain before." Even simply showing other e-mails from the same domain would be enough to prevent phishing in some cases.
There are practical ways to solve this problem. They aren't perfect but they are very feasible.
To your more recent points, i agree that there are other several protections in place...and depending on a number of facotrs, some foks have more at their disposal, and others might have less...but, still there are mechnisms in place to help - without a doubt. But yet with all these mechanisms in place, people still fall prey to phishing attacks...and sometimes those victims are not lay people, but actual technologists. So, i think the solution(s) to solve this are not so simple, and likely are not only tech-based. ;-)
Thing is, where are the user's credentials stored. In a goverment's computer probably. Greece is taking some steps towards this [1].
A Greek citizen to obtain a digital signature, he has to go to a bank, the bank verifies him, he pays a fee and then the government can accept his digital signature. My guess is that the dictatorship banks established with the Covid excuse might start to bear some fruits finally.
But, people on the internet might want something more advanced, more secure than some COBOL computers storing their identity. Then we save digital certificates and digital identities on the blockchain, making essentially the blockchain the heart of the internet.
When a person from a company sends a message to a client, he can sign the message with his own identity and the identity of the company. Problem solved. No one get's confused when the cryptographic signatures are not verified. The message is invalid and it is redirected to the spam folder.
[1] https://www.gov.gr/en/ipiresies/polites-kai-kathemerinoteta/...
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."
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…
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
The sense of urgency is always the red flag.
but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2
ok, maybe there is some browser cache issue, whatever, so you trigger your password manager to provide your auth to the website -- but here, every single password manager would immediately notice that the domain in the browser does not match the domain associated with the auth creds, and either refuse to paste the creds thru, or at an absolute minimum throw up a big honkin' alert that something is amiss, which you'd need to explicitly click an "ignore" button to get past. red flag 3
nobody should be able to publish new versions of widely-used software without some kind of manual review/oversight in the first place, but even ignoring that, if someone does have that power, and they get pwned by an attack like this, with at least 3 clear red flags that they would need to have explicitly ignored/bypassed, then CLEARLY this person cannot keep their current position of authority
The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's.
> but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2
Why wouldn't I be? I don't stay logged into npm at all.
the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient
what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL?
i'm not sure what this comment is trying to accomplish, it parses as FUD
DKIM et al came back clean.
As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
> As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
"scheme" is a well-defined domain term that refers to the e.g. `https://` part of a URL/URI -- but that aside, I still don't get what you're saying here? what is "format and layout of URLs" and how does that relate to "mitm attack"?
to cut to the chase, a malicious email maybe contains a link, to a URL, that a victim can click on. but if that link says it goes to `https://npm.org` then it actually does go to `https://npm.org` and there isn't like any special secret way for an email to hijack or mitm that domain or URL resolution. if the link is actually `https://npn.org` then that's a totally different thing, it's not a mitm attack, there is no concept of "format or layout" of that totally different URL "matching 1:1" with `https://npm.org` -- unless you're talking about something totally different to what I'm understanding?
edit: wait are we talking about an email sent from a domain `npmjs.help`? DKIM and DMARC and URL scheme validation don't even enter the picture here, this was no kind of mitm attack by any definition -- "npmjs.help" is clear-as-day a malicious domain, and any email from it a clear-as-day phishing attempt.. ! it's fine, we're all human and etc. but it just underscores the issue here being minimizing blast radius of failures, and not anything related to any specific user/human
1. My email client does the validation of certain integrity and security checks and shows a checkmark next to senders that pass. Since npmjs.help was a domain legitimately owned by the attackers, it passed.
2. The link in the email lead to their site at the same domain, most likely performing a MITM between my browser and npm's official servers.
3. You're arguing semantics about "scheme". Please try to understand what I'm attempting to convey: The URLs appeared to match the official npm's site. There was no <a href> trickery. Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
4. Emails themselves are not MITM attacks, no. I didn't respond to an email with my credentials. I would never do that. But that isn't what I've ever claimed to have happened.
5. The URLs being similar or identical to npm's isn't how they technically achieved the MITM. The URLs being similar was to avoid arousing suspicion.
Hopefully that's explanatory enough.
The domain "npmjs.help" is pretty clearly malicious at a glance, just from the ".help" TLD alone, but yeah as you say
> Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains.
well except that presumably you clicked on a npmjs.help link and the new tab ended up at npmjs.com? but yeah it's a tough break, don't mean to needle you, hopefully learning experience
You should still never click a link in an email like this, but the urgency factor is well done here
It was obviously good enough.
Snark aside, you only need to trick one person once and you've won.
If everyone signed commits with well published keys, -and- if NPM would stop rejecting every PR and feature request for clients to verify signatures from authors that opt in, this problem would not exist for packages from those authors.
Unfortunately the official position of NPM since 2013 is that hashes solve the same security problem as signatures and that the signatures might make non signing package authors second class citizens. So no security for anyone, to avoid scaring off lazy maintainers.
We are cooked.
> 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".
---
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.
TOTP doesn't need to be phishing-proof if you use a password manager integrated with the browser, though.
If certain websites fail to be detected, thats a security issue on those specific websites, as I'll learn which ones tend to fail.
If they rarely fail to detect in general, its infrequent enough to be diligent in those specific cases. In my experience with password managers, they rarely fail to detect fields. If anything, they over detect fields.
An internal engineer there who did a bunch of security work phished like half of her own company (testing, obviously). Her conclusion, in a really well-done talk, was that it was impossible. No human measures will reduce it given her success at a very disciplined, highly security conscious place.
The only thing that works is yubikeys which prevent this type of credential + 2fa theft phishing attack.
edit:
karla burnette / talk https://www.youtube.com/watch?v=Z20XNp-luNA
https://karla.io/files/ichthyology-wp.pdf
> At Stripe, rather than focusing on mitigating more basic attacks with phishing training, we decided to invest our time in preventing credential phishing entirely. We did this using a combination of Single Sign On (SSO), SSL client certificates, and Universal Second Factor (U2F)
I receive Google Doc links periodically via email; fortunately they're almost never important enough for me to actually log in and see what's behind them.
My point, though, is that there's no real alternative when someone sends you a doc link. Either you follow the link or you have to reach out to them and ask for some alternative distribution channel.
(Or, I suppose, leave yourself logged into the platform all the time, but I try to avoid being logged into Google.)
I don't know what to do about that situation in general.
Or only log in when you need to open a google link. Or better yet, use a multi-account container for google.
Pardon; a what? Got any reference links?
https://addons.mozilla.org/en-US/firefox/addon/multi-account...
The answer is simple: use your bookmarks/password manager/... to login yourself with a URL you control in another tab and come back to the email to click it
(and if it still asks for a login then, of course still don't do it)
Sites choosing to replace password login with initiating the login process and then clicking a "magic link" in your email client is awful for developing good habits here, or for giving good general advice. :c
In both cases it's good advice not to click the link unless you initiated the request. But with the auth token in the link, you don't need to login again, so the advice is still the same: don't login from a link in your email; clicking links is ok.
1. If a target website (say important.com) sends poorly-configured CORS headers and has poorly configured cookies (I think), a 3rd-party website is able to send requests to important.com with the cookies of the user, if they're logged in there. This depends on important.com having done something wrong, but the result is as powerful as getting a password from the user. (This is called cross-site request forgery, CSRF.)
2. They might have a browser zero-day and get code execution access to your machine.
If you initiated the process that sent that email and the timing matches, and there's no other way than opening the link, that's that. But clicking links in emails is overall risky.
2 is also true. But also, a zero day like that is a massive deal. That's the kind of exploit you can probably sell to some 3 letter agency for a bag. Worry about this if you're an extremely high-value target, the rest of us can sleep easy.
Just ... don't.
A guy I knew needed a car, found one, I told him to take it to a mechanic first. Later he said he couldn't, the guy had another offer, so he had to buy it right now!!!, or lose the car.
He bought, had a bad cylinder.
False urgency = scam
As in right then, without being given a deadline…
Last I checked, we're still in a world where the large majority of people with important online accounts (like, say, at their bank, where they might not have the option to disable online banking entirely) wouldn't be able to tell you what any of those things are, and don't have the option to use anything but SMS-based TOTP for most online services and maybe "app"-based (maybe even a desktop program in rare cases!) TOTP for most of the rest. If they even have 2FA at all.
At least the crowd here should _know_ that TOTP doesn't do anything against phishing, and most of the critical infrastructure for code and other things support U2F so people should use it.
The rest is handled by preferring plain text over HTML, and if some moron only sends HTML mails to carefully dissect it first. Allowing HTML mails was one of the biggest mistakes for HTML we've ever made - zero benefits with huge attack surface.
That's exactly why I said all the other "helpful" recommendations and warning signs people are using are never foolproof, and thus mostly useless given the scale at which phishing campaigns operate.
Great if it helps you in the general case, terrible if it lulls you into a sense of confidence when it's actually a phishing email using the right email address.
Still, I don’t understand how npmjs.help doesn’t immediately trigger red flags… it’s the perfect stereotype of an obvious scam domain. Maybe falling just short of npmjshelp.nigerianprince.net.
should practice it for ENTER your password, ENTER your 2FA ;)
> Still, I don’t understand how npmjs.help doesn’t immediately trigger red flags
1. it probably did for quite a few recipients, but that's never going to be 100% 2. not helped by the current practices of the industry in general, many domains in use, hard sometimes to know if it's legit or not (some actors are worse in this regard than others)
Either way, someone somewhere won't pay enough attention because they're tired, or stressed out, or they are just going through 100 emails, etc.
1- As a professional, installing free dependencies to save on working time.
There's no such thing as a free lunch, you can't have your cake and eat it too that is, download dependencies that solve your problems, without paying, without ads, without propaganda (for example to lure you into maintaining such projects for THE CAUSE), without vendor lockin or without malware.
It's really silly to want to pile up mountains of super secure technology like webauthn, when the solution is just to stop downloading random code from the internet.
If I sell corn syrup for downstream food consumers and dont lock my factory doors and let whoever walk in, isn't it reckless?
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.
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.
I hardly think a polite request is entitlement.