A massive NPM supply chain attack has compromised foundational packages like Chalk, affecting over 1 billion weekly downloads. We dissect the crypto-stealing malware and show you how to protect your projects immediately.
How far back does this obfuscated code go? I'm seeing in the overrides you recommend the chalk package 5.3.0 from 2 years ago and not 9 months ago, 1 month or 22 days ago. Does this mean the malicious code is in those versions too?
The malicious code isn't in all the versions published after 5.3.0. The attacker published a new malicious patch version (e.g., 5.3.1) on top of the existing, safe ones.
The recommendation to override with 5.3.0 is a safety measure. It pins your project to the last known-safe version before the incident, preventing your package manager from automatically pulling in the brand-new compromised code.
I'm not so sure the solution of pinning versions works.. many of my peer deps use chalk 4 or lower and I get dependency errors when trying to use 5.3.0
Hi. You mentioned is-core-module, but the author of is-core-module is Jordan Harband (https://github.com/ljharb), not Qix. I went through the code and didn't find anything that indicated any sort of compromise, and both Snyk and Socket haven't identified any vulnerable versions. Additionally, the last version, 2.16.1, was published 9 months ago. Are you sure that package is in fact vulnerable?
So, to actually be affected (to become a victim), there are a few specific conditions that must be met. As I understand it, the malicious code would only trigger if you start a crypto transaction within a website that is running those compromised package versions, correct?
It sounds alarming at first, but given how quickly the issue was discovered and mitigated (congrats on that, by the way), there may not even be many, if any, production systems out there that were truly exposed.
Is my understanding right, or are there other possible scenarios where the attack could have had an impact?
Your understanding is correct. The scope is limited.
The malware could passively swap a crypto address displayed on any infected website right before you copy it, causing you to unknowingly send funds to the attacker. Furthermore, the threat doesn't vanish just because the malicious package was removed from the NPM registry. The compromised version can get "locked in" to a project's package-lock.json file or persist in cached builds, leaving a project vulnerable long after the initial incident. Therefore, while the window for new infections from the source was small, many systems could still be exposed without a proper dependency audit and cleanup.
`is-core-module` has never been maintained by anyone but me, and was not involved in this attack, or compromised in any way whatsoever. Please update your article.
Do we know how much did they gain from this?
I checked some of the BTC, ETH and LTC addresses, but I didn't find any transactions. I haven't checked them all, though.
It's roughly 400 bucks https://etherscan.io/address/0xfc4a4858bafef54d1b1d7697bfb5c52f4c166976
How far back does this obfuscated code go? I'm seeing in the overrides you recommend the chalk package 5.3.0 from 2 years ago and not 9 months ago, 1 month or 22 days ago. Does this mean the malicious code is in those versions too?
The malicious code isn't in all the versions published after 5.3.0. The attacker published a new malicious patch version (e.g., 5.3.1) on top of the existing, safe ones.
The recommendation to override with 5.3.0 is a safety measure. It pins your project to the last known-safe version before the incident, preventing your package manager from automatically pulling in the brand-new compromised code.
do you have evidence of that anywhere?
do you have evidence of that anywhere?
I'm not so sure the solution of pinning versions works.. many of my peer deps use chalk 4 or lower and I get dependency errors when trying to use 5.3.0
You can override a version for 4.* and another one for 5.* like that:
"chalk@^4": "4.1.2",
"chalk@^5": "5.3.0",
do we know if they uploaded a 4.x malicious version of chalk or did they just go with 5.x?
Hi. You mentioned is-core-module, but the author of is-core-module is Jordan Harband (https://github.com/ljharb), not Qix. I went through the code and didn't find anything that indicated any sort of compromise, and both Snyk and Socket haven't identified any vulnerable versions. Additionally, the last version, 2.16.1, was published 9 months ago. Are you sure that package is in fact vulnerable?
Since I didn't want to check everything by hand I created a python tool to check for compromised packages:
https://github.com/MartinGross/compromised_npm_package_checker
Why do they use this kind of variables "_0x2c3d7e", is it for just meaningless obfuscation variables or more than that?
So, to actually be affected (to become a victim), there are a few specific conditions that must be met. As I understand it, the malicious code would only trigger if you start a crypto transaction within a website that is running those compromised package versions, correct?
It sounds alarming at first, but given how quickly the issue was discovered and mitigated (congrats on that, by the way), there may not even be many, if any, production systems out there that were truly exposed.
Is my understanding right, or are there other possible scenarios where the attack could have had an impact?
Your understanding is correct. The scope is limited.
The malware could passively swap a crypto address displayed on any infected website right before you copy it, causing you to unknowingly send funds to the attacker. Furthermore, the threat doesn't vanish just because the malicious package was removed from the NPM registry. The compromised version can get "locked in" to a project's package-lock.json file or persist in cached builds, leaving a project vulnerable long after the initial incident. Therefore, while the window for new infections from the source was small, many systems could still be exposed without a proper dependency audit and cleanup.
Is the "npm audit" command updated to catch the malicious versions of the packages?
npm audit is pretty much useless
well, Edit Distance algos are rather in the Easy bucket of basic CS interviews, nothing sophisticated there imo
`is-core-module` has never been maintained by anyone but me, and was not involved in this attack, or compromised in any way whatsoever. Please update your article.
Fixed - sorry.
This is harsh and bound to happen more and more.
I think that's part of what Deno solves and one of the reason new apple systems give you a new pop up to authorize things every other minute.
It's the sad future we are moving towards.
[Accept Cookies]
Aikido found it first BTW : https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised
But these packages aren’t typically intended for use in the browser, so I’m not sure how the attack would even target it.
This happens only if the platform/wallet you are using are constantly updating their packages, right?
https://www.npmjs.com/package/error-ex?activeTab=versions where is version 1.3.3 ? I just saw 1.3.2 from 7years ago
Version 1.3.3 was just removed so the old (non-malware-)Version 1.3.2 is the latest one.
Nice!!! Glad to hear that it has been removed.
its sole dependency has been contamined too...