
npm ecosystem alert: What you need to do today with Cloudsmith

The npm ecosystem was hit yesterday by a malware attack affecting popular packages like debug and chalk. Both packages are typically bundled into frontend builds. Once included, the malicious payload executes.
These attacks are becoming more frequent - we reported on a similar attack on npm packages just 12 days ago.
How you react depends on what is known about the threat:
Zero-day
- The issue is real, but not yet reported in public databases
- No CVE, MAL, or OSV.dev record
- You cannot automatically detect or block it - your only option is rapid manual actions
N-day
- The issue is documented and tracked (i.e. it has a CVE or MAL ID)
- Security feeds and tools, including Cloudsmith’s Enterprise Policy Management (EPM), can use that tracking to automatically quarantine or block affected packages
When this most recent npm attack was reported by the team at Aikido, it was considered a zero-day threat (potentially compromised packages were identified, but no official designation yet).
Within 24 hours, these packages were confirmed as malicious, and added to the OSV.dev database. Cloudsmith and other similar platforms can then OSV.dev updates and thereby enable automated remediations.
We recommend the following actions for all Cloudsmith customers, regardless of whether you’ve confirmed that any affected packages have been used in builds or are currently present in any of your Cloudsmith repositories.
For Zero-day threats - Block with Deny Rules
1. Add [Deny Rules] that block downloads immediately. This stops any installs in dev, CI, or production environments.
For this scenario, a simple set of rules targeting the compromised packages/versions would have blocked all download attempts. This protects developers who may not have heard the news yet.
For example:
To block the compromised debug package:
(format:npm) AND (name:^debug$ AND version:^4.4.2$)

To block the compromised chalk package:
(format:npm) AND (name:^chalk$ AND version:^5.6.1$)

See the end of this article for a full list of Deny Rules.
2. Audit potential exposure. Use Client Logs to identify who pulled compromised packages and when. Cloudsmith logs are near real-time, so searching for and identifying users andservice accounts that have accessed these packages will help determine potential impact.
For N-Day threats - Quarantine and Flag with EPM
Enable Enterprise Policy Management (EPM) and Continuous Security. Put policies in place to quarantine malicious packages that do not have a fix, or have not been verified and granted an exception from your security team.
Our OSV.dev feed refreshes every hour and will detect newly identified malicious packages automatically. This protects you if compromised packages are already in Cloudsmith repositories. In order to enable continuous securityadd an EPM policy to automatically tag and quarantine new malware.
package cloudsmith
default match := false
match if count(malicious_packages) > 0
malicious_packages := [vulnerability.id |
some vulnerability in input.v0.osv
startswith(vulnerability.id, "MAL-")
]
Why this matters now
The gap between zero-day and n-day is when development teams are most exposed. This “lag” introduces risk, against which the fastest defense is Deny Rules.
Once advisories are live and the zero-day is now an n-day, EPM and Continuous Security take over, eliminating manual effort and keeping build pipelines safe.
Looking ahead: smarter protection is coming
Cloudsmith includes detection and protection against malware and vulnerabilities as a native capability in our Ultra and Enterprise tiers. Every artifact in a Cloudsmith repository is, by definition, in a controlled, policy-enforced environment.
We’re working to include more threat intel sources, richer context, and community feeds like deps.dev, along with the ability to bring your own internal threat data into Continuous Security.
Full list of relevant Deny Rules
Create a Deny Rule for each separate query string.
(format:npm) AND (name:^backslash$ AND version:^0.2.1$)
(format:npm) AND (name:^chalk-template$ AND version:^1.1.1$)
(format:npm) AND (name:^supports-hyperlinks$ AND version:^4.1.1$)
(format:npm) AND (name:^has-ansi$ AND version:^6.0.1$)
(format:npm) AND (name:^simple-swizzle$ AND version:^0.2.3$)
(format:npm) AND (name:^color-string$ AND version:^2.1.1$)
(format:npm) AND (name:^error-ex$ AND version:^1.3.3$)
(format:npm) AND (name:^color-name$ AND version:^2.0.1$)
(format:npm) AND (name:^is-arrayish$ AND version:^0.3.3$)
(format:npm) AND (name:^slice-ansi$ AND version:^7.1.1$)
(format:npm) AND (name:^color-convert$ AND version:^3.1.1$)
(format:npm) AND (name:^wrap-ansi$ AND version:^9.0.1$)
(format:npm) AND (name:^ansi-regex$ AND version:^6.2.1$)
(format:npm) AND (name:^supports-color$ AND version:^10.2.1$)
(format:npm) AND (name:^strip-ansi$ AND version:^7.1.1$)
(format:npm) AND (name:^chalk$ AND version:^5.6.1$)
(format:npm) AND (name:^debug$ AND version:^4.4.2$)
(format:npm) AND (name:^ansi-styles$ AND version:^6.2.2$)
More articles


Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Managing Malicious Packages with Cloudsmith EPM

Malicious Package Detection in Cloudsmith
By submitting this form, you agree to our privacy policy