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

[marcalexiei]

• Follow up of #6099

Consider the following advisories:

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

• https://github.com/debug-js/debug/issues/1005#issue-3394266240
• https://github.com/chalk/chalk/issues/656#issuecomment-3266894253
• https://github.com/chalk/chalk/issues/656#issuecomment-3266900029

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? https://github.com/advisories/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.

[ReanimationXP]

Thanks for doing that.

For the new versions probably the sooner the better. The CVE will implicate the bad version number so as long as you are clear about which versions are affected, and the newer version is incremented higher than that, it's best that the new ones be available already for when people get or see the CVE and try to update. It also ensures that any packages that are just referencing @latest are provoked into pulling the new, unaffected code. This is assuming of course that you have properly locked down your accounts (by forcing sign out of all sessions, changing password, adding MFA, and forcing sign out again for good measure) for all accounts and their respective email accounts involved with managing your code. Keep in mind that if you reused that password anywhere else, those accounts need to be secured as well in the same way.

It's important for us to know for sure whether or not you have regained access to and secured the compromised accounts, so let people know that.

[Qix-]

Oh sorry I think I miscommunicated: the packages have been published with new versions already, that's done. I meant whether or not I should publish the advisory drafts before the CVEs have been assigned, or not. Currently they remain as drafts.

And yes I've regained access and have a U2F key enabled on the account. Sorry if I wasn't clearer about that earlier; that happened the same day of the attack.

I have a link to my account logs as well, which will be needed for the post-mortem, but still waiting on access to the link.

[Qix-]

Will update as they become available.

debug: CVE-2025-59144 error-ex: CVE-2025-59330 color-string: CVE-2025-59142 backslash: CVE-2025-59140 is-arrayish: CVE-2025-59331 simple-swizzle: CVE-2025-59141 color: CVE-2025-59143 color-convert: CVE-2025-59162 color-name: CVE-2025-59145 <pending publication>

chalk packages: <pending>