← Back to context

Comment by martypitt

3 months ago

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

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

9 comments

martypitt

Reply

patates 3 months ago

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

epmatsw 3 months ago
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
- brycewray 3 months ago
  
  “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...
martypitt 3 months ago

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

krona 3 months ago

how about:

grep -r "_0x112fa8"

9dev 3 months ago
Irritatingly, this doesn't turn up anything, despite having a theoretically-compromised project as per the package-lock.json… At least on my end
- mewpmewp2 3 months ago
  
  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?
  
  1 reply →
- AgentME 3 months ago
  
  If you had the dependency installed before this attack, then you would still be pinned to an old safe version.