Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A super quick script to check the deps in your package-lock.json file is here[0].

[0]: https://gist.github.com/martypitt/0d50c350aa7f0fc73354754343...



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


Nice - that's even better - thanks! TIL.


how about:

grep -r "_0x112fa8"


Irritatingly, this doesn't turn up anything, despite having a theoretically-compromised project as per the package-lock.json… At least on my end


What do you mean irritatingly? Do you mean that you think 'grep -r "_0x112fa8"' is not enough or are you irritated that npm audit is flagging as if it was compromised?


I'm irritated because I expected to find at least one compromised file, but there were none. It may be, though, that we only use the affected packages as transitive development dependencies, in which case they are not installed locally. But a sliver of doubt remains that I missed something.


If you had the dependency installed before this attack, then you would still be pinned to an old safe version.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: