NPM debug and chalk packages compromised • Hacker News Board

Re: NPM debug and chalk packages compromised

#331

Post by brycewray » Mon, Sep 08, 2025, 7:34 PM UTC

epmatsw wrote: post #88

patates wrote: post #76

Earlier quoted context omitted.

aren't these already nuked and show up in the "npm audit" command?

Annoyingly, npm audit relies on github's advisory DB, which is currently incorrectly flagging all versions of these packages, not just the compromised ones. https://github.com/github/advisory-database/issues/6098

“Anatomy of a Billion-Download NPM Supply-Chain Attack”[0] suggests adding this to `package.json` for now...

    "overrides": {
      "chalk": "5.3.0",
      "strip-ansi": "7.1.0",
      "color-convert": "2.0.1",
      "color-name": "1.1.4",
      "is-core-module": "2.13.1",
      "error-ex": "1.3.2",
      "has-ansi": "5.0.1"
    }

EDIT: This comment[1] suggests `npm audit` issue has now been resolved.

[0] https://jdstaerk.substack.com/i/173095305/how-to-protect-you...

[1] https://github.com/chalk/chalk/issues/656#issuecomment-32676...

Re: NPM debug and chalk packages compromised

#332

Post by josefbud » Mon, Sep 08, 2025, 7:34 PM UTC

sigotirandolas wrote: post #276

josefbud wrote: post #263

Earlier quoted context omitted.

I'm a little confused on one of the excerpts from your article. > 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 upda…

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. 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.

Yeah, I think I had made the assumption that they were using `npm ci` / `yarn install --frozen-lockfile` / `pnpm install --frozen-lockfile` in CI because that's technically what you're always supposed to do in CI, but I shouldn't have made that assumption.

Re: NPM debug and chalk packages compromised

#333

Post by Cthulhu_ » Mon, Sep 08, 2025, 7:34 PM UTC

junon wrote: 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…

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

Re: NPM debug and chalk packages compromised

#334

Post by vladkens » Mon, Sep 08, 2025, 7:36 PM UTC

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.

Re: NPM debug and chalk packages compromised

#335

Post by josefbud » Mon, Sep 08, 2025, 7:36 PM UTC

DDerTyp wrote: post #284

sigotirandolas wrote: post #276

Earlier quoted context omitted.

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`. 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.

TIL: I need to fix my CI pipeline. Gonna create a jira ticket I guess… Thank you!

Sorry, I had assumed this was what you were doing when I wrote my question but I should have specified. And sorry for now making your npm install step twice as long! ;)

Re: NPM debug and chalk packages compromised

#336

Post by paulddraper » Mon, Sep 08, 2025, 7:37 PM UTC

craftkiller wrote: post #67

paulddraper wrote: post #29

Earlier quoted context omitted.

Which of these would you prefer to reimplement? Debug, chalk, ansi-styles? --- You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

> You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years. Okay, but you're not suggesting that a compression algorithm is the same scale as "is-arrayish". I don't think everyone should need to reimplement LZMA but installing a library to determine if a value is an array is bordering on satire.

FWIW, is-arrayish is primarily an internal dependency. The author (Qix) depends on it for the packages that actually get used, liked color and error-ex.

But it's all one author.

Re: NPM debug and chalk packages compromised

#337

Post by pants2 » Mon, Sep 08, 2025, 7:37 PM UTC

Joker_vD wrote: post #221

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.

Mmm. But how does the package registry know which signing keys to trust from you? You can't just log in and upload a signing key because that means that anyone who stole your 2FA will log in and upload their own signing key, and then sign their payload with that . 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…

That still requires stealing your 2FA again. In this attack they compromised a one-time authenticator code, they'd have to do it a second time in a row, and the user would be looking at a legitimate "new signing key added" email alongside it.

Re: NPM debug and chalk packages compromised

#338

Post by xorcist » Mon, Sep 08, 2025, 7:38 PM UTC

mschuster91 wrote: post #240

goku12 wrote: post #99

Earlier quoted context omitted.

Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.

the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.

That's just it. If any of the browser vendors put 1% of the work they spent on renewing their visual identity, remodeling their home page, or inventing yet another menu system into slightly easier to use client certificates (and smart cards) this would have been a solved problem two decades ago. All the pieces are in place, every browser has supported this since the birth of SSL, it's just the user interface bits that are missing.

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.

Re: NPM debug and chalk packages compromised

#339

Post by tripplyons » Mon, Sep 08, 2025, 7:38 PM UTC

internetter wrote: post #300

winwang wrote: post #68

Earlier quoted context omitted.

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

in general npm does a not-too-great job with these things

Remember, NPM stands for Now Part of Microsoft!

(Microsoft owns GitHub, which owns NPM.)

Re: NPM debug and chalk packages compromised

#340

Post by Cthulhu_ » Mon, Sep 08, 2025, 7:40 PM UTC

PokestarFan wrote: post #174

cddotdotslash wrote: post #154

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.

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

But Github does loads of things with security, including reporting compromised NPM packages. I didn't know NPM is owned by Microsoft these days though, now that I think about it, Microsoft of all parties should be right on top of this supply chain attack vector - they've been burned hard by security issues for decades, especially in the mid to late 90's, early 2000s as hundreds of millions of devices were connected to the internet, but their OS wasn't ready for it yet.