Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

501–510 of 796 posts

Re: NPM debug and chalk packages compromised

#501

Post by dgl »

bflesch wrote: post #89
junon wrote: post #45

Earlier quoted context omitted.

That it had been more than 12 months since last updating them. Npm has done outreach before about doing security changes/enhancements in the past so this didn't really catch me. Screenshot here: https://imgur.com/a/q8s235k

Thanks for sharing, I've created an OTX entry for this: https://otx.alienvault.com/pulse/68bf031ee0452072533deee6

Just looking for "const _0x112" as an IOC seems a bit false positive prone: https://github.com/search?q=%2Fconst+_0x112%2F+lang%3Ajs&typ... (most of that code is pretty dodgy obviously, but it's not unique enough to identify this).

Re: NPM debug and chalk packages compromised

#502

Post by dabockster »

joaomoreno wrote: post #129

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

Here's something I generated in my coding AI for Powershell:

`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.

Re: NPM debug and chalk packages compromised

#503

Post by 6mile »

molsson wrote: post #316

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: 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 ; Mon, 8 Sep 2025…

That domain (npmjs[.]help) has been taken down. Looks like it was purchased and started hosting on September 5th, 2025.

Re: NPM debug and chalk packages compromised

#504

Post by rtpg »

const_cast wrote: post #490
0xbadcafebee wrote: post #278

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. W…

A lot of these security measures have trade offs, particularly when we start looking at heuristics or attestation-like controls. 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…

I have a hard time arguing that 2FA isn't a massive win in almost every circumstance. Having a "confirm that you have uploaded a new package" thing as the default seems good! Someone like npm mandating that a human being presses a button with a recaptcha for any package downloaded by more than X times per week just feels almost mandatory at this point.

The attacks are still possible, but they're not going to be nearly as easy here.

Re: NPM debug and chalk packages compromised

#505

Post by dabockster »

thayne wrote: post #423
tripplyons wrote: post #339

Earlier quoted context omitted.

Remember, NPM stands for Now Part of Microsoft! (Microsoft owns GitHub, which owns NPM.)

Which means they don't have the excuse of being a volunteer effort to not be on top of this. MS has plenty of resources.

If you're running this kind of infrastructure online these days, you have every right to require payment somehow. Don't work for free.

Re: NPM debug and chalk packages compromised

#506

Post by rtpg »

a022311 wrote: post #169

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.

I'm a fan of post-facto confirmation. Allow CI/CD to do the upload automatically, and then have a web flow that confirms the release. Release doesn't go out unless the button is pressed.

It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.

Re: NPM debug and chalk packages compromised

#507

Post by dabockster »

junon wrote: post #141
zachleat wrote: post #132

Earlier quoted context omitted.

Yo, someone at npm needs to unpublish simple-swizzle@0.2.3 IMMEDIATELY. It’s still actively compromised.

It's been almost two hours without a single email back from npm. I am sitting here struggling to figure out what to do to fix any of this. The packages that have Sindre as a co-publisher have been published over but even he isn't able to yank the malicious versions AFAIU. 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.

I haven't published anything to npm in over a decade. But if you still have access to git, a cli, or a browser where the login is cached and you can access it, you should do so and either take the code down or intentionally sabotage/break it.

Re: NPM debug and chalk packages compromised

#508

Post by __MatrixMan__ »

9dev wrote: post #442
__MatrixMan__ wrote: post #380

Earlier quoted context omitted.

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.

As someone with red/green vision deficiency: if you do this, please don’t forget people like me are unable to distinguish many shades of colours, which would be very disadvantageous here!

You could still ignore the colors and just read the characters, like people do now, and you could still use whatever color cues you are sensitive to.

Re: NPM debug and chalk packages compromised

#509

Post by dabockster »

Yoric wrote: post #415
junon wrote: post #349

Earlier quoted context omitted.

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.

For this kind of infrastructure, some kind of real world verification may be necessary as well. Like having human ran phone verification (not AI, an actual call center) using information intentionally kept offline for securing more widespread and mission critical packages.

They can't pwn what they can't find online.

Re: NPM debug and chalk packages compromised

#510

Post by __MatrixMan__ »

Spivak wrote: post #390
__MatrixMan__ wrote: post #380

Earlier quoted context omitted.

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.

Not sure why you're being downvoted, OpenSSH implemented randomart which gives you a little ascii "picture" of your key to make it easier for humans to validate. I have no idea if your scheme for producing keyart would work but it sounds like it would make a color "barcode".

If you ignored the characters and just focused on the background colors, yeah I suppose it would look like a barcode. But the way I envision it, each line on the barcode is a character, so it still copy/pastes into notepad as the original text, but it'll copy/paste into word as colored text with colored background.
Post reply on HN