10 ms·
DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware
- arewethereyeta 1y ago> An attacker published new versions of four of duckdb’s packages that included malicious code to interfere with cryptocoin transactions How can anyone publish their packages?
- deleted 1y ago[deleted]
- pneff 1y agoThere is a detailed postmortem in the linked ticket explaining exactly how this happened.
- masfuerte 1y agoThis is the same phishing attack that hit junon yesterday. https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657
- OtherShrezzing 1y agoThe attacker emailed a maintainer from a legitimate looking email address. The maintainer clicked the link and reset their credentials on a legitimate looking website. The attacker then signs into the legitimate duckdb account and publishes their new package. This is the second high-profile instance of the technique this week.
- arewethereyeta 1y ago2FA for such high profile packages should be enforced
- jsheard 1y agoIt is, if your packages are popular enough then npm will force you to enable 2FA. They started doing that a few years ago. It clearly doesn't stop everything though, the big attack yesterday went through 2FA by tricking the author into doing a "2FA reset".
- frizlab 1y agoPasskeys should be enforced
- frizlab 1y agoI take the downvote but I’d like to know why? Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.
- cesarb 1y ago> 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).
- smw 1y agoYou can't really backup hardware tokens, either? It's quite possible to use something like bitwarden/vaultwarden/1password as a password manager, and you can "backup" tokens quite easily without being tied to a particular mobile/desktop ecosystem.
- frizlab 1y agoThat’s not true anymore; you can migrate passkeys to another password manager now.
- yawaramin 1y ago
- bakugo 1y ago> According to the npm statistics, nobody has downloaded these packages before they were deprecated Is this actually accurate? Packages with weekly downloads in the hundreds of thousands, yet in the 4+ hours that the malicious versions were up for, not a single person updated any of them to the latest patch release?
- diggan 1y agoI think that's pretty unlikely. I aren't even a high-profile npm author, and if I publish any npm package they end up being accessed/downloadaded within minutes of first publish, and any update after that. 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.
- hfmuehleisen 1y agoDuckDB maintainer here, thanks for flagging this. Indeed the npm stats are delayed. We will know in a day or so what the actual count was. In the meantime, I've removed that statement.
- belgattitude 1y agoI think you should unpublish rather than deprecate... `npm unpublish package@version` ... It's possible within 72h. One reason is that the patched version contains -alpha... so tools like npm-check-updates would keep the 1.3.3 as the latest release for those who installed it
- hfmuehleisen 1y agoYes we tried, but npm would not let us because of "dependencies". We've reached out to them and are waiting for a response. In the meantime, we re-published the packages with newer versions so people won't accidentally install the compromised version.
- 1y ago
- mediumsmart 1y agoComes with the territory considering that npm is defacto the number one enshittification dependency by now. But no worries - this will scale beautifully. downvotes appreciated but also happy to see one or two urls that would prove me wrong
- eviks 1y agoIn the spirit of a substantive discussion could you likewise share a couple that would prove you right?
- mediumsmart 1y agoFirst of all I have a theory that nothing can be proven but I can't prove it. 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.
- eviks 1y agoIf you have such a theory, how does it make sense to ask others to do the impossible and prove anything???
- mediumsmart 1y agothats a fortune cookie - please stay on topic :)
- hiccuphippo 1y agoI think the downvotes are because enshittification is a different thing, intentionally done by the developers themselves.
- mediumsmart 1y ago
- deleted 1y ago[deleted]
- diggan 1y agoSo far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though. I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?
- skeeter2020 1y ago>> So far, it seems to be a bog-standard phishing email 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.
- r_lee 1y agoHow does AI relate to this in any way? you can easily clone websites by just copying via devtools, like seriously same with just copying email HTML it's actually easier to make it looke exactly the same vs different in some ways
- mvieira38 1y agoYou can make your phishing bot write tailor-made messages and even respond
- deleted 1y ago[deleted]
- diggan 1y agoBoth of those points are fairly common in phishing emails, at least the ones I receive. Cloning the HTML/CSS for phishing has been done for as long as I've been able to receive emails, don't even need LLMs for that :)
- lovehashbrowns 1y agoI guess it's hands off the npm jar for a week or three 'cause I am expecting a bunch more packages to be affected at this point.
- koakuma-chan 1y agoShould enforce passkeys not 2FA
- cr125rider 1y agoHow is that different?
- koakuma-chan 1y agoPasskey only works when you're on the correct website
- 243423443 1y agoCare to explain?
- vladvasiliu 1y agoThe actual URL in the browser is part of what the passkey signs. So if you go to totallynotascam.com which turns out to be some dude intercepting and passing the connection to npm, the signature would be refused by npm since it wouldn't be for the correct domain.
- diggan 1y agoUse a password manager (that isn't too buggy and/or suck) and you get the same thing for both TOTP and passwords.
- koakuma-chan 1y agoNpm can't force people to use password manager
- diggan 1y agoNor does TOTP+password lock you to one authentication provider indefinitely. Tradeoffs :)
- ebfe1 1y agoIs it just me who think this could have been prevented if npm admins put in some sort of cool off period to only allow new versions or packages to be downloaded after being published by "x" amount of hours? This way the npm maintainer would get notifications on their email and react immediately? And if it is urgent fix, perhaps there can be a process to allow npm admin to approve and bypass publication cool off period. Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here
- herpdyderp 1y agoIf I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else.
- balder1991 1y agoIt could be done like a rollout in % over time like app stores do.
- kaelwd 1y agoIt would be fine if you could still manually specify those versions eg. npm i duckdb@1.3.3 installs 1.3.3 but duckdb@latest or duckdb@^1.3 stays on 1.3.2 until 1.3.3 is ~a week old. https://github.com/pnpm/pnpm/issues/9921 https://github.com/pnpm/pnpm/issues/9921
- herpdyderp 1y agoBrilliantly simple, that would work for me!
- ApolloFortyNine 1y agoExcept they'd have to have an override for when there's a zero day, at which point we're back where we started.
- kaelwd 1y ago
- skylurk 1y agoI hate the janky password manager browser extensions but at least they make it hard to make this mistake.
- smw 1y agoAnd passkeys or hardware tokens (FIDO/yubikeys) make it impossible
- eviks 1y ago> This website contained a *pixel-perfect copy* of the npmjs.com website. Not sure how this emphasis is of any importance, you brain doesn't have a pixel perfect image of the website, so you wouldn't know whether it's a perfect replica or not. Let the silicon dummies in the password manager do the matching, don't strain your brain with such games outside of entertainment
- stanac 1y agoMy password manager is a separate app, I always have to manually copy/paste the credentials. That's because I believed that approach to be more secure, now I see it's replacing one attack vector for another.
- eviks 1y agoWhat's the most common example of an alternative attack with autofill?
- kaoD 1y agoThe password manager's autofill browser extension gets compromised.
- deleted 1y ago[deleted]
- karel-3d 1y agojust recently there was a clickjacking attack that affected most popular password manager extensions. It tricked the managers into filling passwords to random pages, worked on almost all extensions and all pages.
- weinzierl 1y agoIs this related to npm debug and chalk packages being compromised? https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
- cefboud 1y ago> malicious code to interfere with cryptocoin transactions Any idea what the interference was?
- hiccuphippo 1y agoMaybe email software should add an option to make links unclickable, or show a box with the clear link (and highlight the domain) before letting the user go through it. They already make links go through redirects (to avoid referrer headers?) so it's halfway there. Just make the redirect page show the link and a go button instead of redirecting automatically. And it would fix the annoyance that is not being able to see the real domain when you hover the link.
- elric 1y agoSo many legit emails contain links that pass through some kind of URL shortener or tracker (like mailchimp does). People are being actively conditioned to ignore suspicious looking URLs.
- ecshafer 1y agoI worked for a company that as part of phishing we were told not to click on suspicious links. However all links were put through proxy link shortener. So www.google.com becomes just proxy.com/randomstring like an internal link shortener/mitm. But this means I can no longer check the url to see if its legitimate.
- elric 1y agoThis is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time. People who publish software packages tend to be at least somewhat technical people. Can package publishing platforms PLEASE start SIGNING emails. Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform. Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks. And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.
- progx 1y agoTRUE! A simple self defined word in an email and you will see, if the mail is fake or not.
- zokier 1y agoSpf/dkim already authenticates the sender. But it doesn't help if the user doesn't check who the email is from. But in that case gpg would not help that much either.
- elric 1y agoSPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records. 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?
- polynomial 1y agoSerious question, how did the attacking site (npmjs.help) know the victim's 2fa? ie. How did they know what phone number to send the 2fa request to?
- xx_ns 1y agoIt acted as a proxy for the real npm site, which was the one to send the request, intercepting the code when the user inserted it.
- deleted 1y ago[deleted]
- feross 1y agoIt was a relay. The fake site forwarded actions to the real npm, so the legit 2FA challenge was triggered by npm and the victim entered the code into the phishing page. The attacker captured it and completed the session, then added an API token and pushed malware. Passkeys or FIDO2 would have failed here because the credential is bound to the real domain and will not sign for npmjs.help.
- ritcgab 1y agoFor critical infra projects like this, making a release should require at least three signatures from different maintainers. In fact, I am surprised that this is not a common practice.
- ptrl600 1y agoIs there a way to configure npm that it only installs packages that are, like, a week old?
- HatchedLake721 1y agoDon’t auto install latest versions, pick a version up to a patch and use package-lock.json
- mdaniel 1y agoThat's only half the story, as I learned yesterday <https://news.ycombinator.com/item?id=45172213 https://news.ycombinator.com/item?id=45172213> since even with lock files one must change the verb given to npm/yarn to have them honor the lock file So, regrettably, we're back to "train users" and all the pitfalls that entails
- 3np 1y agoMore importantly, avoid yarn[0] if you have a choice. They do not have a security posture fitting for 2025. There's way too much assumptions like "helpful" "magic" guessing/inferring what the user "actually wants" to "make things just work". See also: corepack. [0]: legacy 1.x projects aside
- feross 1y agoDisclosure: I’m the founder of https://socket.dev https://socket.dev 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 https://arxiv.org/abs/2005.09535
- ptrl600 1y agoOK, a week for popular packages, anything else I'd manually review each update. It'd be a nice feature.
- theanonymousone 1y agoHow do these things mostly happen for npm? Why not (much) PyPI or Maven? Or do they?
- johnisgood 1y agoOr Cargo. I compiled Zed with release mode, pulled in 2000 dependencies. It does not fill me with confidence.
- hu3 1y agoOn a related note, the maintainer of the compromised npm packages, debug and chalk, who got pawned, is creating an operational system in rust. https://github.com/oro-os https://github.com/oro-os https://news.ycombinator.com/user?id=junon https://news.ycombinator.com/user?id=junon
- johnisgood 1y agoGood to know! Hopefully others will be delighted to see, too. I wonder if it really is only npm that got compromised.
- zahlman 1y agoPython has a heavy standard library, and the most popular third-party libraries tend to have simple dependency graphs because they can lean on that standard library so much. Many of them are also maintained under umbrellas such as the Python Software Foundation (for things like `requests`) or the Python Packaging Authority (for build tools etc.). So there are many eyes on everything all the time, those eyes mostly belong to security-conscious people, and they all get to talk to each other quite a bit. 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-2fa/ 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-phishing-attack/ 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.
- 0xbadcafebee 1y agoAt least third major compromise in two weeks. (last comment: https://news.ycombinator.com/item?id=45172225 https://news.ycombinator.com/item?id=45172225) (before that: https://news.ycombinator.com/item?id=45039764 https://news.ycombinator.com/item?id=45039764) Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing. You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-user with your public key. Even if your NPM account gets taken over, the attacker does not have your private key, so they cannot publish valid packages as you. But because these platforms don't enforce code and artifact signing, and their tools aren't verifying those signatures, attackers just have to figure out a way to upload their own poison package (which can happen in multiple ways), and everyone is pwnd. There must be a validated chain of trust from the developer's desktop all the way to the end user. If the end user can't validate the code they were given was signed by the developer's private key, they can't trust it. This is already implemented in many systems. You can go ahead and use GitHub and 1Password to sign all your commits today, and only authorize unsealing of your private key locally when it's needed (git commits, package creation, etc). Then your packages need to be signed too, public keys need to be distributed via multiple paths/mirrors, and tools need to verify signatures. Linux distributions do this, Mac packages do, etc. But it's not implemented/required in all package managers. We need Npm and other packaging tools to require it too. After code signing is implemented, then the next thing you want is 1) sign-in heuristics that detect when unusual activity occurs and either notifies users or stops it entirely, 2) mandatory 2FA (with the option for things like passkeys with hardware tokens). This will help resist phishing, but it's no replacement for a secure software supply chain.
- smw 1y ago"2) mandatory 2FA (with the option for things like passkeys with hardware tokens)." No, with the _requirement_ for passkeys or hardware tokens!
- 0xbadcafebee 1y agoThey don't work everywhere, and when they do work they're not a panacea. It's like host-based security: if you get past this one barrier... what, everything is completely pwnd? You need defense in depth. That means the authentication factor(s) must not be the final word in security. So not using a passkey or hardware token shouldn't be a death knell.
- jeswin 1y agoPublishing could require clicking an email confirmation link, sent by npm.
- petcat 1y agoIt's all pointless theater because people want less friction to do what they want, not more. They'll just automate away the friction points like clicking an email confirmation link.
- jeswin 1y agoIf you're the author of ducklib, and you get an email asking "Did you just publish ducklib 2.4.1?" with a fair number of warnings in the mail text, will you click on the publish link? I certainly wouldn't. And I don't see it as pointless theater. It requires deliberate action, and that's what's missing here.
- vitonsky 1y agoJust for context. DuckDB team is consistently ignores any security practices. The single one method how to install DuckDB on laptop is to run `curl https://install.duckdb.org 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 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.
- throwaway127482 1y agoGenuine question: why is `curl https://trusted-site.com https://trusted-site.com | sh` a security 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?
- speedgoose 1y agoI also don’t know why using a unix pipe instead of saving in the file system and executing the file is a significant security risk. Perhaps an antivirus could scan the file without the pipe.
- dansmith1919 1y agoI assume OP's point is "you're running a random script directly into your shell!!" 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.
- tomsmeding 1y agoIt is sometimes possible to detect server-side whether the script is being run immediately with `| sh` or not. The reason is that `sh` only reads from its input as far as it got in the script, so it takes longer to get to the end than if you'd curl show the result in the terminal directly (or pipe it to a file). 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.
- udev4096 1y ago> This website contained a pixel-perfect copy of the npmjs.com website This should not be considered high effort or a sophisticated attack. The attacker probably used a mitm proxy which can easily replicate every part of your site, with very little initial configuration. Evilginx is the most popular one I could think of
- kyle-rb 1y agoI've been critical of blockchain in the past because of the lack of use cases, but I've gotta say crypto functions pretty well as an underlying bug bounty system. This probably could have been a much more insidious and well hidden attack if there wasn't a quick payoff route to take.
- tripplyons 1y agoThat argument only really makes sense if you assume the attackers aren't rational actors. If there was a better, more destructive way to profit from this kind of compromise, they would either do it or sell their access to someone who knew how to do it.
- kyle-rb 1y agoAh, apparently other people had thoughts along the same lines: https://news.ycombinator.com/item?id=45183029 https://news.ycombinator.com/item?id=45183029
- feross 1y agoDisclosure: I'm the founder of https://socket.dev https://socket.dev. A few concrete datapoints from our analysis of this incident that may help cut through the hand-waving: 1. This is the same campaign that hit Qix yesterday (https://socket.dev/blog/npm-author-qix-compromised-in-major-supply-chain-attack 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.
- greatgib 1y agoWhat is funny is again how many "young developers" had fun at old timers package managers like Debian being so slow to release new versions of packages. But never ever anyone was rooted because of malware that was snuck into an official .deb package. That was the concept of "stable" in the good old time, when software was really an "engineering" field.
- SahAssar 1y ago> But never ever anyone was rooted because of malware that was snuck into an official .deb package. 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.
- cenamus 1y agoI'd say jus about every major linux dist is doing about 2 orders of magnitude better than npm
- deleted 1y ago[deleted]
- zahlman 1y ago> But never ever anyone was rooted because of malware that was snuck into an official .deb package. 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.
- dang 1y agoRelated. Others? We all dodged a bullet - https://news.ycombinator.com/item?id=45183029 https://news.ycombinator.com/item?id=45183029 - Sept 2025 (273 comments) NPM debug and chalk packages compromised - https://news.ycombinator.com/item?id=45169657 https://news.ycombinator.com/item?id=45169657 - Sept 2025 (719 comments)
- hoppp 1y agoWhy the hell we use npm, Every dependency is a backdoor, To make them malicious it only take s a small slip up
- xyst 1y ago> ... One of the maintainers read through this text and found it somewhat reasonable. He followed the link (now defunct) to a website hosted under the domain npmjs.help. This website contained a pixel-perfect copy of the npmjs.com website. He logged in using the duckdb_admin user and password, followed by 2FA. Again, the user profile, settings etc. were a perfect copy of the npmjs.com website including all user data. As requested by the email, he then re-set the 2FA setup. This is absolutely wild that this did not raise _any_ red flags to this person. red flag: random reset for 2FA ??? red flag: npmjs.help ??? red flag: user name and password not autofilled by browser ??? red flag: copy and pasting u/p combo into phishing site If _developers_ can't even get this right. Why do we expect dumb users to get this right? We are so cooked.
- karel-3d 1y agonpm actually does send these emails. They are about setting up 2FA though. And never have this sense of urgency. "Hi, XXXX! It looks like you still do not have two-factor authentication (2FA) enabled on your npm account. To enable 2FA, please follow the instructions found here."
- lima 1y agoUsing Security Keys/FIDO2 instead of TOTP codes completely solves trivial phishing attacks like this one.
- Berry141 1y ago[dead]