People who publish software packages tend to be at least somewhat technical people. Can package publishing platforms PLEASE start SIGNING emails. Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform.
Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks.
And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.
We analyzed this DuckDB incident today. The attacker phished a maintainer on npmjs.help, proxied the real npm, reset 2FA, then immediately created a new API token and published four malicious versions. A short publish freeze after 2FA or token changes would have broken that chain. Signed emails help, but passkeys plus a publish freeze on auth changes is what would have stopped this specific attack.
There was a similar npm phishing attack back in July (https://socket.dev/blog/npm-phishing-email-targets-developer...). In that case, signed emails would not have helped. The phish used npmjs.org — a domain npm actually owns — but they never set DMARC there. DMARC is only set on npmjs.com, the domain they send email from. This is an example of the “lack of an affirmative indicator” problem. Humans are bad at noticing something missing. Browsers learned this years ago: instead of showing a lock icon to indicate safety, they flipped it to show warnings only when unsafe. Signed emails have the same issue — users often won’t notice the absence of the right signal. Passkeys and publish freezes solve this by removing the human from the decision point.
I got a fraud alert email from my credit card the other day. It included links to view and confirm/deny the suspicious charge. It all looked OK, the email included my name and the last digits of my account number.
I logged in to the website instead. When I called to follow up I used the phone number printed on my card.
Turns out it was a legit email, but you can't really know. Most people don't understand public key signing well enough to rely on them only trusting signed emails.
Also, if you're sending emails like this to your users, stop including links. Instead, give them instructions on what to do on your website or app.
I wish we could stop training people to click links in random messages just because we want to be able to track their movements online.
I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.
USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA.
[1]https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...
I am skeptical this solves phising & not add to more woes (would you blindly click on links if the email was signed?), but if we are going to suggest public key cryptography, then: NPM could let package publishers choose if only signed packages must be released and consumers decide if they will only depend on signed packages.
I guess, for attackers, that moves the target from compromising a publisher account to getting hold of the keys, but that's going to be impossible... as private keys never leave the SSM/HSM, right?
> Get them to distrust any unsigned email, no matter how convincing it looks.
For shops of any important consequence, email security is table stakes, at this point: https://www.lse.ac.uk/research/research-for-the-world/societ...
Signing the packages seems like low hanging fruit as well, if that isn't already being done. But I'm skeptical that those keys are as safe as they should be; IIRC someone recently abused a big in a Github pipeline to execute arbitrary code and managed to publish packages in that way. Which seems like an insane vulnerability class to me, and probably an inevitable consequence of centralising so many things on github.
* signed packages
enforce it for the top x thousand most popular packages to start
some basic hygiene about detecting unique new user login sessions would help as well
People will inevitably set up their CI system to sign packages, no human intervention needed. If they're smart & the CI system is capable of it they'll set it up to only build when a tag signed by someone approved to make releases is pushed, but far too often they'll just build if a tag is pushed without enforcing signature verification or even checking which contributors can make releases. Someone with access to an approved contributor's GitHub account can very often trigger the CI system to make a signed release, even without access to that contributor's commit signing key.
One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one?
It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.
It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will generate more meetings, etc.
If I want to make any changes to the mycompany.othertld domain, I can just do it, with no approval from anyone.
Alternatively, yup, SOC2 is a thing: optionally create a ticket tracking the why, then open a PR against the IaC repo citing that ticket, have it ack-ed by someone other than the submitter, audit trail complete, change managed, the end
Like Citroen sends software update notifications for their cars from mmy-customerportal.com. That URL looks and sounds like a phisher's paradise. But somehow, it's legit. How can we expect any user to make the right decision when we push this kind of garbage in their face?
I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders.
This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue.
If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email.
I went into more detail about the benefits of this system and how it can be implemented in this comment:
Anyway, I already mentioned a solid incentive for them to use the correct token. Go back and read my earlier comment.
This is the wrong question.
The right question is: what should we do about the fact that the organization has such terrible security practice?
And the answer is: call them on the phone, and tell them that you will not do business with them until they fix their shit.
And who is going to do anything about fixing their stuff when you pay them a mere subscription fee?
"All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.
Most times that I go to use some JS, Python, or (sometimes) Rust framework, I get a sinking feeling, as I see a huge list of dependencies scroll by.
I know that it's a big pile of security vulnerabilities and supply-chain attack risk.
Web development documentation that doesn't start with `npm install` seems rare now.
Then there's the 'open source' mobile app frameworks that push you to use the framework on your workstation with some vendor's Web platform tightly in the loop, which all your code flows through.
Children, who don't know how things work, will push any button. But experienced software engineers should understand the technology, the business context, and the real-world threats context, and at least have an uneasy, disapproving feeling every time they work on code like this.
And in some cases -- maybe in all cases that aren't a fly-by-night, or an investment scam, or a hobby project on scratch equipment -- software engineers should consider pushing back against engaging in irresponsible practices that they know will probably result in compromise.
All these actions are teaching people to be dumb and make it more likely they’ll fall for a scam because the pattern has been normal before.
Maybe don't allow changing the email address right after changing 2fa?
And if the email is changed, send an email to the original email alllowing you to dispute the change.
But I think calling DuckDB “critical infrastructure” is just a bit conceited. As an industry we really overestimate the importance of our software that can be deleted when it’s broken. We take ourselves way too seriously. In any worst case scenario, a technical problem can be solved with a people solution.
If you want to talk about critical infrastructure then the xz backdoor was the closest we’ve caught to affecting it. And what came of that backdoor? Nothing significant… I suppose you could say there might be 100 xz-like backdoors lurking in our “critical infrastructure” today, but at least as long as they’re idle, it’s not actually a problem. Maybe one day China will invade Taiwan and we’ll see just how compromised our critical infrastructure has actually been this whole time…
1. I genuinely don't understand why.
2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action.
You never make a mistake? Never ever? It's a question of numbers. If the likelihood of making a mistake is 1 in 10000 emails, send out links to 10.000 package maintainers, and you've got a 63% chance of someone making that mistake.
I trust the user did this calculation. I didn't.
The major difference between passkeys and hardware 2fa (FIDO2/yubikeys) and TOTP/SMS/Email solutions is that the passkey/yubikey _also_ securely validates the site it's communicating with before sending validation, making traditional phishing attacks all but impossible.
It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself.
There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.
I'll get a lot of pushback for this, but the main problem are ecosystems that encourage using packages published by one person. I call these "some person with a github" packages, and I typically go through codebases to try to remove these dependencies specifically because of this threat vector.
Packages that are developed by a team with code multiple code reviewers and a process are still at risk, don't get me wrong. But the risk is much less if one person does not have the power to unilaterally merge a PR, and more-so if its backed by an organization that has multiple active devs and processes for reviews.
If you do need to depend on these one-person packages, I'd recommend forking and carefully merging in changes, or pinning versions and manually reviewing all commits before upgrading versions. Thats probably intractable for a lot of projects, but thats honestly something that we as developers need to fix by raising the bar for what dependencies we include.
Nothing will reduce incidents to 0, but many things can move us closer to 0.
I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?
I think where they got lucky is
> In hindsight, the fact that his browser did not auto-complete the login should have been a red flag.
A huge red flag. I wonder if browsers should actually detect if you're putting login details for site A manually into site B, and give you a "are you sure this isn't phishing" warning or something?
I don't quite understand how the chalk author fell for it though. They said
> This was mobile, I don't use browser extensions for the password manager there.
So are there mobile password managers that don't even check the URL? I dunno how that works...
>A huge red flag.
It won't be a red flag for people who often see auto-complete not working for legitimate websites. The usual cause is legitimate websites not working instead of actual phishing attempts.
This unintended behavior of password managers changes the Bayesian probabilities in the mind such that username/password fields that remain unfilled becomes normal and expected. It inadvertently trains sophisticated people to lower their guard. I wrote more on how this happens to really smart technical people: https://news.ycombinator.com/item?id=45179643
>So are there mobile password managers that don't even check the URL? I dunno how that works...
Strongbox pw manager on iOS by default doesn't autofill. You have to go settings to specifically enable that feature. If you don't, it's copy&paste.
Please people, build your login forms correctly! It’s not rocket science.
Yeah, that's true, I hit this all the time with 1Password+Firefox+Linux (fun combo).
Just copying-pasting the username+password because it doesn't show up is the wrong approach. It gives you a chance to pause and reflect, since it isn't working, so in that case you lookup if it's actually the right domain, and if it is, add it to the allowed domains so it works fine in the future.
Maybe best would be if password managers defaulted to not showing a "copy" thing at all for browser logins, and not letting users select the password, instead prompting them to rely on the autofill, and fix the domains if the autofill doesn't work.
Half the reason I use password manager in the first place is specifically for this issue, the other half is because I'm lazy and don't like typing. It's really weird to hear people using password managers yet do the old copy-paste dance anyways.
Unfortunately, as bad as phishing is, service providers have leaked more plain text passwords than a phisherman could ever catch.
But the domain binding just isn't possible without technical means, hence I see that as my own top reason, I suppose :)
Thankfully there are many reasons to use a password manager. Auto-fill is just one.
Is there some middle ground where I can get the browser to automatically confirm I am on a previously trusted domain? My initial thought is that I could use Firefox Workspaces for trusted domains. Limited to the chosen set of urls. Which I already do for some sites, but I guess I could expand it to everything with a login.
Not actually suggesting this as it sounds like quite a big headache, but it is an option.
Think my only blocker would be if the browser extension fights me if I try to register a site using a broken/missing password.
Does feel like a bit of a browser gap. “You have previously visited this site N times”. If that number is zero, extra caution warranted. Even just a bit of extra sophistication on bookmarks if the root domain has previously been registered. Thinking out loud, I guess I could just lean on the browser Saved Passwords list. I’ve never been comfortable with the security, but I could just always try to get it to save a sentinel username, “YOUHAVEBEENHEREBEFORE”.
I don't get these arguments. Yeah, of course I was always surprised phishing emails give itself away with mistakes as maybe non-native speakers create it without any spellcheck or whatever and it was straight forward to improve that... but whatever the text, if I open a link from email the first thing I look at is domain. Not how the site looks. The DOMAIN NAME! Am I on trusted site? Well .help TLD would SURELY ring a bell and involve research as whether this domain is associated to npm in any way.
At some point my bank redirected me to some weird domain name... meh, that was annoying, had to research whether that domain is really associated to them.. it was. But they just put their users under risk if they want domain name not to mean trust and just feed whatever domains as acceptable. That is NOT acceptable.
There are more than a few instances when I’ve created an account for a service I know I’ve never interacted with before, but my password manager offered to log me in because another business I’ve used in the past used the same service (medical providers, schools, etc.).
Even as a technically competent person, I received a legitimate email from Google regarding old shadow accounts they were reconciling from YouTube and I spent several hours convinced it was a phishing scheme.it put me on edge for nearly a week that there was no way I could be sure critical accounts were safe, and worse yet, someone like my parents or in-laws could be safe.
data:text/html,<meta charset="utf-8"><body><a href="https://news.ycomb%C4%B1nator.com/login">login to news.ycombinator.com</a></body>
> We can’t connect to the server at news.xn--ycombnator-1ub.com.
1: Ironically HN actually mutated that link, I pasted the unicode version news.ycombınator.com (which it seems to leave intact so long as I don't qualify it with a protocol://)
This is the case when you are doing mass phishing attacks trying to get the dumbest person you can. In these cases, they want the person that will jump through multiple loops one after another that keeps giving them money. A more technical audience you wouldn't want to do so, if you want one smart person to make one mistake.
Frankly I can't believe we've trained an entire generation of people that this is the key identifier for scam emails.
Because native English speakers never make a mistake, and all scammers are fundamentally unable to use proper grammar, right?
MyBank: "Don't click on emails from suspicious senders! Click here for more information" { somethingweirdmybank.com } -- Actual real email from my bank.
Like, wtf. Why are you using a totally different domain.
And the companies I've worked for do this kind of crap all the time. "Important company information" { learnaboutmycompany.com } -- Like, is this a random domain someone registered. Nope, actually belongs to the place I work for when we have a well known and trusted domain.
Oh, and it's the best when the legit sites have their own spelling mistakes.
The fact this is NOT the standard phishing email shows how low the bar is:
1. the text of the email reads like one you'd get from npm in the tone, format and lack of obvious spelling & grammatical errors. It pushes you to move quicker than you might normally, without triggering the typical suspicions.
2. the landing domain and website copy seem really close to legit, no obfuscated massive subdomain, no uncanny login screen, etc.
All the talk of AI disrupting tech; this is an angle where generative AI can have a massive impact in democratizing the global phishing industry. I do agree with you that there's likely many more authors who have been tricked and we haven't seen the full fallout.
Also, I really don't see what this has to do with gen AI, or what "democratizing the global phishing industry" is supposed to mean even.
Is this comment AI generated?
That's what I'm guessing OP meant.
same with just copying email HTML
it's actually easier to make it looke exactly the same vs different in some ways
As a university professor whose email address is public, I've been regularly getting phishing emails for years. Many of these are targeted and devoid of any spelling or grammatical errors. I am sure generative AI is making writing these emails easier but by how much is unknown.
Not sure how this emphasis is of any importance, you brain doesn't have a pixel perfect image of the website, so you wouldn't know whether it's a perfect replica or not.
Let the silicon dummies in the password manager do the matching, don't strain your brain with such games outside of entertainment
I really hope you clear your clipboard history entirely after doing your copy/paste method because your credentials would otherwise persist for any other application with clipboard perms to just exfiltrate (which has already been exploited in the wild before)
How does that work?
If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information? If the user is using a password manager, presumably they don't reuse passwords, so the malicious website would have to guess the matching username + URL where the password applies.
If you're talking about a malicious desktop app running on the same system, it's game over anyway because it can read process memory, read keystrokes, etc.
Sidenote: Most password managers I've used automatically clear the clipboard 10-15s after you copy a credential.
> If a malicious website reads the clipboard, what good is knowing an arbitrary password with no other information?
Even if assuming unique username+url pairings, clipboard history can store multiple items including emails or usernames which could be linked to any data breach and service (or just shotgunned towards the most popular services). It's not really a "no other information" scenario and you drastically reduce the effort required for an attacker regardless.
> If you're talking about a malicious desktop app running on the same system, it's game over anyway because it can read process memory, read keystrokes, etc.
The app does not have to be overtly malicious, AccuWeather (among others) was caught exfiltrating users' clipboard data for over 4 years to an analytics company who may or may not have gotten compromised. Even if the direct application you are using is non-malicious, you are left hoping wherever your data ends up isn't a giant treasure trove/honeypot waiting to be compromised by attackers.
The same reasoning can be used for pretty much anything really, why protect anything locally since they could just keylog you or intercept requests you make.
In that case it would be safer for everyone to run Qubes OS and stringently check any application added to their system.
In the end it's a balancing act between convenience and security with which striving for absolute perfection ends up being an enemy of good.
> Sidenote: Most password managers I've used automatically clear the clipboard 10-15s after you copy a credential.
That is true, good password managers took these steps precisely to reduce the clipboard attack surface.
Firefox also took steps in 2021 to also limit leaking secrets via the clipboard.
Webpages can't read clipboard history, so this wouldn't apply.
I was responding to your guidance to clear your clipboard history after copying a password.
>The app does not have to be overtly malicious, AccuWeather (among others) was caught exfiltrating users' clipboard data for over 4 years to an analytics company who may or may not have gotten compromised.
But clearing your clipboard after pasting passwords wouldn't protect you from this attack. That was the recommendation I disagreed with.
The same reasoning can be used for pretty much anything really, why protect anything locally since they could just keylog you or intercept requests you make.
Yes, I agree. But that's why I think people should focus their energy on defending along trust boundaries.[0] There's no trust boundaries between applications running in the same user context on the same system. There is a trust boundary between a web app and local apps, so I think it makes sense to consider what a malicious web app can do (e.g., read the most recent clipboard contents), but we shouldn't lump web apps in with local desktop apps.
I always manually type the emails and usernames for this reason.
(A keylogger is already game over, so.)
This doesn't seem to be "passwords on random pages", only "Personal Data + Credit Card,", passwords are domain-specific unless the website is hacked itself.
> The attacker can only steal credentials for the vulnerable domain.
Can't KeePass use the autotype functionality, but still filter it by website domain/host that it gets from the extension? So basically you'll still never have to copy&paste, and any site requiring this would be a reliable red flag?
Is this actually accurate? Packages with weekly downloads in the hundreds of thousands, yet in the 4+ hours that the malicious versions were up for, not a single person updated any of them to the latest patch release?
Microsoft has been bravely saying "Security is top priority" since 2002 (https://www.cnet.com/tech/tech-industry/gates-security-is-to...) and every now and then reminds us that they put "security above all else" (latest in 2024: https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...), yet things like this persists.
For how long time do Microsoft need to leave wide-open holes for the government to crack down on their wilful ignorance? Unless people go to jail, literally nothing will happen.
npm stats lag. We observed installs while the malicious versions were live for hours before removal. Affected releases we saw: duckdb@1.3.3, @duckdb/duckdb-wasm@1.29.2, @duckdb/node-api@1.3.3, @duckdb/node-bindings@1.3.3. Same payload as yesterday’s Qix compromise. Recommend pinning and avoiding those versions, reviewing diffs, and considering a temporary policy not to auto-adopt fresh patch releases on critical packages until they age.
I also know projects who are reading the update feeds and kick off CI jobs after any dependencies are updated to automatically test version upgrades, surely at least one dependent of DuckDB is doing something similar.
Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing.
You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-user with your public key. Even if your NPM account gets taken over, the attacker does not have your private key, so they cannot publish valid packages as you.
But because these platforms don't enforce code and artifact signing, and their tools aren't verifying those signatures, attackers just have to figure out a way to upload their own poison package (which can happen in multiple ways), and everyone is pwnd. There must be a validated chain of trust from the developer's desktop all the way to the end user. If the end user can't validate the code they were given was signed by the developer's private key, they can't trust it.
This is already implemented in many systems. You can go ahead and use GitHub and 1Password to sign all your commits today, and only authorize unsealing of your private key locally when it's needed (git commits, package creation, etc). Then your packages need to be signed too, public keys need to be distributed via multiple paths/mirrors, and tools need to verify signatures. Linux distributions do this, Mac packages do, etc. But it's not implemented/required in all package managers. We need Npm and other packaging tools to require it too.
After code signing is implemented, then the next thing you want is 1) sign-in heuristics that detect when unusual activity occurs and either notifies users or stops it entirely, 2) mandatory 2FA (with the option for things like passkeys with hardware tokens). This will help resist phishing, but it's no replacement for a secure software supply chain.
Strongly agree on artifact signing, but it has to be real end-to-end. If the attacker can trigger your CI to sign with a hot key, you still lose. What helps: 1) require offline or HSM-backed keys with human approval for release signing, 2) enforce that published npm artifacts match a signed Git tag from approved maintainers, 3) block publishes after auth changes until a second maintainer re-authorizes keys. In today’s incident the account was phished and a new token was used to publish a browser-side wallet-drainer. Proper signing plus release approvals would have raised several hard gates.
No, with the _requirement_ for passkeys or hardware tokens!
They already make links go through redirects (to avoid referrer headers?) so it's halfway there. Just make the redirect page show the link and a go button instead of redirecting automatically. And it would fix the annoyance that is not being able to see the real domain when you hover the link.
The single one method how to install DuckDB on laptop is to run
`curl https://install.duckdb.org | sh`
I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091
As you can see that it isn't single slip due to "human factor", but DuckDB management consistently puts users at risk.
Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?
Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell. Either way, you are depending entirely on the legitimacy of their domain right?
You're about to install and run their software. If they wanted to do something malicious, they wouldn't hide it in their plaintext install script.
A server can use this to maliciously give you malware only if you're not looking at the code.
Though your point about trust is valid.
Sure a binary can be swapped in other places, but they generally can be verified with hashes and signatures. Also, a plaintext install script often has this problem in another layer of recursion (where the script usually pulls from URLs that the runner of the script cannot verify with this method)
Suppose the site got compromised. If you separately explicitly download the install script first, in principle you can review it before running it.
Same deal with installing Python source packages (sdists). Arbitrary code included in the package runs at installation time (with the legitimate purpose of orchestrating any needed build steps, especially for non-Python code, which could be arbitrarily complex). This is worse than importing the installed code and letting it run whatever top-level code, because the entire installation is normally automated and there's no point where you review the code before proceeding. We do generally accept this risk in the Python ecosystem, but demanding to install only from pre-built wheels is safer (it just isn't always possible).
(Pip has the problem that this still happens even if you use its "download" command — because it wants to verify that building the project would produce a package with a name and version that match what it says in the file name and/or other metadata, and because it wants to know what the dependencies are — and in the general case it's permitted to depend on the build process to tell you this, because the system for conditional-on-platform dependencies isn't powerful enough for everyone's use case. See also: https://zahlman.github.io/posts/2025/02/28/python-packaging-...)
They should only need http. You don't need https at all if your package is signed. The package/installer/app/etc could come from anywhere, modified by anyone, at any level. But if it's not signed by the dev's private key (which only exists on their laptop [or hardware token], protected by a password/key manager), it's invalid. This avoids the hundred different exploits between the dev and the user.
What's actually crazy about this is, if you're already making the user do a copy and paste, it doesn't have to be one line. Compare that line above, to:
(set -eu; tmpf="$(mktemp)"; [ -w "$tmpf" ] &&
curl https://install.duckdb.org/ -o "$tmpf" &&
echo "d5d91c69a874ef99c30cf36654f623ed9c423ed0e210dca229744ce4d3b273d0 *$tmpf" | sha256sum -c - &&
bash "$tmpf")
It is amazing that a duckdb could be worse than decade old PHP for something such as this.
curl -f
Tomorrow they will do it again, and attackers will replace binary files that users download with this random script. Or this script will steal crypto/etc.
To make attack vector difficult for hackers, it's preferable to download any software as packages. On linux it looks like `apt install python3`.
The benefits is
1. Repositories are immutable, so attacker can't replace binary for specific version, even if they will hack all infrastructure of DuckDB. Remote script may be replaced anytime to run any code
2. Some repositories have strict review process, so there are external reviewers who will require to pass security processes to upload new version
for MacOS they have it in brew, which is also you can use on linux, also it is available in nix.
I think the problem is that there are so many linux distros with their own package repositories, that it is very untrivial task to include package into most of them if maintainers are not proactively interested.
Running scripts even more so.
One day someone might decide simply to exploit whatever trust they have.
Actually I wonder how much black market would pay for rights to change reasonable popular script like that...
> depending entirely on the legitimacy of their domain
Just move the phishing attack down each step of your dependency chain.
https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
But never ever anyone was rooted because of malware that was snuck into an official .deb package.
That was the concept of "stable" in the good old time, when software was really an "engineering" field.
We got pretty close with the whole XZ thing. And people generated predictable keys due to a flaw in a debian patch to openssl.
This stuff is hard and I'm not saying that npm is doing well but seems like no large ecosystem is doing exceptionally well either.
Sure. The tradeoff is that when there's a zero-day, you have to wait for Debian to fix it, or to approve and integrate the dev's fix. Finding malware is one thing; finding unintentional vulns is another.
We all dodged a bullet - https://news.ycombinator.com/item?id=45183029 - Sept 2025 (273 comments)
NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 - Sept 2025 (719 comments)
PyPI also now requires 2FA for everyone and makes other proactive attempts to hunt down malware (https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f...) in addition to responding to reports.
There was still a known compromise recently: https://blog.pypi.org/posts/2025-07-31-incident-report-phish... (`num2words` gets millions of monthly downloads, but still for example two orders of magnitude less than NumPy). Speaking of the communication I mentioned in the first paragraph, one of the first people reporting seeing the phishing email was a CPython core developer.
Malware also still does get through regularly, in the form of people just uploading it. But there are automated measures against typo-squatting (you can't register a name that's too similar to existing names, or which is otherwise blacklisted) and for most random crap there's usually just no reason anyone would find out about it to install it.
I wonder if it really is only npm that got compromised.
This is absolutely wild that this did not raise _any_ red flags to this person.
red flag: random reset for 2FA ??? red flag: npmjs.help ??? red flag: user name and password not autofilled by browser ??? red flag: copy and pasting u/p combo into phishing site
If _developers_ can't even get this right. Why do we expect dumb users to get this right? We are so cooked.
I cannot be bother to remember every hole name. They're all USB anyway, the difference is that some are A, C, or Lightning, I bought a new MacBook and it has that magnet hole, what is that called? I'm not following.
The stuff I deal with every day is centering divs
> it's too hard to keep track of the names of the three different ports
it's more than three ports.
> do you now need to maintain two keys for every service?
I do maintain multiple keys for every service. I wouldn't say it's a lot of maintenance, any more than a far more secure "remember me" box is "maintenance".
When I register for a new service, I add my hardware token on my keychain as a passkey. I sign in on my laptop for the first time for a service I'll use there more than once, I make a passkey. I sign in on my desktop for the first time, I make a passkey, maybe make a spare in my password manager. Maybe if it's something I use on my phone, I'll make a passkey there as well when I sign in for the first time. When I get around to it, I'll add the spare hardware token I keep in a drawer. But its not like "I just signed up for a new service, now I must go around to every device and make a new passkey immediately. As long as I've got a couple of passkeys at registration time, I'm probably fine.
Lose my laptop? Its ok, I've got other passkeys. Lose my keys? Its ok, I've got other passkeys. My laptop and keys get stolen at the same time? Its ok, I've got other passkeys.
Its really not that hard.
Yes, they support NFC
> or do you now need to maintain two keys for every service?
I maintain 4 keys so I have backups. In most cases registering additional keys is no problem, and this is only needed when signing up.
The idea is that if your password manager doesn't show the usual list of accounts (regardless if the actual autofill after clicking the account works or not), you double-check the domain.
Not at all? The password manager handles that automatically, have you never used a password manager before?
> Passkeys will automate and enforce the check
What happens to the passkey when the origin changes, is it automatically recognising it as the new domain without any manual input? Curious to see what magic is responsible for that
Yes: '...you double-check the domain.' That's manually checking for mistakes.
> What happens to the passkey when the origin changes,
The passkey won't work at all. You will just have to create a new one.
Yes, but that's only when the origin changed compared to when you added it to the password manager. Same thing for Passkeys, won't work if the origin is different, so you double-check that the domain in your browser address bar is the correct one.
Obviously normally you don't do anything except click on the account that shows up, since the domain matches.
You could claim that a phishing site could set up their own passkey registration system–but that still wouldn't give them access to the target's real account.
So exactly the same as password managers, there is no functional difference if you were using a password manager...
Considering that today it'd add work for me today, and future work, with no additional security benefits compared to my current approach, it just don't seem worth it.
A few concrete datapoints from our analysis of this incident that may help cut through the hand-waving:
1. This is the same campaign that hit Qix yesterday (https://socket.dev/blog/npm-author-qix-compromised-in-major-...). The injected payload is byte-for-byte behaviorally identical. It hooks fetch, XMLHttpRequest, and common wallet provider APIs and live-rewrites transaction payloads to attacker addresses across ETH, BTC, SOL, TRX, LTC, BCH. One tell: a bundle of very distinctive regexes for chain address formats, including multiple Solana and Litecoin variants.
2. Affected versions and timing (UTC) that we verified:
- duckdb@1.3.3 at 01:13
- @duckdb/duckdb-wasm@1.29.2 at 01:11
- @duckdb/node-api@1.3.3 at 01:12
- @duckdb/node-bindings@1.3.3 at 01:11
Plus low-reach test shots: prebid@10.9.1, 10.9.2 and @coveops/abi@2.0.1
3. Payout so far looks small. Tracked wallets sum to roughly $600 across chains. That suggests speed of discovery contained damage, not that the approach is harmless.
What would actually move the needle:
=== Registry controls ===
- Make passkeys or FIDO2 mandatory for high-impact publisher accounts. Kill TOTP for those tiers.
- Block publishing for 24 hours after 2FA reset or factor changes. Also block after adding a new automation token unless it is bound by OIDC provenance.
- Require signed provenance on upload for popular packages. Verify via Sigstore-style attestations. Reject if there is no matching VCS tag.
- Quarantine new versions from being treated as “latest” for automation for N hours. Exact-version installs still work. This alone cuts the blast radius of a hijack.
=== Team controls ===
- Do not copy-paste secrets or 2FA. Use autofill and origin-bound WebAuthn.
- Require maker-checker on publish for org-owned high-reach packages. CI must only build from a signed tag by an allowed releaser.
- Pin and lock. Use `npm ci`. Consider an internal proxy that quarantines new upstream versions for review.
=== Detection ===
- Static heuristics catch this family fast. Wallet address regex clusters and network shims inside non-crypto packages are a huge tell. If your tooling sees that in a data engine or UI lib, fail the build.
Lastly, yes, training helps, but the durable fix is making the easy path the safe path.
This should not be considered high effort or a sophisticated attack. The attacker probably used a mitm proxy which can easily replicate every part of your site, with very little initial configuration. Evilginx is the most popular one I could think of
A week waiting period would not be enough. On average, npm malware lingers on the registry for 209 days before it's finally reported and removed.
Source: https://arxiv.org/abs/2005.09535
So, regrettably, we're back to "train users" and all the pitfalls that entails
[0]: legacy 1.x projects aside
"Hi, XXXX! It looks like you still do not have two-factor authentication (2FA) enabled on your npm account.
To enable 2FA, please follow the instructions found here."
Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here
But, this coming from GitHub, who believe that sliding "v1" tags on random action repos is how one ends up with https://news.ycombinator.com/item?id=43367987
Every dependency is a backdoor, To make them malicious it only take s a small slip up
Any idea what the interference was?
I certainly wouldn't. And I don't see it as pointless theater. It requires deliberate action, and that's what's missing here.
downvotes appreciated but also happy to see one or two urls that would prove me wrong
Second - an example for a javascript heavy npm utilizing tracking heavy / low content site has not much weight in proving me right - my view is an assumption - 2 examples of shitty tracking SEO AI garbage content blubber sites not using npm would substantially question my assumption... I am genuinely interested in the tech those sites would use instead.
How can anyone publish their packages?
This is the second high-profile instance of the technique this week.
Are they actively forcing it? I've received the "Remember to enable 2FA" email notifications from NPM since 2022 I think, but haven't bothered since I'm not longer publishing packages/updates.
Besides, the email conveniently mentions their "automation" tokens as well, which when used for publishing updates, bypasses 2FA fully.
https://old.reddit.com/r/node/comments/xftu7i/comment/iooabn...
Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.
From what I've heard, they're also unbackupable, and tied to the ecosystem used to create them (so if you started with an Apple desktop, you can't later migrate the passkeys to a Windows desktop, you have to go to every single site you've ever used and create new ones).