Shai-Hulud – npm’s Latest Supply Chain Breach: @ctrl/tinycolor and 526+ Packages, including CrowdStrike. What Actually Happened and How to Recover with ASPM?

TL;DR for engineering teams

• Another supply chain and npm maintainer were compromised after the QIX compromise.
• The campaign, named Shai-Hulud, continues to target TinyColor and now CrowdStrike npm packages.
• Another account, following the pattern campaign on npm, has been compromised. 
• The malware is identical to the tinycolor malware, which includes a bundle.js script that:
  • Downloads and executes TruffleHog, a legitimate secret scanner
  • Searches host systems for tokens and cloud credentials
  • Validates discovered developer and CI credentials
  • Creates unauthorized GitHub Actions workflows within repositories
  • Exfiltrates sensitive data to a hardcoded webhook endpoint

• Do not install @ctrl/tinycolor@4.1.1 or @4.1.2 (and avoid any dependency graph that resolves to them). The same campaign hit 40-74+ other packages (full list below).
• The malware uses a self-propagating function (NpmModule.updatePackage) to grab maintainer packages, inject a Webpack-bundled bundle.js, repack, and republish—creating a blast radius across maintainers and dependents.
• The payload pulls down TruffleHog, hunts for GITHUB_TOKEN, NPM_TOKEN, AWS/GCP/Azure credentials, validates tokens (npm whoami), hits GitHub APIs, writes a persistence GitHub Actions workflow that exfiltrates secrets to webhook[.]site, and can persist in CI even after the original host is clean. IoCs and exfil link below.
• Initial alert attribution includes Daniel dos Santos Pereira and community triage; Socket and StepSecurity published detailed breakdowns and IoCs.
• Rotate tokens, rip out the backdoor workflow, scan repos/org for Shai-Hulud branch and workflow, audit your clouds’ secret access, and lock down publish paths. Guidance and commands included.
• Thanks to Daniel Pereira for the initial alert:

Update 19 September

• New Indicator of Compromise 23 New libraries affected, bringing the total to 526 libraries,
• Script updated to include detection

Update 18 September

• New Indicator of Compromise 27 New libraries affected, bringing the total to 504 libraries,
• Script updated, plus integration with Phoenix

Update 17 September

• The number of libraries affected has increased from 40-74 to 477+

What was compromised, and how it spread

This was not a one-off malicious post-install. It’s a small supply-chain engine:

1. Trojanization pipeline
   The attacker’s code downloads a package tarball, modifies package.json, injects a local bundle.js, repacks, and republishes. That updatePackage function automates the spread across a maintainer’s other packages, weaponizing maintainer trust at scale.
   
2. Execution vector
   The minified bundle.js (≈3.6MB) runs during install. It fingerprints the OS, pulls a matching TruffleHog binary, and starts secret harvesting. The code validates npm auth via /-/whoami, calls GitHub REST if a token is present, and probes cloud metadata endpoints used by build agents.
   
3. Persistence and exfiltration
   If GitHub access is available, the script writes a workflow at .github/workflows/shai-hulud-workflow.yml. That workflow serializes secrets and posts to a webhook[.]site endpoint. Once committed, secrets can leak from future CI runs even if the developer’s laptop is clean. IoC hash and exfil URL are fixed.
   
4. Scope and blast radius
   @ctrl/tinycolor counted ~2M weekly downloads and is just one node in the set. The same campaign hit multiple maintainers and org scopes, including CrowdStrike-scoped packages and a swath of @ctrl/* modules. 
   

How to verify packages:

Launch our quick check tool:

python3 npm_compromise_detector.py ‘/path/to/your/project’ –output security-audit.txt –check-cache –full-tree –show-locations

How to Check if You Are Affected by Shaia Hulud and verify in Phoenix Security:

If you are a Phoenix Security client, verify your SBOM dependencies from 3rd party of from Phoenix Security Scanner:

• SBOM Screen: Verify the main packages
• https://YOURDOMAIN/app/external-dependencies/libraries?q=eJyrrgUAAXUA%2BQ%3D%3D 

How to remediate / Prevention measures against Shaia Hulud NPM campaigns and follow-up

Attack surface is expanding, and developers distributed across an organization is the worst recipe for NPM attacks like this. Following a list of steps to consider to prevent this attack from spreading

Key suggestions

• Pin Dependencies. Avoid auto update, pin dependencies
• Prevent direct access/ update from NPM or other package managers (see below) 
• Prevent unvetted updates using a proxy

To respond and be prepared to Shaia Hulud and other NPM source package attacks, follow the quick recommendation. For detailed guidelines, check npm-shai-hulud-supply-chain-compromise-explained

To defend against npm supply chain attacks and recover fast when incidents strike, adopt these practices:

• Lock & Pin Dependencies – Use package-lock.json/pnpm-lock.yaml with npm ci (not npm install) and set save-exact=true in .npmrc.
• Proxy & Sanitize – Route all installs through an internal package manager proxy (e.g., Nexus/Artifactory) that caches and sanitizes approved versions.
• Restrict Registry Access – Temporarily block direct access to npm when an active campaign is underway, forcing developers to pull only vetted packages.
• Detect & Monitor – Integrate SCA + malware scanning in CI/CD to catch compromised dependencies early, with reachability analysis to reduce noise.
• Delay Adoption – Apply a “cooldown period” (e.g., 60 days for new packages) before trusting fresh releases.
• Reduce Bloat – Eliminate unused or duplicate libraries, and leverage reachability analysis to prune non-critical dependencies.
• Recovery Playbook: Responding to a Compromise
  • Isolate & Identify: Freeze deployments and check lockfiles against compromised versions.
  • Eradicate & Clean: Remove malicious packages, update to safe versions, purge caches, and commit fresh lockfiles.
  • Rotate All Credentials: Reset every token and secret used in CI/CD (GitHub, npm, cloud keys).
  • Audit for Persistence: Hunt for backdoors (e.g., malicious workflows) and remove them before resuming operations.

Packages confirmed in this campaign

Do not install @ctrl/tinycolor@4.1.1+ (or any resolver path that selects those versions) until you’ve verified provenance. The maintainer account scttcper is the publisher for many of the affected @ctrl/* and Angular packages; treat any recent publishes with extreme caution while provenance is established.  

Refer to the full analysis of Shaia Hulud for full analysis and details on the waves.

The payload under the microscope

Stage 1: Recon and environment sweep

• OS/arch profile using os.platform() and os.arch() to tailor a TruffleHog download.
  
• Env dump to harvest any exported credentials: GITHUB_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, cloud CLI creds, and CI secrets that occasionally leak into runner envs.
  

Stage 2: Secrets harvesting

• Local filesystem scan: invokes TruffleHog as a child process (filesystem / –json) to trawl for high-entropy secrets across developer machines or CI agents.
  
• Cloud secret managers: enumerates AWS Secrets Manager and GCP Secret Manager, with pagination and silent error handling. This is notable—many “npm malware” strains stop at environment variables; this one reaches into managed secret stores if credentials are present.
  

Stage 3: Token validation and lateral reach

• npm identity: /-/whoami used to confirm token validity, then the code pivots to maintainer package discovery via registry search.
  
• GitHub reach: if a token exists, calls /user and repo APIs, plants a workflow, and creates branches to persist the backdoor beyond the original host.
  

Stage 4: Persistence via GitHub Actions

• Workflow path: .github/workflows/shai-hulud-workflow.yml.
  
• Function: serialize secrets, double- or triple-base64 content, and POST to a webhook[.]site collector.
  
• Risk: once committed, any future CI run leaks secrets again. Token rotation alone won’t save you unless you also remove the workflow and force a clean history.

Indicators of Compromise (IoCs)

• Malicious file: bundle.js
  
  SHA-256: 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
• 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09 
• de0e25a3e6c1e1e5998b306b7141b3dc4c0088da9d7bb47c1c00c91e6e4f85d6
• 81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
• 83a650ce44b2a9854802a7fb4c202877815274c129af49e6c2d1d5d5d55c501e
• 4b2399646573bb737c4969563303d8ee2e9ddbd1b271f1ca9e35ea78062538db
• dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c
• 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
• b74caeaa75e077c99f7d44f46daaf9796a3be43ecf24f2a1fd381844669da777
  
• Backdoor workflow: .github/workflows/shai-hulud-workflow.yml
  
• C2 / exfil: https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 (defang if sharing internally).
  
• Suspicious behaviors: npm publish –force, TruffleHog invocation filesystem / –json, npm registry maintainer search (/v1/search?text=maintainer:), GitHub repo and contents writes, secretsmanager API calls. (link to Socket)
  

Immediate response playbook (copy/paste friendly)

1) Hunt and eradicate the packages

# Check for affected packages (example: tinycolor)

npm ls @ctrl/tinycolor

# Force remove compromised versions (replace with your offenders)

npm uninstall @ctrl/tinycolor

npm cache verify

Cross-check your lockfiles for any of the versions listed above; pin to known-good releases and re-vendor locks.

Note that this checks only first-level dependencies

2) Remove the GitHub Actions backdoor

# From each repo’s root

rm -f .github/workflows/shai-hulud-workflow.yml

# Look for a lingering branch across all repos in an org

gh repo list YOUR_ORG –limit 1000 –json nameWithOwner –jq ‘.[].nameWithOwner’ \

| while read repo; do

  gh api “repos/$repo/branches” –jq ‘.[] | select(.name == “shai-hulud”) | “‘$repo’ has branch: ” + .name’

done

# If found, delete it

git push origin –delete shai-hulud

The persistence risk sits in CI. Scrub workflow files in all repos, including forks and archived projects where secrets still live.

3) Rotate credentials with blast-radius thinking

• GitHub: personal access tokens, Actions secrets (org, env, repo), deploy keys, OAuth app grants.
  
• npm: automation tokens and publish tokens—replace ~/.npmrc everywhere.
  
• Cloud: AWS IAM keys, GCP SA keys, Azure SP credentials; regenerate and scope tightly.
  
• Secret stores: rotate values in AWS Secrets Manager and GCP Secret Manager that were accessed during the window.
  

4) Audit logs for exploitation

• AWS CloudTrail (examples):
  

aws cloudtrail lookup-events –lookup-attributes AttributeKey=EventName,AttributeValue=ListSecrets

aws cloudtrail lookup-events –lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue

• GCP Audit Logs:
  

gcloud logging read ‘resource.type=secretmanager.googleapis.com’ –limit=200

gcloud logging read ‘protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey’ –limit=50

5) Network containment

• Block outbound to webhook.site at your egress controls and proxy. Search historical logs for requests to the exact exfil URL.
  

DevSecOps guardrails that actually change outcomes

This campaign rode on two realities: trust in maintainer updates and permissive publish paths. You can blunt both.

Package intake discipline for npm

• Adopt a cooldown: delay brand-new package versions by 48–72h in pipelines. Most malicious releases get caught inside a day. StepSecurity’s Package Cooldown Check automates this gate. pnpm added a minimumReleaseAge setting for the same reason; similar features exist in Taze/NCU workflows.
  
• Artifact provenance: require provenance/SLSA attestations where available; block un-attested publishes in CI.
  
• Lockfile policy: single owner for dependency updates, reproducible builders, and a rule that no production deploy occurs within the same PR that bumps a critical transitive unless a security exception is signed.
  

Publisher and registry hygiene

• Publisher hardening: enforce hardware-backed 2FA for maintainer accounts; don’t reuse SSO providers or email factors; monitor for 2FA reset phish across corporate mail.
  
• Automated anomaly detection: watch for publishes that do not originate from your authorized CI/CD. Tools like StepSecurity Artifact Monitor or equivalent homegrown checks can flag “hand-pushed” packages.
  

GitHub Actions blast-radius controls

• Mandatory review for workflow changes (workflow file-path protections + CODEOWNERS).
  
• Untrusted code path: run npm install of untrusted branches on isolated runners with no org secrets; prefer job-level permissions: that default to read-all.
  
• Secret minimalism: removed or masked secrets by default; use OIDC with constrained audience/claims over long-lived PATs.
  

Build agent hardening

• Egress filters for runners; e.g., block webhook.site and similar pastebins.
  
• Read-only tokens where possible; ephemeral tokens everywhere else.
  
• Filesystem risk: developer laptops and CI hosts often hold .npmrc, .aws/credentials, and ~/.git-credentials. Treat them as secrets vaults; disk encryption and agent isolation aren’t “nice to have”.
  

How ASPM helps you get ahead of the next one

You can’t win this with scanners alone. You need continuous context:

• Unified risk view across code → pipeline → runtime
  Map where each dependency lands, which pipelines can publish, what secrets live in those pipelines, and which apps inherit those risks. That’s ASPM territory: one backlog per team, dedupe by context, and focus remediation where reachability and blast radius intersect.
  
• Reachability-aware dependency policy
  If a trojanized library is unreachable at runtime, don’t halt a release; if it’s reachable in critical paths, raise the gate. Tie this to your SCA/SBOM and CI policy so the decision is automatic.
  
• Provenance-based exceptions
  Write the rule once: only allow npm publishes signed by your CI service account with attested provenance; quarantine everything else. When the next attack drops, your policy blocks it by default while you investigate.
  
• Campaign-based remediation
  Treat this like a campaign: remove backdoor workflow, rotate tokens, re-pin affected versions, sweep org repos. Track it in your vulnerability management backlog as a single supply chain incident with child tasks per team—this reduces fatigue versus spraying dozens of tickets.
  

Triage checklist for security and platform teams

1. Inventory: generate a dependency SBOM and diff against the version list above.
   
2. Resolve: pin to safe versions; rebuild containers and serverless layers.
   
3. Pipelines: scan repos for .github/workflows/shai-hulud-workflow.yml; delete; force a clean commit that removes it; protect the workflows/ path.
   
4. Secrets: rotate npm, GitHub, cloud, and third-party tokens; re-issue OIDC workloads.
   
5. Forensics: search logs for webhook.site egress and CloudTrail/GCP Secret Manager access.
   
6. Comms: notify impacted developers; share detox steps for local machines (remove backdoor workflow clones, clear caches, re-auth CLI tools).
   
7. Policy: enable version cooldown and provenance gates in PR checks; require approvals for workflow changes.
   

Notes on maintainers and attribution

• The npm account scttcper (Scott Cooper) publishes many @ctrl/* libraries, including @ctrl/tinycolor. Treat any installs of recently published versions with care and verify the source timeline before unblocking.
  
• Initial alert: credits include Daniel dos Santos Pereira for flagging the suspicious @ctrl/tinycolor update; Socket and StepSecurity published deep dives and kept the package list current as the story evolved.
  

References and further reading

• StepSecurity: full technical breakdown, IoCs, remediation guidance for the bundle.js campaign.
  
• Socket Research: analysis of the tinycolor incident and Nx attack wave; lists affected versions and details on token validation, AI-assisted exfil in related incidents.
  
• The Hacker News: concise summary of the 40-package compromise with the fixed package list and exfil workflow details.
  
• npm maintainer profile (scttcper) for publisher context and recent publishes.
• Daniel Pereira for the initial alert
  

Final word: hold the line on package intake

Speed is the attacker’s ally here: release, wait for installs, drain secrets, and ride CI persistence. Slow them down. Bake cooldown, provenance, and workflow-path protections into your DevSecOps pipelines. Let your ASPM practice decide what gets blocked, what gets quarantined, and what needs a hotfix, based on reachability and blast radius.

Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.

Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM powered by AI-based Reachability Analysis

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues.

Why do people talk about Phoenix?

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication with reachability analysis: Utilizing canary token-based traceability for network reachability and static and dynamic runtime reachability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.