npm debug / chalk Supply-Chain Attack: The Complete Guide

Key Highlights

• What happened? Multiple popular npm packages (including debug, chalk, and core dependencies like ansi-styles, strip-ansi, supports-color) were published with malicious, browser-side code that silently intercepts crypto/web3 activity and rewrites payment destinations to attacker addresses.
  
• When? Malicious versions began appearing September 8, 2025 ~13:15 UTC, detected by Aikido.
  
• Scope: 18 packages, collectively >2B weekly downloads, making this a potentially far-reaching incident.
  
• Initial vector: Maintainer phished via a fake npm support domain npmjs.help.
  
• What it does: Hooks fetch/XMLHttpRequest and wallet APIs (e.g., window.ethereum, Solana), then reroutes transactions/approvals to attacker-controlled addresses.
  
• Act now: Identify if your builds ingested the malicious versions below, rotate secrets, and invalidate any client bundles produced during the window.

What are the debug / chalk npm packages?

debug provides lightweight namespaced logging. chalk powers terminal string styling. They sit beneath a huge portion of the Node.js ecosystem, and their transitive deps (e.g., ansi-styles, supports-color, strip-ansi, wrap-ansi) are embedded widely — which is why poisoning these supply-chain nodes can ripple across countless apps.

What Happened?

On September 8, 2025, new versions of 18 high-traffic packages were pushed to npm with obfuscated code that, when executed in a browser context, monitors and tampers with crypto/web3 flows. The malware hooks into network and wallet APIs, rewriting recipients and approval targets to attacker addresses — all while keeping the UI looking legitimate. 

The attack began with a successful phishing attack against a package maintainer via a fake npm support domain (npmjs.help).

Quick Timeline of the Compromise

1. Sep 8, 2025 (morning US time): Maintainer targeted by [email protected] phishing.
   
2. Fake support domain npmjs.help registered.
   
3. Sep 8, ~13:16 UTC: Malicious versions start appearing.
   
4. Sep 8 (afternoon UTC): Maintainer acknowledges compromise on Bluesky; begins removal/cleanup.
   
5. Later Sep 8: Researchers observe another maintainer/package targeted ([email protected]) using the same payload pattern

What is the Impact?

• Important exposure conditions (from bleeping computer): Most apps were only at risk if (1) they performed a fresh install between ~13:00 and ~15:30 UTC on Sep 8, 2025, (2) the lockfile was created during that window, and (3) one of the compromised packages was included (directly or transitively). If those conditions don’t apply, your exposure is likely limited.
• Browser-side risk: If the malicious code shipped into client bundles for web apps, end-users interacting with crypto wallets (Ethereum, Solana, etc.) could have transactions silently redirected.
  
• Stealth: The payload hooks wallet methods (e.g., eth_sendTransaction, Solana signing methods) and rewrites data pre-signature, making UI checks unreliable.
  
• Breadth: Because many projects import these packages transitively, you may be exposed even if you didn’t explicitly depend on debug or chalk.

How Do I Know If My Repositories Are Affected?

1. Search your dependency graph (including lockfiles) for these exact malicious versions:
   
   • [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected].
     
     
2. Check recent builds: Identify web builds generated on/a few hours after Sep 8, 2025 13:16 UTC that could have pulled these versions. Rebuild after remediation.
   
   
3. Audit CDN / artifact storage (e.g., S3, Cloudflare): purge affected JS bundles.
   
   
4. Runtime telemetry: Look for anomalous wallet call patterns or outbound traffic consistent with rewritten destinations. (See IOCs.)

What Immediate Steps Should I Take to Mitigate the Risk?

Pin / revert dependencies

• Lock to known-good versions or revert to pre-Sep 8 releases for the packages listed above.
  
• Regenerate lockfiles and force clean install to avoid cached artifacts.
  

Rebuild & invalidate client caches

• Rebuild web artifacts after cleanup and purge CDN caches to prevent clients from loading tainted bundles.
  

Incident response & monitoring

• Review logs for wallet API calls originating from your app that diverted to attacker addresses.
  
• If end-users could have interacted with crypto features, prepare customer comms and support guidance.
  

Rotate secrets where relevant

• While this payload targets client-side flows, standard practice is to rotate any exposed tokens and review CI logs/artifacts produced during the window.

How Can I Prevent Similar Supply-Chain Attacks in the Future?

1. Strict version pinning + provenance

• Use lockfiles, enable provenance/SLSA where available, and allow-list registries and ranges.
  

2.Malware & behavior screening in CI

• Static checks are not enough; add malware heuristics and runtime-aware tests that flag suspicious browser hooks (e.g., mass overriding of fetch, wallet APIs).
  

3.Registry hygiene & publisher validation

• Monitor for maintainer takeovers, sudden ownership changes, or unexpected domain/contact shifts (like npmjs.help).
  

4.Frontend release discipline

• Immutable artifact naming, SBOMs for client bundles, and automatic CDN purge on security rollbacks.

Indicators of Compromise (IOCs)

Phishing domain

• npmjs.help (sender: [email protected]).
  

Malicious package versions

• See the complete list under “How Do I Know…”.
  

TTPs

Hooks fetch/XMLHttpRequest and wallet APIs (e.g., window.ethereum), monitors Ethereum, Bitcoin, Solana, Tron, Litecoin, and Bitcoin Cash addresses/flows, and rewrites recipients before signing

How Cycode Helps Organizations Strengthen Their Software Supply Chain Security

1) Rapid blast-radius analysis with RIG

Cycode’s Risk Intelligence Graph pinpoints where malicious or vulnerable package versions enter your environment (direct or transitive), shows which pipelines built affected artifacts, can link those packages to code assets, and prioritizes remediation based on real execution during the exposure window.

2) Policy enforcement for package hygiene

Enforce allow-listed registries, block unverified publishers, and prevent builds when dependency drifts outside approved ranges.

3) Automated Threat Intel

Our feeds map known malicious versions (like the set in this incident) to your repos and pipelines, generating targeted alerts which include specific findings, and one-click fix guidance.

Conclusion

This campaign weaponizes a few foundational npm packages to push browser-side malware into web apps — a stark reminder that transitive dependencies can be the weakest link. By rapidly identifying malicious versions, rebuilding clean artifacts, and hardening dependency and release practices, you reduce both time-to-contain and end-user risk.