Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

411–420 of 796 posts

Re: NPM debug and chalk packages compromised

#411

Earlier quoted context omitted.

yes. ripgrep just does it faster, is all.

But also respects .gitignore by default so I’m not sure you want to use ripgrep to scan your node_modules

Isn't the intended behaviour of original comment checking the node_modules folder for the "infected" string.

Re: NPM debug and chalk packages compromised

#412
post #246
post #9

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-conve…

We also caught this right away at Socket, 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.

So how do you detect these attacks?

Re: NPM debug and chalk packages compromised

#413

Earlier quoted context omitted.

[flagged]

I feel like you were trying to help here, but anyone can do this for themselves. Providing information in this way sort of indicates that you don't believe that the person you're replying to can do it on their own, and for that reason it's considered rude.

Also, HN hates machine generated replies, especially the lengthy and overly verbose slop variety -- I think that probably eclipsed any perceived rudeness.

Re: NPM debug and chalk packages compromised

#414
post #324

Earlier quoted context omitted.

Almost certainly Lazarus

The phishing email comes across a bit too amateur. Specifically the inclusion of: "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...

[dead]

Re: NPM debug and chalk packages compromised

#415
post #349

Earlier quoted context omitted.

Tbh, it's not your fault per se; everybody can fall for phishing emails. The issue, IMO, lies with npmjs which publishes to everyone all at the same time. A delayed publish that allows parties like Aikido and co to scan for suspicious package uploads first (e.g. big changes in patch releases, obfuscated code, code that intercepts HTTP calls, etc), and a direct flagging system at NPM and / or Github would already be a…

Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.

Wouldn't they have been able to change your key if they had compromised your entire npm account?

Also, junon.support++ – big thanks for being clear about all this.

Re: NPM debug and chalk packages compromised

#416
post #194

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…

Dependabot now supports "cooldown" config for this case:

https://github.blog/changelog/2025-07-01-dependabot-supports...

Re: NPM debug and chalk packages compromised

#417
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.

Re: NPM debug and chalk packages compromised

#418
post #77

Earlier quoted context omitted.

But why can’t we have a good library instead of those mini thingies?

Because a mini thing can be written in mini time by a mini number of people

And a mini thing can be switched to another 'mini' package easy enough if the current package decides to do something dumb.

If your mega package decides to drop something you need you pretty much have to follow.

Re: NPM debug and chalk packages compromised

#419

Earlier quoted context omitted.

NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them

It's not like NPM pre-Microsoft was a paragon of professional management or engineering...

The difference is in the apparent available resources. You cant get to "professional" without the time and money, and NPM post acquisition, presumably, has more of both. Granted, NPM probably doesn't have a revenue model to speak of, which means Microsoft is probably not paying it much attention.

Re: NPM debug and chalk packages compromised

#420
post #286

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 like this idea and could see it being visually represented as a faint red/green bar behind the URL text in the address bar, with a greater amount of the bar being red when the domain is less trusted.

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.

Post reply on HN