Posted by universesquid 9/8/2025
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.
If someone hijacked your DNS, they could direct your browser to connect to their web server instead which served a phishing site on port 80 and never redirected you, thus never ran into the certificate issue. That's part of the reason why browsers started warning users when they're connecting to a website without HTTPS.
- make sure you're connected to the expected official domain (though many companies are desensitizing us to this threat by using distinct domains instead of subdomains for official business)
- make sure you're connected over HTTPS (this was most likely their issue)
- use a password manager which remembers official domains for you and won't offer to auto-fill on phishing sites
- use a 2FA method that's immune to phishing, like passkeys or security keys (if you do this, you get a lot of leniency to mistakes everywhere else)
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...
Mempool.space - no Blockchair - no Tronscan - no Blockcypher.com - no Blockread.io - no
As for developers trusting a plugin that reaches out to an external location to determine the reputation of every website they visit seems like a harder sell though.
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.
So I guess a lot more accounts/packages might be affected than the ones stated in the article
Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.
Oh my word please no! Every time I run into an issue where a dependency suddenly isn’t logging colors like it’s supposed to, it always boils down to chalk trying to do something fancy to handle an edge case that doesn’t actually exist. Just log the dang colors!
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?
1. The version matching was wrong (now fixed).
2. The warning message is (still) exaggerated, imo, though I understand why they’d pass the liability downstream by doing so.
>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.
It sounds like the package then somehow executes and invites other software onto the machine. If something else has executed then anything the executing user has access to is now compromised.
This incident would be much more severe if the code would actually steal envs etc. because a lot of packages have dependency on debug as wildcard.
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.
I generally recommend Google's to any Android users, since it suggests your saved password not only based on domain in Chrome browser, but also based on registered appID for native apps, to extend your point. I'm not sure if third party password managers do this, although perhaps it's possible for anti-monopoly reasons?
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.
Luckily some of them actually import the packages to a local distribution point and check them first.
- 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
And get yourself drowning in insurmountable technical debt in about two months.
JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.
It so recommend to stay on top of the dependencies and for different stacks this means different update schedule. For some, daily is indeed a good choice.
Upgrading after a month will take some serious time.
Somehow we've survived without updating dependencies for probably at least a year.
Other than that you now probably have an insurmountable technical debt and upgrading the dependencies is a project of itself.
All the above applies to JavaScript world, of course. It's much different for the rest.
We continuously monitor our dependencies for CVEs and update them if necessary. Most of the time the CVEs that are reported are not relevant / worth updating for.
content-security-policy: default-src 'self';
The reason it doesn't help in this instance is because the attack targets the generated bundle and runs on client devices, whereas other attacks will target developer machines themselves (and possibly also client devices). Those types of attacks can be mitigated by using Deno.