Executive Summary
The NPM ecosystem is facing another critical supply chain attack. The popular @ctrl/tinycolor package, which receives over 2 million weekly downloads, has been compromised along with more than 40 other packages across multiple maintainers. This attack demonstrates a concerning evolution in supply chain threats - the malware includes a self-propagating mechanism that automatically infects downstream packages, creating a cascading compromise across the ecosystem. The compromised versions have been removed from npm.
The incident was discovered by @franky47, who promptly notified the community through a GitHub issue. We thank theuser for his vigilance and swift action in reporting this critical security issue.
Attack Timeline and Discovery
The malicious versions of @ctrl/tinycolor (4.1.1 and 4.1.2) were published to NPM before being detected. The attack was first reported through community channels, with Socket.dev providing detailed technical analysis of the compromise.
What makes this attack particularly dangerous is its self-propagating nature - once a package is infected, the malware automatically attempts to compromise other packages maintained by the same author or accessible through available credentials.
Technical Analysis
Attack Mechanism
The malware operates through a sophisticated multi-stage attack chain:
- Self-Propagation Engine: The malware uses a function called
NpmModule.updatePackage
to automatically spread to other packages. This mechanism allows the attack to cascade through the NPM ecosystem without manual intervention. - Credential Harvesting: The malware downloads and executes TruffleHog, a popular secrets scanning tool, but repurposes it for malicious credential extraction. It specifically targets:
- NPM authentication tokens
- GitHub personal access tokens
- AWS access keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
- Google Cloud Platform service credentials
- Azure credentials
- Cloud metadata endpoints
- Persistence Mechanism: To maintain access, the malware creates a malicious GitHub Actions workflow file at
.github/workflows/shai-hulud-workflow.yml
. This workflow can be triggered to re-infect repositories or exfiltrate additional data. - Data Exfiltration: All harvested credentials and sensitive data are sent to
webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
.
Indicators of Compromise
- Malicious bundle.js SHA-256:
46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
- Exfiltration endpoint:
https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
- Malicious workflow file:
.github/workflows/shai-hulud-workflow.yml
- Suspicious function call:
NpmModule.updatePackage
Affected Packages
The following packages have been confirmed as compromised:
Immediate Actions Required
If you use any of the affected packages, take these actions immediately:
Remove or Downgrade Affected Packages
bash
# Check if you have any affected packages
npm ls @ctrl/tinycolor
# Or remove entirely if not critical
npm uninstall @ctrl/tinycolor
Rotate All Credentials
Given the comprehensive credential harvesting capabilities, immediately rotate the following credentials if the compromised package ran on your dev / ci machine:
- All NPM tokens (both automation and publish tokens)
- GitHub personal access tokens and GitHub Actions secrets
- AWS IAM credentials and access keys
- Google Cloud service account keys
- Azure service principals and access tokens
- Any other secrets stored on affected systems
Audit Your Infrastructure
- Check for the malicious workflow file:
.github/workflows/shai-hulud-workflow.yml
- Review recent NPM publishes for unauthorized packages
- Audit GitHub Actions workflow runs for suspicious activity
- Check for unexpected TruffleHog executions
- Monitor outbound connections to
webhook.site
Clean Your Repositories
bash
# Remove malicious workflow if present
rm -f .github/workflows/shai-hulud-workflow.yml# Check for unauthorized package.json modifications
git log -p package.json# Audit your npm publish history
npm view <your-package-name> time
For StepSecurity Enterprise Customers
The following steps are applicable only for StepSecurity enterprise customers. If you are not an existing enterprise customer, you can start our 14 day free trial by installing the StepSecurity GitHub App to complete the following recovery step.
Use NPM Package Cooldown Check
The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.
Here is an example showing how this check protected a project from using the compromised versions of packages involved in this incident:
https://github.com/step-security/test-reporting/pull/16/checks?check_run_id=49850926488

Discover Pull Requests upgrading to compromised npm packages
We have added a new control specifically to detect pull requests that upgraded to these compromised packages. You can find the new control on the StepSecurity dashboard.
Use StepSecurity Harden-Runner to detect compromised dependencies in CI/CD
StepSecurity Harden-Runner adds runtime security monitoring to your GitHub Actions workflows, providing visibility into network calls, file system changes, and process executions during CI/CD runs. Harden-Runner detects the compromised nx packages when they are used in CI/CD. Here is a sample Harden-Runner insights page demonstrating this detection:

If you're already using Harden-Runner, we strongly recommend you review recent anomaly detections in your Harden-Runner dashboard. You can get started with Harden-Runner by following the guide at https://docs.stepsecurity.io/harden-runner.
Use StepSecurity Artifact Monitor to detect software releases outside of authorized pipelines
StepSecurity Artifact Monitor provides real-time detection of unauthorized package releases by continuously monitoring your artifacts across package registries. This tool would have flagged this incident by detecting that the compromised versions were published outside of the project's authorized CI/CD pipeline. The monitor tracks release patterns, verifies provenance, and alerts teams when packages are published through unusual channels or from unexpected locations. By implementing Artifact Monitor, organizations can catch supply chain compromises within minutes rather than hours or days, significantly reducing the window of exposure to malicious packages.

Learn more about implementing Artifact Monitor in your security workflow at https://docs.stepsecurity.io/artifact-monitor.