HN Reader

Here we are again. 12 days ago (https://news.ycombinator.com/item?id=45039764) I commented how a similar compromise of Nx was totally preventable.

Again, this is not the failure of a single person. This is a failure of the software industry. Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. We're software developers... we're the ones to implement them.

Every software packaging platform on the planet should already require code signing, artifact signing, user account attacker access detection heuristics, 2FA, etc. If they don't, it's not because they can't, it's because nobody has forced them to.

These attacks will not stop. With AI (and continuous proof that they work) they will now get worse. Mandate software building codes now.

NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.

From sindresorhus:

You can run the following to check if you have the malware in your dependency tree:

`rg -u --max-columns=80 _0x112fa8`

Requires ripgrep:

`brew install rg`

https://github.com/chalk/chalk/issues/656#issuecomment-32668...

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.

I thought it stupid that there were some old established electro-mechanical manufacturing companies that would just block github.com and Internet downloads in general, only allowing codes from internal repos that took months to get approved, breaking npm dependent workflows.

Now? Why aren't everyone setting up own GitHub mirrors is beyond me, almost. They were 100% right.

@junon, if it makes you feel any better, I once had a Chinese hacking group target my router and hijack my DNS configuration specifically to make "amazon.com" point to 1:1 replica of the site just to steal my Amazon credentials.

There was no way to quickly visualize that the site was fake, because it was in fact, "actually" amazon.com.

Phishing sucks. Sorry to read about this.

Edit: To other readers, yes, the exploit failed to use an additional TLS attack, which was how I noticed something was wrong. Otherwise, the site was identical. This was many years ago before browsers were as vocal as they are now about unsecured connections.

It was a pain in the ass but I always appreciated that Maven central required packages to be signed with a public key pre-associated with the package name.

looks like it won't affect you if you just downloaded the packages locally.

the actual code only runs in a browser context - it replaces all crypto addresses in many places with the attacker's.

a list of the attacker's wallet addresses: https://gist.github.com/sindresorhus/2b7466b1ec36376b8742dc7...

It wouldn't be a perfect solution, but I wonder why browsers don't indicate the registration date for a domain in the URL bar somehow? I bet junon would have seen that and gotten suspicious.

I can't imagine all the struggle the author must feel like.

Like the need to constantly explain himself because of one single blunder.

It shows how much so many open source projects rely on dependencies which are owned by one person and they can be pwned and (maybe hacked too)

Everyone can get pwned I suppose. From a more technical perspective though, from the amounts of times I am listening AI,AI & AI BS, Couldn't something like deno / node / bun etc. just give a slight warning on if they think that the code might be malware or, maybe the idea could be that we could have a stable release that lets say could be on things like debian etc. which could be verified by external contributors and then instead of this node world moving towards @latest, we move towards something like @verified which can take builds / source from something like debian maintained or something along that way...

I hope people can understand that author is a human too and we should all treat him as such and lets treat him with kindness because I can't imagine what he might be going as I said. Woud love a more technical breakdown once things settle and we can postmortem this whole situation.

Wow, I also received the same phishing email even though my packages only have a few hundred downloads a week (eg. bsky-embed).

So I guess a lot more accounts/packages might be affected than the ones stated in the article

Finally validated for writing my own damn ANSI escape codes.

I'm a little confused after reading everything. I have an Expo app and if I run `npm audit`, I get the notification about `simple-swizzle`.

The GitHub page (https://github.com/advisories/GHSA-hfm8-9jrf-7g9w) says to treat the computer as compromised. What does this mean? Do I have to do a full reset to be sure? Should I avoid running the app until the version is updated?

>> which silently intercepts crypto and web3 activity in the browser, manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user.

If you're doing financial transactions using a big pile of NPM dependencies, you should IMHO be financially liable for this kind of thing when your users get scammed.

This is really scary. It could have totally happened to me too. How can we design security which works even when people are tired or stressed?

Once upon a time, I used a software called passwordmaker. Essentially, it computed a password like hash(domain+username+master password). Genius idea, but it was a nightmare to use. Why? Because amazon.se and amazon.com share the same username/password database. Similarly, the "domain" for Amazon's app was "com.amazon.something".

Perhaps it's time for browser vendors to strongly bind credentials to the domain, the whole domain and nothing but the domain, so help me Codd.

The irony of this post's reception a few hours ago: https://news.ycombinator.com/item?id=45167394

DuckDB pwned by same attack: https://github.com/duckdb/duckdb-node/security/advisories/GH...

I've posted this idea already last time with the nx incident: we need some mechanism for package managers to ignore new packages for a defined time. Skip all packages that were published less than 24 hours ago.

Most of those attacks are detected and fixed quickly, because a lot of people check newly published packages. Also the owners and contributors notice it quickly. But a lot of consumers of the package just install the newest release. With some grace period those attacks would be less critical.

This looks pretty bad. Even if this only affects crypto wallets, I can't help but imagine how much worse this could be.

Another good read is at https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...

Using a security key instead of TOTP would have prevented this.

One reason why i run everything on my development machine in a docker container, you can't trust any package.

I use bun, but similar could be done with npm

Add to .bashrc:

  alias bun='docker run --rm -it -u $(id -u):$(id -g) -p 8080:8080 -v "$PWD":/app -w /app my-bun bun "$@"'

then you can use `bun` command as usual.

Dockerfile:

  FROM oven/bun:1 AS base
  VOLUME [ "/app" ]
  EXPOSE 8080/tcp
  WORKDIR /app
  # Add your custom libs
  # RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get -y install \
  #  ... \

Create once the container:

  $ docker build -t "my-bun" -f "Dockerfile" .

For everyone wondering: the code looks this way: https://web.archive.org/web/20250908162250/https://cdn.jsdel...

Got it from the "simple-swizzle" package that hasn't been taken down by NPM.

Actually, my problem is not really with NPM itself or the fact that it can be hacked, but with the damn auto-update policy of software – as users we usually have no idea which versions are installed, and there is even no way to roll back to a safe version.

All these Chrome, VSCode, Discord, Electron-apps, browser extensions, etc – they all update ± every week, and I can't even tell what features are being added. For comparison, Sublime updates once a YEAR and I'm totally fine with that.

You too can run malware from NPM (I mean without consequences)

https://github.com/naugtur/running-qix-malware?tab=readme-ov...

How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com?

Also, the package 1.3.3 has been downloaded 0 times according to npmjs.com, how can the writer of this article has been able to detect this and not increment the download counter?

Seems a quite targeted attack though, the phishing domain is registered just 4 days ago.

Also reported here: https://socket.dev/blog/npm-author-qix-compromised-in-major-...

Luckily this seems to be browser-specific, and not cryptocurrency malware that runs in Node.js environments, so it might be wise for us all to do some hardening on our software, and make sure we're doing things like version pinning.

Edit: As of this morning, `npm audit` will catch this.

Update: It seems like all packages of the author got hacked.

This is terrifying. Reminder to store your crypto in a hardware based wallet like Ledger not browser based. Stay frosty when making transfers from exchanges.

BTW: the NPM logo is blurry in that phishing email.

A package on the list called ‘simple-swizzle’ turns out to be used in OpenNext which is an unexpected attack vector for sure.

Does anybody have tips on how to invalidate a wallet address response if it's intercepted and modified like this?

I wanted to remind once again that hardware keys are immune to fishing because they check website domain unlike humans.

Maintainer phished.

Was caught quickly (hours? hard to be sure, the versions have been removed/overwritten).

Attacker owns npmjs.help domain.

Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight.

So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running underneath. And cryptocurrency and web3 aren't the only sensitive information that browsers handle. Meaning that similar exploits could arise targeting any of those. With millions of developers, someone is bound to repeat the same mistake sooner or later. And with some packages downloaded thousands of times per day, some CI/CD system will pull it in and publish it in production. This is a bigger problem than just a developer's oversight.

- How do the end user protect themselves at this point? Especially the average user?

- How do you prevent supply chain compromises like this?

- What about other language registries?

- What about other platforms? (binaries, JVM, etc?)

This isn't a rhetorical question. Please discuss the solutions that you use or are aware of.

Maybe it's time to declare the JS package world broken?

Damn, I use chalk... did they remove the malicious versions?

i use node/npm moderately

is there a runnable command to determine if the package list has a compromised version of anything?

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

I think Passkeys fixes this

What a ss email is

Is the npm package ecosystem fixable at this point? It seems to be flawed by design.

Is there a way to not accept any package version less than X months old? It's not ideal because malicious changes may still have gone undetected in that time span.

Time to deploy AI to automatically inspect packages for suspect changes.

Incidents like this show how fragile the supply chain really is. One compromised maintainer account can affect thousands of projects. We need better defaults for package signing + automated trust checks, otherwise we’ll just keep repeating the same cycle.”

The malware steals crypto in end-user browsers.

Another one for “web3 is going great”…

Cough passkeys would've prevented this.

Given that most of these kind of attacks are detected relatively quickly, NPM should implement a feature where it doesn't install/upgrade packages newer than 3 days, and just use the previous version.

Hi, yep I got pwned. Sorry everyone, very embarrassing.

More info:

- https://github.com/chalk/chalk/issues/656

- https://github.com/debug-js/debug/issues/1005#issuecomment-3...

Affected packages (at least the ones I know of):

- ansi-styles@6.2.2

- debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST)

- chalk@5.6.1

- supports-color@10.2.1

- strip-ansi@7.1.1

- ansi-regex@6.2.1

- wrap-ansi@9.0.1

- color-convert@3.1.1

- color-name@2.0.1

- is-arrayish@0.3.3

- slice-ansi@7.1.1

- color@5.0.1

- color-string@2.1.1

- simple-swizzle@0.2.3

- supports-hyperlinks@4.1.1

- has-ansi@6.0.1

- chalk-template@1.1.1

- backslash@0.2.1

It looks and feels a bit like a targeted attack.

Will try to keep this comment updated as long as I can before the edit expires.

---

Chalk has been published over. The others remain compromised (8 Sep 17:50 CEST).

NPM has yet to get back to me. My NPM account is entirely unreachable; forgot password system does not work. I have no recourse right now but to wait.

Email came from support at npmjs dot help.

Looked legitimate at first glance. Not making excuses, just had a long week and a panicky morning and was just trying to knock something off my list of to-dos. Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile).

Just NPM is affected. Updates to be posted to the `/debug-js` link above.

Again, I'm so sorry.

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list.

It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one.

This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction.

We did a full deobfuscation of the payload and analyzed this specific function. Wrote up the details here for anyone interested: https://jdstaerk.substack.com/p/we-just-found-malicious-code...

Stay safe!

> Yes, I've been pwned. First time for everything, I suppose. It was a 2FA reset email that looked shockingly authentic. I should have paid better attention, but it slipped past me. Sincerely sorry, this is embarrassing.

My worst nightmare is to wake up, see an email like that and hastily try to recover it while still 90% asleep, compromising my account in the process.

However, I think I can still sleep safe considering I'm using a password manager that only shows up when I'm on the right domain. A 2FA phishing email sending me to some unknown domain wouldn't show my password manager on the site, and would hence give me a moment to consider what's happening. I'm wondering if the author here wasn't using any sort of password manager, or something slipped through anyways?

Regardless, fucking sucks to end up there, at least it ends up being a learned lesson for more than just one person, hopefully. I sure get more careful every time it happens in the ecosystem.

Managed large health groups for a long time, we actually care about security, billion of patient interactions, never a compromise. I managed the modernization of the payment platform for the largest restaurant in the world. Billions of dollars a year. Early thing we did was freeze versions, maintain local package repos, carefully update. It is very concerning how rare these things are done. Tens of thousands of random people are in the core supply chain of most node projects and there seems to be a lot of carelessness of that fact.

When I run `npm audit`, it points me to a security advisory at GitHub. For example, for debug, it is https://github.com/advisories/GHSA-8mgj-vmr8-frr6 .

That page says that the affected versions are ">=0". Does that seem right? That page also says:

> Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Is this information accurate?

This attack could have been so, so much worse. We were saved by the attacker's lack of creativity and competence.

Definitely sounds like spear phishing targeting you specifically.

Kudos to you for owning up to it.

As others have said, it's the kind of thing that could happen to anyone, unfortunately.

Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem:

- Don't update dependencies unless necessary

- Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags

- Sign up for https://socket.dev and/or https://www.aikido.dev

- Work inside a VM

Scoket was all over this - https://socket.dev/blog/npm-author-qix-compromised-in-major-...

If you want to see what the phishing site (npmjs[.]help) looks like: https://urlscan.io/result/01992a3e-4f8c-72bb-90a9-c13826f2d8... - Was still up and running 2 hours ago.

I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a malefactor can easily make changes to code before publishing.

Did someone wrote a script to check if the attacker wallets really did get any transactions? I checked a few bitcoin portfolios balance manually but nothing in there but the first ETH portfolio had a few cents. I would be curious about the total financial impact so far

It looks like a lot of packages of the author have been compromised (in total over 1 billion downloads). I've updated the title an added information to the blog post.

A super quick script to check the deps in your package-lock.json file is here[0].

[0]: https://gist.github.com/martypitt/0d50c350aa7f0fc73354754343...

Completely understand people getting phished.

How long before npm mandates using phishing resistant mfa? At least for accounts that can publish packages with this may downloads.

I'm curious if anyone is tracking transactions against the wallet addresses in the malicious code - I assume that is essentially the attackers' return on investment here.

Ugh, I almost had my github compromised two years ago with a phishing email from circleci dot net. Almost. The github login page still under that domain made me stop in my tracks.

"B-b-but passkeys are inconvenient"

I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array.

I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.

Another great example of why things like dependabot or renovate for automatically bumping dependencies to the latest versions is not a good idea. If it's not a critical update, better to let the world be your guinea pig and only update after there's been a while of real world usage and analysis. If it is a critical enough update that you have to update right away, then you take the time to manually research what's in the package, what changed, and why it is being updated.

I'll come back to this thread when someone asks me why I hate JavaScr*pt yet again. this will be one of a thousand links.

I'm really surprised that NPM does not have better means to detect and respond to events like this. Since all the affected packages were by the same author, it would seem straightforward to have a mitigation event that rolls back all recent changes to some recent milestone. Then it's just a question of knowing when to hit the button.

I maintain a package on npm with >1M weekly downloads. I also got the same phishing e-mail, although I didn't click it.. here are the e-mail headers in the phishing e-mail I got:

Return-Path: <ndr-6be2b1e0-8c4b-11f0-0040-f184d6629049@mt86.npmjs.help> X-Original-To: martin@minimum.se Delivered-To: martin@minimum.se Received: from mail-storage-03.fbg1.glesys.net (unknown [10.1.8.3]) by mail-storage-04.fbg1.glesys.net (Postfix) with ESMTPS id 596B855C0082 for <martin@minimum.se>; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) Received: from mail-halon-02.fbg1.glesys.net (37-152-59-100.static.glesys.net [37.152.59.100]) by mail-storage-03.fbg1.glesys.net (Postfix) with ESMTPS id 493F2209A568 for <martin@minimum.se>; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) X-SA-Rules: DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROM_FMBLA_NEWDOM,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MIME_HTML_ONLY,SPF_HELO_NONE,SPF_PASS X-RPD-Score: 0 X-SA-Score: 1.1 X-Halon-ID: e9093e1f-8c6e-11f0-b535-1932b48ae8a8 Received: from smtp-83-4.mailtrap.live (smtp-83-4.mailtrap.live [45.158.83.4]) by mail-halon-02.fbg1.glesys.net (Halon) with ESMTPS id e9093e1f-8c6e-11f0-b535-1932b48ae8a8; Mon, 08 Sep 2025 06:47:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=smtp.mailtrap.live; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=Dc1BbAc9maHeyNKed/X7iAPabcuvlgAUP6xm5te6kkvGIJlame8Ti+ErH8yhFuRy/xhvQTSj8ETtV f3AElmzHDWcU3HoD/oiagTH9JbacmElSvwtCylHLriVeYbgwhZVzTm4rY7hw/TVqNE5xIZqWWCMrVG wi+k9uY+FUIQAh7Ta2WiPk/A4TPh04h3PzA50zathvYcIsPC0iSf7BBE+IIjdLXzDzNZwRmjgv2ZHW GAx/FRCPFgg0PbVvhJw98vSHnKmjPO/mmcotKFG+MUWkCtTu28Mm46t7MI7z5PrdCXZDA7L1nVnIwE ffIf0zED32Z6tFSJFNmYgFZlD6g+DnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=npmjs.help; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=DyWvxSOjMf7WfCVtmch+zw63kZ/OOBjcWnh1kIYs/hozgemb9mBIQCMqAdb4vSZChoW5uReVH5+k5 Jaz7UodbPJksVkYWqJOVg6nyx5EaYMYdgcw1+BCct/Sf2ceFwWurhupa6y3FBTFWBYLhcsAXERlx2l IuxWlpZoMDEBqDxjs8yvx/rkBrcd/2SNTcI+ooKJkrBIGBKuELOd3A5C6jlup6JNA4bE7vzP3FUfKw y0357UMnn45zWHm9HvudO4269FRlNjpiJaW7XF1/ANVrnDlNWfUGNQ5yxLZqmQDTtxFI7HcOrF3bTQ O/nrmVOvN9ywMvk/cJU4qGHqD9lT32A== CFBL-Address: fbl@smtp.mailtrap.live; report=arf X-Report-Abuse-To: abuse@mailtrap.io Received: from npmjs.help by smtp.mailtrap.live with ESMTPSA 6aee9fff-8c4b-11f0-87bb-0e939677d2a1; Mon, Sep 08 2025 00:33:20 GMT Feedback-ID: ss:770486:transactional:mailtrap.io Message-ID: <6be2b1e0-8c4b-11f0-0040-f184d6629049@npmjs.help> X-Mt-Data: bAX0GlwcNW6Dl_Qnkf3OnU.GLCSjw_4H01v67cuDIh2Jkf52mzsVFT_ZEVEe0W6Lf3qzW2LP_TCy93I46MCsoT0pB9HozQkvCw22ORSCt3JBma1G3v9aDEypT1DLmyqlb6hYLF3H7tJCgcxTU5pbijyNaOFtoUMdiTA6jxaONeZbBj.SKUa5CLT5TMpeNHG6oGIiY_jqlU.nQkxGPY3v9E34.Nz4ga8p9Pd_BplftaE~--2CLrluJMY65S5xFl--IISg0olYJu6DVyVDEcJ.AQ~~ MIME-Version: 1.0 Date: Mon, 08 Sep 2025 00:33:20 +0000 Subject: Two-Factor Authentication Update Required To: "molsson" <martin@minimum.se> From: "npm" <support@npmjs.help> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable