Questions on scope and impact of `npm` malware advisories (2025-09-09)

[marcalexiei]

• Follow up of npm debug, color-convert, backslash, error-ex, simple-swizzle, is-arrayish, color-name, color-string have incorrect wildcard version in their malware advisory (2025-09-08) #6099

Consider the following advisories:

1. chalk-template GHSA-3jjr-pvq7-4jq5
2. supports-hyperlinks GHSA-hggr-35mp-qcxg
3. has-ansi GHSA-jff9-gjh4-j359
4. slice-ansi GHSA-9xjj-cmqc-578p
5. wrap-ansi GHSA-2rv4-jp6r-xgq7
6. ansi-regex GHSA-jvhh-2m83-6w29
7. supports-color GHSA-pj3j-3w3f-j752
8. strip-ansi GHSA-vfjc-p7x3-q864
9. chalk GHSA-2v46-p5h4-248w
10. ansi-styles GHSA-p5rr-crjh-x7gr
11. color-convert GHSA-ch7m-m9rf-8gvv
12. color-string GHSA-3q87-f72r-3gm6
13. backslash GHSA-m2xf-jp99-f298
14. is-arrayish GHSA-hfm8-9jrf-7g9w
15. simple-swizzle GHSA-wwpx-h6g5-c7x6
16. color-name GHSA-m99c-cfww-cxqx
17. error-ex GHSA-5g7q-qh7p-jjvm
18. debug GHSA-8mgj-vmr8-frr6

---

Affected versions

All advisories were listing every version (>= 0) as vulnerable.
However, it seems the real impact is limited.
For example, debug@4.4.2 (now unpublished) is cited as affected.
Is there a particular reason why a wildcard range was used to mark everything as vulnerable?

Honestly, I think I lost a few years of life 😅.

---

Clarity of description

The advisories currently states:

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

This suggests a full system compromise.
However, the following discussions indicate that the real impact is uncertain:

• (RESOLVED) Version 4.4.2 published to npm is compromised debug-js/debug#1005 (comment)
• Version 5.6.1 published to npm is compromised (RESOLVED) chalk/chalk#656 (comment)
• Version 5.6.1 published to npm is compromised (RESOLVED) chalk/chalk#656 (comment)

From analysis, it appears the malicious code was designed to run in the browser, and may not actually execute in a Node.js environment.
Is there any plan to update the description to reflect this?

---

This is my first time engaging in a security advisory discussion, so I apologize if some of my questions come across as basic.

[SohelIslamImran]

@marcalexiei Does it now really have full control over my computer? As stated here? GHSA-wwpx-h6g5-c7x6

I just deleted .lock file and node_modules and reinstalled.
What else do I need to do to get rid of it and be safe? @marcalexiei

[MalteMagnussen]

Any CVE ID's for this yet?

[Qix-]

AFAIK there will be no CVEs as this isn't a vulnerability; no repositories were affected. This was a compromised publishing account.

I actually don't know if CVEs are filed for malicious takeovers like this. I might be wrong. If there does need to be a CVE (as in cve.org, not as in github advisory et al) please LMK and I can make sure that's being done. Given past experience it's often the case someone else is already doing it but I haven't heard anyone filing for a CVE specifically.

[P3NG00]

As I understand, the obfuscated code was cryptojacking in some way. I don't think there was ever a full compromise of the affected machines. I think it was noticed, blew up as it was obfuscated and unsure of what it was doing, then was fully understood and updated over time. @SohelIslamImran

[JonathanLEvans]

Thank you for your questions.

First, we have updated the descriptions for the advisories to more accurately describe the impact of the malware.
As to the reason behind the initial values for the affected versions and description, they are automatically generated when the npm team removes a package. In fast paced incidents, we want to minimize the spread and impact of the malware. This means that we are often publishing advisories and issuing alerts before we have fully analyzed the capabilities of the malware.

For the CVE assignment question, the newest version of the CVE assignment rules allows for assignments issues like these.

4.1.9 Products that have been modified to become malicious, for example, trojan horses, backdoors, or similar supply chain compromises, MAY be determined to be a Vulnerability.

However, GitHub’s scope for assignment is limited to when code owners request them so unless the owners of the repos request one, we cannot assign. That being said, another CNA, such as MITRE could.

[ReanimationXP]

Apologies for my previous deleted comment, I missed the latest one. If I'm understanding correctly are you saying @qix could request that GitHub open a CVE on his behalf? Doing so might aid vulnerability scanning tools and increase awareness. Thoughts?

[JonathanLEvans]

@ReanimationXP, yes, @qix can request CVE IDs for these issues by creating a repo advisories for them and using the request a CVE ID feature.

[nickthetait]

Due to the significant scope of this compromise, I would encourage assignment of a CVE. DuckDB was caught by the same phishing campaign, which was assigned CVE-2025-59037. So Josh should take some solace in the fact that you were not the only victim.

[Qix-]

Hey @JonathanLEvans, thanks for the information. Will the repository advisories conflict with the existing advisories in any way? Just want to know exactly what I'm doing before doing anything quickly, given the scale of things.

PS Jonathan I've sent you a message on LinkedIn if you have the time.

[JonathanLEvans]

Hi @Qix-, we will handle any conflicts on our end. If you publish a repo advisory and request a CVE ID, we will assign and publish the CVE. We will then publish a global GHSA and withdraw the malware advisories, similar to how we handled the advisories for CVE-2025-59037.

Side note: You can technically request a CVE ID before you publish the repo advisory. However, since the issue is already public, publishing first reduces the delay in the process.

[ReanimationXP]

Thanks @JonathanLEvans. @nickthetait I agree.

@Qix- Time is of the essence here if you don't mind, we're already days out and though npm removed the packages fairly fast, they could still be present in developer local repos and such which might be pushed into projects at some point. A CVE would help with this and provokes vuln scanning tools to at least look at the issue when malicious code injection isn't their typical bread and butter. Also, deleting bad versions without also providing a newer version is also bad practice (though I don't know how much control you had given the account compromise. - Did you regain access to your account yet?)

@ Vuln researchers - For detection, I think focusing more on the obfuscated javascript code IoC found in the Snyk article rather than the npm libraries and version numbers would be best. My research seemed to indicate other libraries were found to have the same malicious code and there are different library lists all over the place. Lots of them are incomplete. Some list @latest packages which is bad practice as it will change over time. Relying on something like npm list and lockfiles might produce inaccurate results in certain scenarios.

[Qix-]

Hi, yes took a break from the screen last night for the first time in a week. Sounds like everything will get squared away. I'm starting everything in a few.

[Qix-]

Hey @ReanimationXP et al, I published new versions and have drafted a security advisory for each of them (color-name's will take a little longer as I don't actually own that package, but we'll get it filed shortly). I've also requested CVEs for each.

If I should publish them right away before the CVE is allocated, let me know and I can do that. I don't know the implications of that so I have held off for now.