Posted by universesquid 9/8/2025
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.
https://socket.dev/blog/npm-author-qix-compromised-in-major-...
While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.
In this incident, we detected the packages quickly, reported them, and they were taken down shortly after. Given how high profile the attack was we also published an analysis soon after, as did others in the ecosystem.
We try to be transparent with how Socket work. We've published the details of our systems in several papers, and I've also given a few talks on how our malware scanner works at various conferences:
You can't catch everything with normal static analysis either. LLM just produces some additional signal in this case, false negatives can be tolerated.
There are cases an LLM may be able to catch that their static analysis can't currently catch. Should they just completely ignore those scenarios, thereby doing the worst thing by their customers, just to stay purist?
What is the worst case scenario that you're envisioning from an LLM hallucinating in this use case? To me the worst case is that it might incorrectly flag a package as malicious, which given they do a human review anyway isn't the end of the world. On the flip side, you've got LLM catching cases not yet recognised by static analysis, that can then be accounted for in the future.
If they were just using an LLM, I might share similar concerns, but they're not.
when static analysis does it, it's called a "misclassification"
“Chat, I have reading comprehension problems. How do I fix it?”
Very insightful.
Does the AI detect the obfuscation?
Thanks for the links in your other comment, I'll take a look!
It seems strange to attack a service like this right after it actively helped keep people safe from malware. I'm sure its not perfect, but it sounds like they deserve to take a victory lap.
Seems good to me. I want more attention and more tooling around this problem. You seem mad at them for helping solve a real problem?
Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge hierarchal trees of code is absolutely fucking crazy, rather than a blatant attempt to make money off an ongoing problem without actually solving anything.
You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptostealers in their web apps.
And regarding not copying massive trees of untrusted dependencies: I am actually all for this! It's better to have fewer dependencies, but this is also not how software works today. Given the imperfect world we have, I think it's better to at least try to do something to detect and block malware than just complain about npm.
So just because a lock isn't 100% effective at keeping out criminals we shouldn't lock our doors?
That’s like lock companies parading around when their neighbour is murdered during a burglary but they weren’t because they bought a Foobar(tm) lock.
Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong.
Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available.
I have never been phished because I follow best practices. Most people don’t.
In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort.
Thank you for your input :)
But instead, we're left with this mess where ordinary developers are forced to deal with the consequences of getting phished.
Also, Yubikeys work on phones just fine, via both NFC and USB.
Just set up a new passkey on the mobile device.
Password managers can’t help you if you don’t use them properly.
Spotify steals (and presumably uploads) your clipboard, as well as other apps. Autofill is your primary defense against phishing, as you (and hopefully some others) learned this week.
It is possible to restrict clipboard access when running applications inside Firejail, i.e. Firejail allows you to restrict access to X11 and Wayland sockets, which prevents the sandboxed application from reading or writing to the system clipboard. See: "--x11=none", "--private=...", "--private-tmp", and so forth. You can run a GUI app with isolated clipboard via "firejail --x11=xvfb app".
For Wayland, you should block access to the Wayland socket by adding "--blacklist=/run/user/*/wayland-*".
I do not use autofill on desktop at all. I use it on Android, however.
The autofill feature is not 100% reliable for various reasons:
(1) some companies use different domains that are legitimate but don't exactly match the url in the password manager. Troy Hunt, the security expert who runs https://haveibeenpwned.com/ got tricked because he knew autofill is often blank because of legit different domains[1]. His sophisticated knowledge and heuristics of how autofill is implemented -- actually worked against him.
(2) autofill doesn't work because of technical bugs in the plugin, HTML elements detection, interaction/incompatibility with new browser versions, etc. It's a common complaint with all password plugins:
https://www.google.com/search?q=1password+autofill+doesn%27t...
https://www.1password.community/discussions/1password/1passw...
https://github.com/bitwarden/clients/issues?q=is%3Aissue%20a...
... so in the meantime while the autofill is broken, people have to manually copy-paste the password!
The real-world experience of flaky and glitchy autofill distorts the mental decision tree.
Instead of, "hey, the password manager didn't autofill my username/password?!? What's going on--OH SHIT--I'm being phished!" ... it becomes "it didn't autofill in the password (again) so I assume the Rube-Goldberg contraption of pw manager browser plugin + browser version is broken again."
Consider the irony of how password managers not being perfectly reliable causes sophisticated technical minds to become susceptible to social engineering.
In other words, password managers inadvertently create a "Normalization of Deviance" : https://en.wikipedia.org/wiki/Normalization_of_deviance
[1] >Thirdly, the thing that should have saved my bacon was the credentials not auto-filling from 1Password, so why didn't I stop there? Because that's not unusual. There are so many services where you've registered on one domain (and that address is stored in 1Password), then you legitimately log on to a different domain. -- from: https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mail...
The number of cases in this thread, about a malware attack basically because of 1Password, where people mention their bad experience with 1Password is really stretching the "no such thing as bad publicity" theory
Well, until now.
They screwed up, but we have thousands of years of evidence that people make mistakes even when they really know better and the best way to prevent that is to remove places where a single person making a mistake causes a disaster.
On that note, how many of the organizations at risk do you think have contributed a single dollar or developer-hour supporting the projects they trust? Maybe that’s where we should start looking for changes.
One side note: most systems make it hard to completely rely on WebAuthn. As long as other options are available, you are likely vulnerable to an attack. It’s often easier than it should be to get a vendor to reset MFA, even for security companies.
It was a generic Phish email you were in every single Corp 101 security course
My main point was simply that the better response isn’t to mock them but to build systems which can’t fail this badly. WebAuthn is great, but you have to go all in if you want to prevent phishing. NPM would also benefit immensely from putting speed bumps and things like code signing requirements in place, but that’s a big usability hit if it’s not carefully implemented.
Ive literally never for a support email or any email from a .help domain.
I'm not mocking them, just trying to understand how so many red flags slipped past.
Domain name No auto-fill Unannounced MFA resets Etc...
My point is that nothing could have saved this person except extreme security measures. There's literally no conclusion here besides:
1. Lock everything down so extremely that it's extremely inconvenient to prevent mistakes 99% of people don't make. (How many npm packages vs the total have been hijacked, less than 1%)
2. This person was always going to be a victim eventually... And that's a hard pill to swallow. For me and the maintainer. Being in network security it's my actual nightmare scenario.
The only lesson to be learned is you need extreme security measures for even the most experienced of internet users. This wasn't your grandma clicking a link, it's a guy who's been around for decades in the online / coding world.
It also makes me suspicious but that's a road I'd rather keep myself
A password manager can’t manage passwords if you don’t configure it and use it.
You forgot to mention that you are both highly skilled and practiced at phishing yourself... don't you think that helps too?
(Microsoft owns GitHub, which owns NPM.)
But google comes with its own privacy nightmares.
Also, junon.support++ – big thanks for being clear about all this.
If you change your key you can't use it for like 12 hours or something?
They can't pwn what they can't find online.
So if the hacker did an npm publish from local it would show up.
With nodejs packages, I can open up node_modules and read the code. But packages get a chance to run arbitrary code on your computer after installation. By the time you can read the source code, it may be too late.
If there's any ideas on what I should be doing, I'm all ears.
EDIT: I've heard back, they said they're aware and are on it, but no further details.
Github is SOC2 compliant, but that of course means nothing really.
It took them quite a long time to do so.
Please take care and see this as things that happen and not your own personal failure.
I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA:
TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough.
I don't understand how most of the anti-phishing advice focuses on that, it's useless to borderline counter-productive.
What really helps against phishing :
1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try.
2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not.
That is all there is. Any other method, any other "indicator" helps but is error-prone, which means someone somewhere will get phished eventually. Particularly if stressed, tired, or in a hurry. It just happened to be you this time.
Good luck and well done again on the response!
Login using one off email links (instead of username + password) is increasingly common which means its the only option.
1. You just requested it, I'm not saying to never click link on transactional emails you requested. You still need to click on those verify email links
2. It replaces entering your password, so you're not entering your password on a link from an email, which is the very wrong thing.
Not promoting the pattern, I also find it worrying the majority of internet users have no basic understanding of authentication and the risk for their digital identity.
If you use username instead of email address attackers have to guess that too.
One quite serious problem I see quite often is using email plus password for login, and notifying on failed login that the email is not in the system, letting attackers validate which emails are logins.
And this is exactly the kind of phishing attack that is most effective, as this particular incident shows. So I'd say it's actually a worse phishing vector than magic links.
Have the TOTP in the same/another password manager (after considering the tradeoffs) and that can also not be entered unless the domain is right :)
Passkeys seem like the best solution here where you physically can not fall for a phishing attack.
This is how Troy Hunt got phished. He was already very tired after a long flight, but his internal alarm bells didn't ring loud enough, when the password manager didn't fill in the credentials. He was already used to autofill not always working.
I dunno, it mostly seems to not work when companies change their field names/IDs, or just 3rd party authentication, then you need to manually add domains. Otherwise my password manager (1Password) works everywhere where I have an account, except my previous bank which was stuck in the 90s and disallowed pasting the passwords. If you find that your password manager doesn't work with most websites (since it's "extremely common") you might want to look into a different one, even Firefox+Linux combo works extremely well with 1Password. Not affiliated, just a happy years+ user.
> Passkeys seem like the best solution here where you physically can not fall for a phishing attack.
Yeah, I've looked into Passkeys but without any migration strategy or import/export support (WIP last time I looked into it), it's not really an alternative just yet, at least for me personally. I have to be 100% sure I can move things when the time ultimately comes for that.
> without any migration strategy or import/export support
Since you're already a 1Password user, I wanted to draw your attention to the "Show debugging tools" in the "Settings > Advanced" section. From that point, you can say "Copy Item JSON" and it will give you the details you would want for rescuing the Passkey. Importing it into something else is its own journey that I can't help with
{
"overview": {
"passkey": {
"credentialId": "...",
"rpId": "example.com",
"userHandle": "..."
},
...
"details": {
"passkey": {
"type": "webauthn",
"createdAt": 175.......,
"privateKey": "eyJ...",
"userHandle": "..."
}
For now, when companies let me have multiple passkeys, that's sufficient for me. I put one on my Apple Keychain and one in 1Password.
You only need read the whole thread however to see reasons why this would sometimes not be enough: sometimes the password manager does not auto-fill, so the user can think it's one of those cases, or they're on mobile and they don't have the extension there, or...
As a matter of fact, he does use one, that didn't save him, see: https://news.ycombinator.com/item?id=45175125
So pick one that does? That's like its top 2 feature
> he does use one
He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch
Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature.
WebAuthn prevents phishing. Password managers reduce it. This is the difference between being bulletproof like Superman or a guy in a vest.
That's why WebAuthn doesn't allow that as a core protocol feature, preventing both this attack and shifting the cost of unnecessary origin changes back to the company hosting the site. Attacking this guy for making a mistake in a moment of distraction is like prosecuting a soldier who was looking the other way when someone snuck past: wise leaders know that human error happens and structure the system to be robust against a single mistake.
As a developer I also love their ssh and gpg integrations, very handy.
I do get it for free from work, but if I had to choose one myself I'd have to pay for I'd probably still pick 1Passwrod.
I wanted to highlight that "getting it for free from work" isn't a sweetheart deal offered just to OP, but a feature of 1Password for Teams, meaning all employees of a business that uses 1Password automatically have a Family license for use at home https://support.1password.com/link-family/
And, for clarity, it's merely a financial relationship: the business cannot manage your Family account, cannot see its contents, and if you have a separation event you can retain the Family account forever in a read only capacity or you can take over the payment (or, heh, I presume move to another employer that also uses 1Password) and nothing changes for your home passwords
> I was mobile, the autofill stuff isn't installed
Folks from multi-billion dollar companies with multimillion dollar packages should learn a few things from this response.
> The author appears to have deleted most of the compromised package before losing access to his account. At the time of writing, the package simple-swizzle is still compromised.
Is this quote from TFA incorrect, since npm hasn’t yanked anything yet?
npm does appear to have yanked a few, slowly, but I still don't have any insight as to what they're doing exactly.
I’m extremely security conscious and that phishing email could have easily gotten me. All it takes is one slip up. Tired, stressed, distracted. Bokm, compromised
Great of you to own up to it.
Screenshot here: https://imgur.com/a/q8s235k
Urgency is poison.
Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard.
I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in good faith" should be shamed for doing it.
Actual alerts: just notify. Take immediate, preventive, but non-destructive action, and help the user figure out how to right it - on their own terms.
and use what? instant message? few things lack legitimacy more than an instant message asking you to do something.
Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive.
the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.
If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index.
> You ARE reviewing them, right?
Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake.
While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.
No. The problem is unsigned package repositories.
The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.
I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.
That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.
I am with PGP but more wary of self-signed certs, though even self-signed certs allow mass revocation of packages when an author's cert is compromised.
1. It's an extra step: before you pwn the package, you need to pwn a domain.
2. When a domain is pwned, the packages it signs can be revoked with a single command.
You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply.
> You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor.
1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway.
2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable.
As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before.
It's a total clown show.
It should be a PGP or SSH key, absolutely not an X509 certificate (unless you allow self signed).
Personal identity keys should be fully autonomous and not contingent on the formal recognition of any external authority.
They didn't need me; plenty of repositories doing signed packages existed well before npm was created.
Which is why I likened them to a bunch of kids - they didn't look around at how the existing repos were designed, they just did the first thing that popped into their head.
Identity on the Internet is a lie. Nobody knows you're a dog.
The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.
What do you think HTTPS is?
Received: from npmjs.help by smtp.mailtrap.liveI'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.
For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?
FWIW npmjs does support FIDO2 including hard tokens like Yubikey.
They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.
I'm surprised by this. Yeah, GitHub definitely forces you to re-auth when accessing certain settings.
that message feels like it could work as a first-time as well
Regardless of whether the real NPM had done this in the past, decades of dumb password expiration policies have trained us that requests like this are to be expected rather than suspected.
0x10ed43c718714eb63d5aa57b78b54704e256024e
0x13f4ea83d0bd40e75c8222255bc855a974568dd4
0x1111111254eeb25477b68fb85ed929f73a960582
0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f
Source: https://github.com/chalk/chalk/issues/656#issuecomment-32670...
> Those are swap contract addresses, not attacker addresses. E.g. 0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af the Uniswap v4 universal router addr.
> Every indication so far is that the attacker stole $0 from all of this. Which is a best-case outcome.
My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said, "nope, we really, intentionally, did this"
Companies intentionally withhold warning emails as late as possible to cause more people to incur late fees. So everyone is used to "shit, gotta do this now or get screwed"
You can't hope to have good security when everyone's money is controlled by organizations that actively train people to have bad OPSEC or risk missing rent.
Completely agree. The only reliable way is to never use an email/SMS link to login, ever.
I used the word "often" rather than "always" for this reason.
dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0rDo we just run:
npm list -g #for global installs
npm list #for local installs
And check if any packages appear that are on the above list?
Thanks!
Does anyone know how this attack works? Is it a CSRF against npmjs.com?
It wasn't a single-click attack, sorry for the confusion. I logged into their fake site with a TOTP code.
Sorry for what you're going through.
You login with your credentials, the attacker logins to the real site.
You get an SMS with a one time code from the real site and input it to the fake site.
The attacker takes the code andc finishes the login to the real site.
I actually got hit by something that sounds very similar back in July. I was saved by my DNS settings where "npNjs dot com" wound up on a blocklist. I might be paranoid, but it felt targeted and was of a higher level of believability than I'd seen before.
I also more recently received another email asking for an academic interview about "understanding why popular packages wouldn't have been published in a while" that felt like elicitation or an attempt to get publishing access.
Sadly both of the original emails are now deleted so I don't have the exact details anymore, but stay safe out there everyone.
phishing is too easy. so easy that I don't think the completely unchecked growth of ecosystems like NPM can continue. metastasis is not healthy. there are too many maintainers writing too many packages that too many others rely on.
thanks for your efforts!
Don't do security things when you're not fully awake, too. Lesson learned.
The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things coming from well-intentioned sites before. Since npm has historically been in contact about new security enhancements, this didn't smell particularly unbelievable to my nose.
The email went to the npm-specific inbox, which is another way I can verify them. That address can be queried publicly but I don't generally count on spammers to find that one but instead look at git addresses etc
The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake.
The actual in-email link matched what I'd expect on npm's actual site, too.
I'm still trying to work out exactly how they got access. They didn't technically get a real 2FA code from the actual, I don't believe. EDIT: Yeah they did, nevermind. Was a TOTP proxy attack, or whatever you'd call it.
Will post a post-mortem when everything is said and done.
Authentications are separated and if some signature must be placed or money to be sent, you must use other access code and the app shows the intention of what are you authorizing. If it is money being sent, you see where and how much you want to sent before you approve this request on the app.
But the app is all tied to digital identity from the id card in the first place - to set up these strong authentication guarantees in the first place you use your ID card. Some time ago we had to use computer with smartcard reader to set it up, nowdays I dunno whether it is NFC or something, but the mobile phone can read the ID card.
It's nothing short of amazing that nobody worked on this. It's not as if there isn't a need. Everyone with high security requirements (defense, banks etc.) already do this, but this clumsy plugins and (semi-)proprietary software. Instead we get the nth iteration of settings redesigns.
That's exactly what I mean! Who would use it if the UI/UX is terrible? Many Gemini (protocol) browsers like Lagrange have such pleasant UIs for it, though somewhat minimal. With sufficient push, you could have used mutual TLS from even hardware tokens.
Once heard of a user putting in a helpdesk ticket asking why they had to pay for the TOTP app. Then I realize their TOTP seed is probably out in the open now.
I’m sure we can imagine how else this could go badly…
The extension from https://authenticator.cc, with smart domain match enabled, would have caught this by showing all other TOTP codes besides the one intended by NPM.
On a Mac, Keychain would also have caught this by not autofilling: https://support.apple.com/en-ph/guide/passwords/mchl873a6e72...
They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.
I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned
The `.help` should have been the biggest red flag, followed by the 48-hours request timeline. I wasn't thinking about things like I normally would this morning and just wanted to get things done today. Been a particularly stressful week, not that it's any excuse.
That's how they get you.
If you maintain popular open source packages for the love of God get yourself a couple of security keys.
It's a good thing the WebPKI cartel mostly did away with EV certs.... these days any old cert where only the SAN matches the domain and your browser gives a warm fuzzy "you're secure!"
By contrast, OV certs, which were originally supposed a very similar level of assurance, were did away with by CAs themselves, by cost-optimizing the verification requirements into virtual nonexistence.
That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example (something an Internet-wide system mostly can guarantee) and it being wise to transact there (something extensive experience shows it can’t and shouldn’t try to). And if you’re a domain owner, your domain is your identity; pick one and stick to it. Stackoverflow.blog is stupid, don’t be like stackoverflow.blog.
[1] https://www.troyhunt.com/extended-validation-certificates-ar...
[2] https://arstechnica.com/information-technology/2017/12/nope-...
That's because the browser implementers gave up on trying to solve the identity problem. It's too difficult they said, we'd rather push other things.
Google implemented certificate pinning in Chrome for themselves and a few friends, said fuck everyone else, and declared the problem solved. Who cares about everyone else when your own properties are protected and you control the browser?
Meanwhile the average user has no idea what a certificate does, whether it does or doesn't prove identity.
No wonder they removed the lock icon from the browser.
Can't really tell you what not to do, but if you're not already using a password manager so you can easily avoid phishing scams, I really recommend you to look into starting doing so.
In the case of this attack, if you had a password manager and ended up on a domain that looks like the real one, but isn't, you'd notice something is amiss when your password manager cannot find any existing passwords for the current website, and then you'd take a really close look at the domain to confirm before moving forward.
That being said, if you’re making login pages: please, for the love of god, test them with multiple password managers. Oh, and make sure they also work correctly with the browser’s autotranslation. Don’t rely on the label to make form submission decisions ... please.
I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :)
> That being said, if you’re making login pages
I think we're doomed on this front already. My previous bank still (in 2025!) only allows 6 numbers as the online portal login password, no letters or special characters allowed, and you cannot paste in the field so no password manager works with their login fields, the future is great :)
This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.
What is your mythical "good password manager"?
In those cases, I carefully review the new domain, make sure it belongs to the right owner, then add it to the list of domains to accept. Now the account list properly show up in the future too, until they again change it. But it gives me a moment to pause and reflect before just moving past it.
I cannot remember any times in the last years where 1Password was 100% unable to fill out the username/password for a website unless the website itself prevented pasting passwords (like my old bank).
But even if it fills the wrong fields, it still provides safety as you wouldn't even see the accounts in the list if you're on the wrong domain, so that's your first warning sign.
want to stress everyone it can happen to. no one has perfect opsec or tradecraft as a 1 man show. its simply not possible. only luck gets one through and that often enough runs out.
And because it could happen to anyone that we should be doing a better job using AI models for defense. If ordinary people reading a link target URL can see it as suspicious, a model probably can too. We should be plumbing all our emails through privacy-preserving models to detect things like this. The old family of vulnerability scanners isn't working.
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!
> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3
As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx
And with that, packages usually shouldn't be getting updated in your CI pipeline.
Am I mistaken on how npm(/yarn/pnpm) lockfiles work?
In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
That's because they are being "replaced", in a sense!
When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes.
Hence the childish attitude and behaviour with everything to do with JavaScript.
And so, it seems, is everything else. Perhaps, this commentary adds no value — just old man yells at cloud stuff.
Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?
The lockfile includes a hash of the tarball, doesn't it?
Thank you!
The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.
The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically.
That’s how I understand it / that’s my current knowledge. Maybe there is someone here who can confirm/deny that. That would be great!
That way it's much harder to make one hash look like another.
That's a lot of flexibility within which to do clever color math which accounts for the types of colorblindness according to their prevalence.
Simple. Instead of forcing colour, one could retain a no colour option maybe?
Done. Solved.
Everything should have this option. I personally have no colour vision issues, other than I find colour annoying in any output. There's a lot who prefer this too.
If you're the sort of person who would think about adjusting it to suit your sensitivity to this kind of attack, you're likely not the sort of person that the feature is trying to protect anyhow.
One will not be surprised to see that Chalk chooses its own path via the stunningly opaque FORCE_COLOR=0 and is all :fu: to people who suggest otherwise <https://github.com/chalk/chalk/issues/547#issuecomment-11268...> One will especially enjoy the "get bent" response because I discovered that one issue by, you know, searching the issues <https://github.com/chalk/chalk/issues?q=is%3Aissue%20NO_COLO...>
This is smart, but not really unusual.
"we kindly ask that you complete this update your earliest convenience".
The email was included here: https://cdn.prod.website-files.com/642adcaf364024654c71df23/...
From this article: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...
Such a Two Factor Authentication update request would have needed a blog post first, to announce such a fishy request.
I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same.
To be honest, this whole post has the ring of AI writing, not careful analysis.
No it doesn't?
It has been what, hours? since the discovery? Are you expecting them to spend time analysing it instead of announcing it?
Also, nearly everyone has AI editing content these days. It doesn’t mean it wasn’t written by a human.
I want no part of AI in any form of my communication, and I know many which espouse the same.
I will certainly agree on "many", but not "nearly everyone".
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.
Sadly, programming language package managers have normalized the idea that everyone who uses the package manager should be exposed to every random package and release from random strangers with no moderation. This would be unthinkable for a Linux distribution. (You can of course add 3rd-party Linux package repositories, unstable release branches, etc, which should enforce the same type of rules, but they don't have to)
Linux distros are still vulnerable to supply chain attacks though. It's very rare but it has happened. So regardless of the release process, you need all the other mitigations to secure the supply chain. And once they're set up it's all pretty automatic and easy (I use them all day at work).
This will probably be reigned in soon. Many companies I know are backing away from npm/node, and even composer. It's just too risky an ecosystem.
These can exclude a lot of common systems and software, including automations. If your heuristic is quite naive like "is using Linux" or "is using Firefox" or "has an IP not in the US" you run into huge issues. These sound stupid, because they are, but they're actually pretty common across a lot of software.
Similar thing with 2FA. Sms isn't very secure, email primes you to phishing, TOTP is good... but it needs to be open standard otherwise we're just doing the "exclude users" thing again. TOTP is still phishable, though. Only hardware attestation isn't, but that's a huge red flag and I don't think NPM could do that.
The attacks are still possible, but they're not going to be nearly as easy here.
This attack would have 100% been thwarted, when a load of emails appeared saying "publish package you just uploaded?".
(if you read the dev's account of this, you'll see this would have worked)
If I could have a publish token / oidc Auth in CI that required an additional manual approve in the web UI before it was actually published I could imagine this working well.
It would help reduce risk from CI system breaches as well.
There are already "package published" notification emails, it's just at that point it's too late.
I don't disagree, but this sentence is doing a lot of heavy lifting. See also "draw the rest of the owl".
It's not that simple. You can implement the most stringent security measures, and ultimately a human error will compromise the system. A secure system doesn't exist because humans are the weakest link.
So while we can probably improve some of the processes within npm, phishing attacks like the ones used in this case will always be a vulnerability.
You're right that AI tools will make these attacks more common. That phishing email was indistinguishable from the real thing. But AI tools can also be used to scan and detect such sophisticated attacks. We can't expect to fight bad actors with superhuman tools at their disposal without using superhuman tools ourselves. Fighting fire with fire is the only reasonable strategy.
That was more than ten days ago, and yet major packages were compromised yesterday. How?
You’re right, this will only get a lot worse.
https://www.businessinsider.com/npm-ceo-bryan-bogensberger-r...
https://www.businessinsider.com/npm-cofounder-laurie-voss-re...
Why in the world would they NEED to stop? It apparently doesn't harm their "business"
What kind of crazy AI could possible have noticed that on the NPM side?
This is frustrating as someone that has built/published apps and extensions to other software providers for years and must wait days or weeks for a release to be approved while it's scanned and analyzed.
For all the security wares that MS and GitHub sell, NPM has seen practically no investment over the years (e.g. just go review the NPM security page... oh, wait, where?).
> Things were fine before they became mainstream
As in, things were fine before we had commonplace tooling to fetch third party software?
> package files that are set to grab the latest version
The three primary Node.js package managers all create a lockfile by default.
In some ways they were. I remember how much friction it was to take a dependency in your typical desktop C++ or Delphi app in late 90s - early 00s. And because of that, developers would generally be hesitant to add a new dependency without a strong justification, especially so any kind of dependency that comes with its own large dependency tree. Which, in turn, creates incentives for library authors to create fairly large, framework-style libraries. So you end up with an ecosystem where dependencies are much more coarse and there are fewer of them, so dependency graphs are shallow. Whether this is an advantage or a disadvantage in its own right can be debated, but it's definitely less susceptible to this kind of attack because updating dependencies in such a system is also much more involved; it's not something that you do with a single `npm install`.
> As in, things were fine before we had commonplace tooling to fetch third party software?
Yes. The languages without a dominant package manager (basically C and C++) are the only ones that have self-contained libraries, that you can just drag into your source tree.
This is how you write good libraries - as can be seen by the fact that for many problems, there's a powerful C (or C++, but usually C) library with minimal (and usually optional) dependencies, that is the de-facto standard, and has bindings for most other languages. Think SDL, ffmpeg, libcurl, zlib, libpng/jpeg, FreeType, OpenSSL, etc, etc.
That's not the case for libraries written in JS, Python, or even other compiled languages like Go and Rust - libraries written in those languages come with a dependency tree, and are never ported to other languages.
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...
-uu searches through ignored and hidden files (eg dotfiles)
-uuu searches through ignored, hidden, and binary files (ie everything)
For security checks, the first 2 out of 3 is just fine.
> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.
---
So there might be pull requests, but Brew's official stance is that they do not actively moderate casks for malware. I guess there's something built into the MacOS packaging step that help mitigate the risk, but I don't know much about it outside playing w/ app development in XCode.
That said, I think rg is pretty well known to linux daily-drivers and they just wanted to share something quickly for powerusers who want to check their workspaces quickly. Probably better to just instruct n00bs to use grep than install a whole cli tool for searching
Come to think of it, I wonder if a 2-phase attack could be planned by an attacker in the future: Inject malware into a package, flood guidance with instructions to install another popular tool that you also recently compromised... lol
It takes like 2 years to get up to date packages. This isn't NPM.
https://www.redhat.com/en/blog/understanding-red-hats-respon...
https://lists.debian.org/debian-security-announce/2024/msg00...
Like ... npm?
Everybody knows npm is a gaping security issue waiting to happen. Repeatedly.
It’s convenient, so it’s popular.
Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.
npm sold it really hard that you could rely on them and not have to vendor dependencies yourself. If I suggested that a decade ago in Seattle, I would have gotten booed out of the room.
Yet here we are. And this is going to get massively worse, not better.
I mean, I believe you, but the person you are replying to obviously believes that they are similar. Could you explain the significant differences?
> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.
(I get that the same can be said for said for npm and the packages in question, but I don’t really see how the context of the thread matters in this case).
npm cache clean --force pnpm cache delete
`Get-ChildItem -Recurse | Select-String -Pattern '_0x112fa8' | ForEach-Object { $_.Line.Substring(0, [Math]::Min(80, $_.Line.Length)) }`
Breakdown of the Command:
- Get-ChildItem -Recurse: This command retrieves all files in the current directory and its subdirectories.
- Select-String -Pattern '_0x112fa8': This searches for the specified pattern in the files.
- ForEach-Object { ... }: This processes each match found.
- Substring(0, [Math]::Min(80, $_.Line.Length)): This limits the output to a maximum of 80 characters per line.
---
Hopefully this should work for Windows devs out there. If not, reply and I'll try to modify it.
If you have crypto wallets on the potentially compromised machine, or intend to transfer crypto via some web client, proceed with caution.
https://gist.github.com/edgarpavlovsky/695b896445c19b6f66f14...
Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.
XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections.
Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:
For xz an advanced persistent threat, inserted hypertargeted self modifying code into a tarball.
A single npm dev was "hacked" (phished) by a moderate effort, (presumably drive by) crypto thief.
I have no idea what you meant by "right inside _ssh_" but I don't think that's a good description of what actually happened in any possible case.
I'm unlikely to defend C devel practices but this doesn't feel like an indictment of C, if anything the NPM ecosystem looks worse by this comparison. Especially considering the comment you replied to was advocating for minimizing dependencies, which if the distros effected by xz being compromised had followed, (instead of patching sshd) they wouldn't have shipped a compromised version.
Most times they actually are a normal .c/.h combo, but the implementation was moved to the "header" file and is simply only exposed by defining some macro. When it is actually a like a single file, that can be included multiple times, there is still code in it, so it is only a header file in name.
What is the big deal in actually using the convention like it is intended to and name the file containing the code *.c ? If is intended to only be included this can be still done.
> avoiding the C standard library are regressive and obsolete
I don't understand this as well, since the one half of libc are syscall wrappers and the other half are primitives which the compiler will use to replace your hand-rolled versions anyway. But this is not harming anyone and picking a good "core" library will probably make your code more consistent and readable.
And generally it's one less file to look at, more easy to copy-paste into your project (and as a very minor security benefit you'll potentially look at arbitrary subsets of the contents every time you do a go-to-definition or use the header as docs (thus having chances to notice oddities) instead of just looking at a header).
But maybe I'm misunderstanding the feature
That sounds great in theory. In practice, NPM is very, very buggy, and some of those bugs impact pulling deps from git repos. See my issue here: https://github.com/npm/cli/issues/8440
Here's the history behind that:
Projects with build steps were silently broken as late as 2020: https://github.com/npm/cli/issues/1865
Somehow no one thought to test this until 2020, and the entire NPM user base either didn't use the feature, or couldn't be arsed to raise the issue until 2020.
The problem gets kinda sorta fixed in late 2020: https://github.com/npm/pacote/issues/53
I say kinda sorta fixed, because somehow they only fixed (part of) the problem when installing package from git non-globally -- `npm install -g whatever` is still completely broken. Again, somehow no one thought to test this, I guess. The issue I opened, which I mentioned at the very beginning of this comment, addresses this bug.
Now, I say "part of of the problem" was fixed because the npm docs blatantly lie to you about how prepack scripts work, which requires a workaround (which, again, only helps when not installing globally -- that's still completely broken); from https://docs.npmjs.com/cli/v8/using-npm/scripts:
prepack
- Runs BEFORE a tarball is packed (on "npm pack", "npm publish", and when installing a git dependencies).
Speaking of TypeScript, the TypeScript compiler developers ran into this very problem, and have adopted this workaround, which is to invoke a script from the npm prepare script, which in turn does some janky checks to guess if the execution is occuring from a source tree fetched from git, and if so, then it explicitly invokes the prepack script, which then kicks off compiler and such. This is the workaround they use today:
https://github.com/cspotcode/workaround-broken-npm-prepack-b...
... and while I'm mentioning bugs, even that has a nasty bug: https://github.com/cspotcode/workaround-broken-npm-prepack-b...
Yes, if the workaround calls `npm run prepack` and the prepack script fails for some reason (e.g. a compiler error), the exit code is not propagated, so `npm install` will silently install the respective git dependency in a broken state.
How no one looks at this and comes to the conclusion that NPM is in need of better stewardship, or ought to be entirely supplanted by a competing package manager, I dunno.
[1] https://www.debian.org/doc/manuals/securing-debian-manual/de...
So if we're discussing anything here, why not what this reason is, instead of everyone praising their favourite package registry?
https://github.com/npm/npm/pull/4016#issuecomment-76316744
https://news.ycombinator.com/item?id=38645969
https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...
Good.
export default function ansiRegex({onlyFirst = false} = {}) {
// Valid string terminator sequences are BEL, ESC\, and 0x9c
const ST = '(?:\\u0007|\\u001B\\u005C|\\u009C)';
// OSC sequences only: ESC ] ... ST (non-greedy until the first ST)
const osc = `(?:\\u001B\\][\\s\\S]*?${ST})`;
// CSI and related: ESC/C1, optional intermediates, optional params (supports ; and :) then final byte
const csi = '[\\u001B\\u009B][[\\]()#;?]*(?:\\d{1,4}(?:[;:]\\d{0,4})*)?[\\dA-PR-TZcf-nq-uy=><~]';
const pattern = `${osc}|${csi}`;
return new RegExp(pattern, onlyFirst ? undefined : 'g');
} ... | wc -c
592
I guess having some cool down period after some strange profile activity (e.g. you've suddenly logged from China instead of Germany) before you're allowed to add another signing key would help, but other than that?
Hell no. CI needs to be a clean environment, without any human hands in the loop.
Publishing to public registries should require a chain of signatures. CI should refuse to build artifacts from unsigned commits, and CI should attach an additional signature attesting that it built the final artifact based on the original signed commit. Public registries should confirm both the signature on the commit and the signature on the artifact before publishing. Developers without mature CI can optionally use the same signature for both the source commit and the artifact (i.e. to attest to artifacts they built on their laptop). Changes to signatures should require at least 24 hours to apply and longer (72 hours) for highly popular foundation packages.
It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.
In the attack described above, the attacker did not have access to the victim's email address.
Why does the mobile app use a completely different domain? Who designed this thing?
Password managers themselves have had vulnerabilities, browser autofill can fail, and phishing can bypass even well-trained users if the attack is convincing enough.
Good hygiene (password managers, MFA, domain awareness) certainly reduces risk, but it doesn’t eliminate it. Framing security only as a matter of 'individual responsibility' ignores that attackers adapt, and that humans are not perfect computers. A healthier approach would be: encourage best practices, but also design systems that are resilient when users inevitably make mistakes.
It's not easy to be 100% vigilant 100% of the time against attacks deliberatly crafted to fall for them. All it takes is a single well crafted attack that strikes when you're tired and you're done.
Now? Why aren't everyone setting up own GitHub mirrors is beyond me, almost. They were 100% right.