When NPM Goes Rogue: The @ctrl/tinycolor Supply-Chain Attack

Technical Analysis

Here is how the attack is structured, in stages:

1. Initial Compromise & Post-Install Payload
   A malicious bundle (≈ 3.6 MB, minified, “bundle.js”) is injected into compromised package versions. The actor uses postinstall hooks (in package.json) to ensure that code runs during npm install.
   
2. Self-Propagation Across Maintained Packages
   Once the malware has control (via a user’s NPM credentials/NPM_TOKEN), it queries the NPM registry to find all packages maintained by that user (up to 20), and force-publishes patched versions including the malicious bundle. This allows cascading compromise across the owner’s entire package portfolio.
   
3. Credential & Secret Harvesting
   
   • Dumps environment variables (process.env) to look for tokens like AWS_ACCESS_KEY_ID, GITHUB_TOKEN, etc.
     
   • Uses tools like TruffleHog to scan the filesystem for high-entropy secrets.
     
   • Accesses cloud secret stores: AWS Secrets Manager, Google Cloud Secret Manager, Azure credentials, metadata endpoints where possible.
     
4. Persistence via GitHub Backdoor
   A malicious GitHub Actions workflow file, named something like .github/workflows/shai-hulud-workflow.yml, is injected. It triggers on push events, uses a base64-encoded script to exfiltrate secrets via $ {{ toJSON(secrets) }} to a remote endpoint. As part of this, the attacker may create a branch shai-hulud or force patches into existing repos.
   

Evasion & Silent Failures
The malware hides its activity: error handling swallows failures, no conspicuous logs, various modules are modularized so only needed code is loaded. It also deliberately excludes Windows hosts (activates only on Linux or macOS).

Impacted Packages

Here is the confirmed list of compromised packages and their versions. If your projects depend on any of them (directly or transitively), treat them as suspect.

Detection & Mitigation

Here are actionable steps for detection and mitigation (both immediate and longer-term) from Kodem’s Security Research Team:

Immediate Steps

• Audit your dependency tree. Use npm ls <package> (or equivalent in Yarn/pnpm) to check if you depend (directly or indirectly) on any of the above compromised packages. Remove or pin to safe versions (if available).
  
• Search for the known malicious bundle. The SHA-256 hash of the compromised bundle.js is:
  46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
  
• Inspect GitHub repositories in your organisation for the malicious workflow file .github/workflows/shai-hulud-workflow.yml, and branches named shai-hulud. Remove them.
  
• Rotate credentials: any NPM tokens, GitHub PATs, cloud credentials (AWS, GCP, Azure), SSH keys, CI/CD secrets, etc. Assume they may have been exposed.
  

Medium & Long-Term Defenses

• Least privilege for automation tokens. Ensure that tokens used for publishing or CI only have exactly the permissions needed. Separate credentials used for publishing from those with broad access.
  
• Use code review / dependency gating. Implement policies (e.g. via CI) that require review when adding or upgrading dependencies; particularly new versions of packages with large download counts.
  
• Monitor publishing activity. Tools that detect anomalous publishes (e.g. new versions in quick succession, forced patches) are valuable.
  
• Audit cloud secret access logs regularly. For AWS, GCP, Azure: audit access to Secrets Manager, look for unusual or suspicious secret reads, cross-region access, unexpected service account key creation.
  
• Enable branch protections, secret scanning, workflow approvals in GitHub (or equivalent) to reduce risk from malicious workflows.
  
• Supply chain risk awareness. For organisations, maintain an inventory of dependencies; understand which maintainers are shared; understand transitive dependency risks.
  

Why This Matters & Lessons Learned

• Supply chain attacks are evolving. This one is not just about inserting malicious code into one package; it self-propagates via maintainer accounts, cloud creds, GitHub workflows.
  
• Wider blast radius. With over 40 packages affected, and many downstream consumers, the risk of exposure is very large, across many projects and organisations.
  
• Detection is hard when evasion is baked in. Silent failures, modular payloads, skipping Windows hosts, using base64 and obfuscation, all make this harder to detect until damage is done.
  
• Importance of proactive measures. Having detection tools in place before compromise (like monitoring publish events, gating dependency upgrades, reviewing workflows) can mitigate damage.
  

Conclusion

The @ctrl/tinycolor compromise is a stark reminder that even trusted, popular packages in NPM can become attack vectors. The layers of malicious behavior here (credential harvesting, propagation, GitHub backdoors) make this especially dangerous. Developers, maintainers, and security engineers need to assume breach: inspect dependencies, log and audit cloud credentials, enforce least privilege, and incorporate supply chain risk checks into CI/CD.

If you believe you or your organisation may have been affected, act immediately: remove compromised dependencies, rotate credentials, search for backdoor workflows, audit systems. Then, review and strengthen your processes to reduce risk in the future.

References

Here are sources and additional reading:

• StepSecurity. (2025, September 15). ctrl/tinycolor and 40+ NPM Packages Compromised. StepSecurity. Retrieved from https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised (StepSecurity)
• Socket.dev. (2025). [Analysis of the ctrl/tinycolor compromised packages]. Socket.dev. (Original discovery attribution) (StepSecurity)