Inside the Shai‑Hulud NPM Supply Chain Attack

On September 14, the JavaScript ecosystem was rocked by a massive npm 2.0 supply-chain attack. Security researchers are calling it one of the largest malware incidents ever to hit the npm registry.

Source: https://x.com/ReversingLabs/status/1967576545838694497 

TL;DR: What made “Shai-Hulud Attack” different

• Self-spreading worm: The malware (nicknamed after the Dune sandworm) compromised 180+ open-source packages across multiple maintainers and kept spreading using stolen credentials.

• Automatic propagation: Once inside a developer machine or CI, it harvested secrets and used them to publish more trojanized packages, turning the registry into a “trojan factory.”

• High-profile impact: Popular public libraries (e.g., a color utility with ~8M+ monthly downloads) and internal packages from reputable companies were affected.

• Credential theft at scale: NPM/GitHub tokens, API keys, and cloud creds were exfiltrated, enabling further compromise.

• Ecosystem-level risk: A single tainted dependency rippled across projects with unusual speed and reach.

In this deep dive, we’ll break down:

• How the Shai-Hulud npm supply-chain attack unfolded step by step.

• Who was impacted and what was exposed.

• Immediate and long-term actions engineering and security teams should take to mitigate damage.

• Practical steps to fortify your software supply chain against future “npm 2.0”-style threats.

How the Shai-Hulud npm 2.0 Attack Unfolded

Researchers traced “patient zero” to an npm user named techsupportrxnt, whose package rxnt-authentication was published with a malicious payload on September 14, 2025. The worm began with the compromise of a single maintainer’s npm account (likely through stolen credentials) and used that access to push a trojanized update.

Figure 1: Shai-Hulud npm Worm Timeline

Automatic execution: Once any infected package was installed by a developer or CI server, the malware executed immediately via a post-install script (a 3MB+ bundle.js) embedded in the package.

Aggressive secret harvesting: This script searched local machines and CI environments for secrets, npm authentication tokens, GitHub personal access tokens, API keys, and cloud credentials (AWS, GCP, etc.). To accelerate scanning, it even repurposed a legitimate secret-scanning tool, TruffleHog, to comb file systems and environments for sensitive keys.

Exfiltration & persistence: Stolen credentials were sent to an attacker-controlled server and a public GitHub repository named “Shai-Hulud,” which contained encoded data.json files of stolen secrets. It also implanted a malicious GitHub Actions workflow into victims’ repositories to persist beyond the initial infection, triggering on future CI runs to exfiltrate new secrets.

Exposure of private code: The malware attempted to make public copies of private repositories by appending “-migration” to repo names, likely to expose hardcoded secrets hidden in private codebases.

Self-propagation. With stolen npm publish tokens, the worm automatically:

• downloaded the next package tarball,

• injected the payload,

• bumped version, and

• Republished, compromising additional packages under affected scopes/orgs.

High-profile packages quickly became victims: the popular color library @ctrl/tinycolor, packages under the @nativescript-community namespace, multiple Angular/Ngx libraries, and even plugins under the @crowdstrike scope. By exploiting developer trust and automated publishing, Shai-Hulud turned the npm supply chain into a “trojan factory,” its code would download the next package tarball, inject malware, bump the version, and republish, compromising new projects in a loop.

Why this was new? This wasn’t a one-off backdoor. It was a worm that used the ecosystem’s automation to spread.

Figure 2: Worm Propagation

Now let’s look at the impact, which developers, packages, and organizations were caught in its net, and what security teams must do next.

Scope and Impact

Within ~24 hours of discovery, 187+ packages were flagged; subsequent analysis points to hundreds affected.

Who/what was hit (examples)

Figure 3: Hundreds of Packages, Millions at Risk

1. High-profile victims: These weren’t obscure libraries. Popular tools across frontend and backend were hit. For example:

• ngx-bootstrap (Angular UI library, ~300,000 weekly downloads)

• ng2-file-upload (100,000 weekly downloads)

• @ctrl/tinycolor (2+ million weekly downloads)

• Other packages in the @ctrl scope (Angular utilities, torrent clients, etc.)
  Any one of these could have silently introduced malicious code into countless projects.

2. Enterprise developer accounts targeted: Even security-savvy organizations weren’t immune. An npm account associated with CrowdStrike was used to push contaminated updates for a dozen @crowdstrike/* packages (mostly internal tools and config libraries). CrowdStrike confirmed it removed the packages and rotated keys immediately, and that these packages were not used in its flagship products. But it underscores a hard truth: if the supply chain is compromised, nobody is automatically safe.

Who was directly at risk? End-users were typically indirectly impacted. The primary targets were developers and CI systems during install/build. Any machine that ran npm install on malicious versions during the window may have had secrets stolen.

Why it matters: With stolen GitHub tokens, attackers could access private source code or plant malicious commits. With stolen cloud keys, they could probe infrastructure and data. With npm publish tokens, they could push trojanized updates under a maintainer’s name. This “cascading compromise” makes it nearly impossible to predict the full spread given npm’s dense web of interdependencies.

3. Security industry verdict:

• ReversingLabs called Shai-Hulud the “first self-replicating worm” in the npm ecosystem.

• Wiz labeled it “one of the most severe JavaScript supply-chain attacks observed to date.”

• Analysts noted it appears to have evolved from earlier incidents, like the August 2025 “s1ngularity” breach and the early September compromise of chalk and debug (2+ billion weekly downloads combined), but at a much larger, automated scale.

In short, Shai-Hulud proved that one phished maintainer can instantly turn into an attack vector for thousands of downstream apps, and that automation can supercharge the spread.

Faced with such a fast-moving and invasive supply-chain worm, what should organizations do immediately if they suspect exposure? 

Immediate Steps for Affected Teams

If your organization uses Node.js or npm packages, now is the time to verify whether the Shai-Hulud supply-chain worm has touched your codebase. Even if you weren’t directly affected, treat this as a fire-drill for software supply-chain security. 

Here’s a prioritized checklist for engineering leaders and security teams:

1. Identify and Remove Malicious Packages

• Audit all dependencies, including transitive ones – to check if any compromised npm package versions slipped into your environments.

• Use tools such as npm audit, software composition analysis (SCA) platforms, or your internal vulnerability scanners to detect tainted versions.

• Pay special attention to builds or deployments between September 14–16, 2025 (the attack window).

• If you find any bad versions, remove them from node_modules, clear the npm cache, and reinstall using known safe releases (pin to the last clean version before the malicious update).

• Although many of the trojanized versions have been unpublished from npm, remain vigilant, attackers may have uploaded multiple bad versions in a row.

2. Isolate and Rebuild Potentially Compromised Systems

• Treat any developer machine or CI runner that installed tainted packages as potentially compromised.

• At minimum, disconnect those systems and avoid using any credentials stored on them until sanitized.

• Ideally, perform a clean rebuild of CI containers or reimage developer workstations to eliminate lingering malware (remember, the worm may have created persistent GitHub Actions workflows or other implants).

3. Revoke and Rotate Credentials Immediately

• Assume any tokens or keys present in a compromised environment were stolen.

• Revoke npm tokens, GitHub personal access tokens, SSH keys, cloud provider keys, and CI secrets.

• Generate fresh keys and update them in your secure stores.

• This step cuts off attackers’ access and prevents them from publishing new malware using a stolen npm token. (CrowdStrike proactively rotated all keys even though its main products weren’t impacted.)

4. Check for Indicators of Compromise (IoCs)

• Search your GitHub org and developers’ personal accounts for telltale signs of Shai-Hulud:

  • Any repository named “Shai-Hulud”

  • Any repo or branch with “-migration” in its name or description

• Review GitHub audit logs for suspicious behavior, such as unexpected repo creation or OAuth token use.

• Check your npm account logs for unauthorized package publications or login attempts around that time.

5. Analyze Logs for Exfiltration

• If you have network monitoring, look for outgoing requests to the webhook.site domain (used by the attackers as a drop point).

• The malware also triggered GitHub API calls to create new repos; watch for such traffic patterns.

• If you discover a rogue data.json in any “Shai-Hulud” repo, decode it from base64 to see what credentials or data might have been leaked.

6. Inform Stakeholders Promptly

• If your organization was impacted, loop in your security team and activate your incident response plan.

• Notify customers or partners if there’s any chance your software releases were affected.

• Transparency is key: if you maintain a library that others depend on, and your account was breached, disclose promptly so downstream users can respond.

• NPM’s security team and the wider open-source community have been quick to act, coordinate with them for package status updates or assistance.

Once the immediate fire is contained, the crucial question for engineering leaders is how to prevent a Shai-Hulud-style incident from happening to you. Let’s outline strategies to build resilience against future supply-chain threats.

Secure Your Software Pipeline Against the Next Attack

“Hope is not a strategy” is especially true for npm supply-chain security. After witnessing both the September 8 phishing-based npm attack and the September 16 Shai-Hulud worm, it’s clear no team can assume their software pipeline is safe by default. Below are key measures, spanning people, process, and technology, to strengthen your defenses.

1. Harden Developer Accounts and Credentials

• Enforce 2FA everywhere. Every npm maintainer account and GitHub account in your org should require strong two-factor authentication. Prefer hardware security keys or WebAuthn over SMS or authenticator apps. Phishing can steal one-time codes, but not a hardware key. 

• Educate your team on phishing. Make sure no one enters credentials or 2FA codes into suspicious links. The “qix” maintainer was compromised by a look-alike domain (npmjs.help) that bypassed his OTP 2FA, hardware keys would have blocked it.

• Use least-privilege tokens. Audit your automation tokens and API keys. Don’t use a broadly scoped npm token on a CI runner that only needs to install packages, use read-only or CIDR-restricted tokens where possible. Segment publishing credentials so compromise of one project doesn’t grant rights to all. Short-lived tokens further reduce risk.

• Rotate secrets regularly. Implement time- or event-based rotation for CI secrets and access keys. Even if something was stolen silently, it may expire before attackers can use it. Moving toward “secretless CI/CD” (e.g., ephemeral OpenID Connect tokens for cloud deployments) also reduces exposure.

2. Tighten Software Composition Practices

• Treat dependencies as untrusted code. Every npm package you install executes with your application’s privileges. Adopt a zero-trust stance for new packages or updates. Before pulling in a new open-source library, do a quick risk review: who maintains it, is the maintainer active, has it had malicious releases?

• Add approval steps. Require a senior engineer’s review for PRs that add or bump dependencies, especially high-impact packages. An unexpected minor version release to a stable library could be a red flag.

• Pin and lock dependencies. Use exact version pins or lockfiles to avoid auto-upgrading to compromised versions. Many teams use lockfiles and manual update processes for precisely this reason.

• Disable post-install scripts where possible. In CI, consider running npm install --ignore-scripts to block postinstall scripts by default. This would have stopped Shai-Hulud’s payload from executing on build machines. Maintain an allow-list for packages that truly need install scripts.

• Monitor dependency releases. Watch for unusual activity, e.g., a flurry of new releases or a maintainer change. Some organizations implement a “cool-down period” (24–48 hours) before adopting new versions so the community can flag malicious updates first.

3. Strengthen CI/CD Pipeline Security

• Lock down build environments. CI/CD runners should operate with “minimal necessary access.” Don’t grant build jobs access to high-value secrets unless absolutely required. Segment roles for publishing, testing, and deploying. Consider running builds in isolated network sandboxes and block outgoing internet access except to known registries, this can stop malware from phoning home.

• Add integrity checks. Enable npm’s built-in integrity verification (sha512 hashes in package-lock.json) and consider PGP signatures or Sigstore as they become available. In the long run, adopting frameworks like SLSA (Supply Chain Levels for Software Artifacts) helps ensure provenance and integrity.

• Continuously monitor builds. Implement alerts for unusual behavior. For example, if a build process that normally runs tests suddenly creates outbound network connections or new workflow files, trigger an alarm. Some teams plant Canary tokens or dummy secrets in build environments, if a tool like TruffleHog tries to exfiltrate them, you know you’ve been breached.

4. Invest in Supply-Chain Security Tooling

• Maintain an SBOM and use SCA. Keep an up-to-date Software Bill of Materials (SBOM) for your applications. Modern Software Composition Analysis (SCA) tools can flag known malicious packages or anomalous behavior in near real time. During Shai-Hulud, vendors like Socket and Semgrep updated their rules quickly; automated SCA in your CI/IDE could warn you “this version of tinycolor is potentially malicious” as soon as someone tries to install it.

• Centralize dependency management. Funnel package installs through an internal proxy or artifact registry so you can yank a malicious version across the org instantly and enforce policies (e.g., no installs of unpublished versions, allow-lists/deny-lists). This is essentially a “package firewall” for npm.

• Use automated code review and analysis. Pair human reviews with AI-powered platforms that analyze code and dependencies for quality, security, and compliance issues. For example, CodeAnt.ai acts as an intelligent second set of eyes on every pull request, flagging dangerous patterns or suspicious changes (like a 3 MB obfuscated script in a minor update) that human reviewers might miss. Because CodeAnt understands context, it reduces false alarms and can differentiate legitimate large changes from truly anomalous insertions. It also offers one-click fixes and engineering metrics (including DORA metrics, outdated dependencies, or bypassed policies) so leaders can see both code health and team trends at a glance. 

Hardening your pipeline isn’t a one-time exercise; it’s an ongoing process of people, process, and tooling. By combining basic hygiene (2FA, least privilege, dependency pins) with advanced supply-chain security and AI-powered code reviews, organizations can dramatically reduce the risk of the next Shai-Hulud. In the next section, we’ll show how to operationalize these practices into day-to-day development so they become habits, not exceptions.

From Reaction to Prevention, Securing Your npm Supply Chain

The recent npm supply chain attacks have made one thing crystal clear: software supply-chain security is no longer a niche concern; it’s a board-level issue. Trusted tools, registries, and workflows can be subverted overnight, whether by phishing a maintainer or infecting a build pipeline.

To protect your organization:

• Implement the immediate steps first

• Drive longer-term initiatives

• Use automation defensively

One example is CodeAnt AI, that unifies code quality, security, and compliance intelligence. Instead of just scanning code, CodeAnt AI:

• Contextually reviews pull requests and flags anomalies (like obfuscated scripts or suspicious new workflows) before they land.

• Provides one-click fixes and detailed metrics so developers can act immediately without slowing velocity.

• Gives engineering leaders visibility into outdated dependencies, security trends, and team performance, all from one dashboard.

By combining proven best practices with platforms like CodeAnt AI, you can:

• Ship code at high velocity while ensuring every change is vetted against a knowledge base of security and compliance rules.

• Gain continuous visibility into your engineering process and supply chain risk.

• Make security improvements scalable and repeatable rather than one-off reactions.

Take action today:

• Review your exposure to the Shai-Hulud attack window.

• Implement the best practices above to harden your npm supply chain.

• Evaluate CodeAnt AI or a similar AI-powered code review platform to institutionalize these defenses.

Your developers, and your customers, will thank you when your products stay both innovative and secure in the face of an evolving threat landscape. Try CodeAnt AI today!!!

The sandworms may be burrowing, but with robust guardrails and smart automation, your software factory can stay safe.

Appendix: Known Compromised Packages (IoCs)

The following IoCs were collected as part of RL’s investigation of this campaign.