npm Chalk & Debug Packages Compromised: How to Check If You're Impacted

On September 8, 2025, Aikido researchers discovered that 18 highly popular npm packages (including chalk, debug, ansi-styles, and strip-ansi) were compromised with malicious code designed to intercept crypto and Web3 transactions. Together, these packages account for more than 2 billion downloads per week.

The malware hooks into fetch, XMLHttpRequest, and wallet APIs like window.ethereum and Solana providers. It rewrites payment destinations and approvals with attacker-controlled addresses, all while staying invisible to the user.

Check If You're Impacted Right Now

At Mate, we've immediately created detection queries and direct search links to help you identify if your organization is impacted. Our approach covers both your development pipeline and production environments, we’ve built direct queries you can use right now:

• SBOM links→ Pre-filtered inventory links for each compromised package and version. Clicking the link takes you straight to results within your SBOM manager (e.g Wiz SBOM).
• GitHub search → Ready-to-run queries across your organization’s repos to see if these versions are referenced in lockfiles or manifests.
• Local checks → Mate Agent can run the same detection logic locally for projects not yet committed to GitHub.

This means you can verify exposure in both running environments (Shift Right) and source code (Shift Left) without waiting for CVEs or vendor-published queries.
‍

Bonus: One-click “all packages” GitHub org search

Use this to scan your org’s lockfiles for any of the exact versions in one go (edit YOUR_ORG_NAME first):

• All-in-one query:
  GitHub code search

Tip: You can further restrict to lockfiles with filename:package-lock.json OR filename:yarn.lock OR filename:pnpm-lock.yaml in the search box to prevent GitHub from failing the search query.

Check Lock Files Locally

You can quickly check whether your local project lockfiles reference the compromised versions by using grep. This works even before code is pushed to GitHub.

‍

# For npm projects
grep -E "(ansi-styles.*6\.2\.2|debug.*4\.4\.2|chalk.*5\.6\.1|strip-ansi.*7\.1\.1|supports-color.*10\.2\.1|ansi-regex.*6\.2\.1|wrap-ansi.*9\.0\.1|color-convert.*3\.1\.1|slice-ansi.*7\.1\.1|is-arrayish.*0\.3\.3|color-name.*2\.0\.1|error-ex.*1\.3\.3|color-string.*2\.1\.1|simple-swizzle.*0\.2\.3|has-ansi.*6\.0\.1|supports-hyperlinks.*4\.1\.1|chalk-template.*1\.1\.1|backslash.*0\.2\.1)" package-lock.json

# For pnpm projects  
grep -E "(ansi-styles.*6\.2\.2|debug.*4\.4\.2|chalk.*5\.6\.1|strip-ansi.*7\.1\.1|supports-color.*10\.2\.1|ansi-regex.*6\.2\.1|wrap-ansi.*9\.0\.1|color-convert.*3\.1\.1|slice-ansi.*7\.1\.1|is-arrayish.*0\.3\.3|color-name.*2\.0\.1|error-ex.*1\.3\.3|color-string.*2\.1\.1|simple-swizzle.*0\.2\.3|has-ansi.*6\.0\.1|supports-hyperlinks.*4\.1\.1|chalk-template.*1\.1\.1|backslash.*0\.2\.1)" pnpm-lock.yaml

# For yarn projects  
grep -E "(ansi-styles.*6\.2\.2|debug.*4\.4\.2|chalk.*5\.6\.1|strip-ansi.*7\.1\.1|supports-color.*10\.2\.1|ansi-regex.*6\.2\.1|wrap-ansi.*9\.0\.1|color-convert.*3\.1\.1|slice-ansi.*7\.1\.1|is-arrayish.*0\.3\.3|color-name.*2\.0\.1|error-ex.*1\.3\.3|color-string.*2\.1\.1|simple-swizzle.*0\.2\.3|has-ansi.*6\.0\.1|supports-hyperlinks.*4\.1\.1|chalk-template.*1\.1\.1|backslash.*0\.2\.1)" yarn.lock

‍

If the command returns matches, your project is using one of the compromised versions and should be remediated.

You can also use npm audit to identify known vulnerabilities in your project dependencies:

‍

npm audit

‍

Note: At the time of writing, these compromised packages do not yet have CVEs assigned, which means npm audit may not flag them. It's still useful to run, but version-level checks (like the ones above) are currently the most reliable way to catch this issue.

Use npm ci / pnpm install --frozen-lockfile in Your Pipelines

The reason a malicious package can be installed in your pipeline, despite your package-lock.json / pnpm-lock.yaml, is the use of npm install / pnpm install. This command can update dependencies based on semantic versioning rules in package.json.

npm ci / pnpm install --frozen-lockfile on the other hand, is designed for automated environments. It performs a clean install exactly according to the package-lock.json / pnpm-lock.yaml file. If a dependency doesn't match the lockfile, it will throw an error instead of installing a potentially malicious newer version.

Switching to npm ci / pnpm install --frozen-lockfile is the single most important change you can make to prevent supply chain attacks in your CI/CD pipelines.

‍

# Instead of this in your CI/CD
npm install

# Use this
npm ci

# Instead of this in your CI/CD  
pnpm install

# Use this
pnpm install --frozen-lockfile

‍

Found Compromised Packages? Here's Your Action Plan

Mitigation: Work with Developers

• Identify ownership → Use git blame on the affected lockfile lines to see which developer or team introduced the package version.
• Escalate with context → Share the detection result with the owner, so they understand which package and version need updating.
• Developer action → The developer updates the dependency and regenerates the lockfile.
• Track → Track that the remediation has been assigned and monitor until the update is merged and deployed.

Verification: Confirm Closure

• Re-run detection queries → After remediation, SOC rechecks with Wiz SBOM, GitHub search, or Mate Agent to confirm the malicious version is no longer present.
• Runtime validation → Ensure running environments are no longer loading compromised versions.
• Prevent recurrence → Work with DevSecOps to set guardrails in CI/CD (dependency policies, version pinning) so the same issue doesn’t reappear.

Why This Matters

This compromise is a reminder of how quickly supply chain risk can spread. The affected packages (chalk, debug, ansi-styles, and many others) are deeply embedded across the JavaScript ecosystem. Because they don’t come with CVE identifiers and vendor queries are not yet available, detection has to happen at the version level.

By checking your environments with the Wiz SBOM queries and scanning your repositories with the GitHub search queries, you can quickly confirm whether you are pulling in the compromised versions. If you find matches, the next step is to work with your engineering teams to upgrade or replace the affected dependencies.

The key takeaway: don’t wait for external advisories to trickle down. Having a way to query package versions directly, in both production and source code, lets you respond as soon as new compromises are discovered.

Conclusion

Supply chain attacks like this remind us that modern threats require more than just detection - they require intelligent, context-aware response. Your SOC doesn't need more alerts; it needs the organizational intelligence to act on them decisively.

Stay secure, The Mate Team