Sandworm in the supply chain: Lessons from the Shai-Hulud npm attack on developer and machine identities

September 24, 2025 Andy Thompson

Digital sandworm tunneling through code and npm package icons, symbolizing the Shai-Hulud supply chain attack on developer and machine identities.

Do you know why Shai-Hulud should raise your hackles? Unless you’ve spent time on Arrakis in Frank Herbert’s Dune or the npm ecosystem this month, the name Shai-Hulud might not ring a bell. In Herbert’s world, Shai-Hulud is the colossal sandworm of Arrakis—feared, powerful, and destructive. In our world, I guess you could say the same thing.

Shai-Hulud surfaced as a malware worm that tore through the npm software registry on Sept. 16–17, 2025. Like its literary namesake, burrowing unseen, this worm tunneled into the supply chain, stealing developer credentials, API keys, and sensitive tokens. Attacks on package managers like npm, Homebrew, Yum, Chocolatey, and others are nothing new.

What separates this incident from all other recent attacks is that this attack spread in a way that upends the very trust model that global software development depends on—identities. For developers and enterprises alike, the fallout isn’t just disruptive; it’s devastating.

Attackers compromised over 500 npm packages in this attack, including massively popular libraries and some tied to cybersecurity vendors. The actual blast radius extended much further, impacting organizations consuming npm at scale in continuous integration and continuous delivery (CI/CD) pipelines and internal apps.

Shai-Hulud isn’t your garden‑variety malware; it’s a self-propagating worm. Once installed, it steals sensitive data (credentials, tokens, keys) and then weaponizes its victims in real time, forcing compromised developers to push malicious updates to their own software packages.

This incident is a perfect case study for identity security. Identities—both human (developer accounts) and machine (tokens, API keys) were the fuel. This post breaks down what happened, why it matters, and what we can learn from it.

Shai-Hulud isn’t just another supply-chain compromise—it’s identity security’s “perfect storm,” hitting human credentials, machine identities, and supply chain trust relationships all at once.

Now that you’re curious, let’s cut open this worm and dissect the breach! 🪱

TLDR: CyberArk’s identity‑centric approach can help keep your codebase threat actor-free.

Pull quote from blog: "Shai-Hulud isn’t just another supply-chain compromise—it’s identity security’s 'perfect storm,' hitting human credentials, machine identities, and supply chain trust relationships all at once." Visual emphasis on cybersecurity and supply chain attack theme.

What is the Shai-Hulud npm attack?

How the attack unfolded

Initial breach: npm maintainer accounts were compromised. The precise vector is unconfirmed, though phishing or stolen or reused tokens are most likely. This incident was separate from the Sept. 8 “chalk and debug compromise” (a crypto stealer) but shares tactics with the Aug. 27 Nx “s1ngularity” attack, in which attackers dumped secrets to GitHub. Researchers believe Nx and Shai-Hulud are likely related, while the “chalk and debug” incident appears unrelated.

Poisoned packages: With access to these highly privileged credentials, the attacker immediately pushed malicious updates. In one case, “@ctrl/[email protected]” carried a hidden payload (bundle.js), designed to execute quietly after install. bundle.js executed a multi-stage payload, including staging TruffleHog to scan the filesystem, environment variables, dotfiles, and cloud IMDS endpoints for secrets. It validated tokens (npm, GitHub, cloud) and then exfiltrated results. There is no evidence of raw memory scraping, but bundle.js aggressively harvested all secrets accessible to the runtime.

Data theft at scale: Stolen data was exfiltrated to a public GitHub repo (“Shai-Hulud”) and via a commonly used public webhook service. Because this service enforced request rate-limits, not all exfiltration attempts succeeded, which likely reduced the attackers’ yield. To persist beyond package cleanup, the malware also injected malicious GitHub Actions workflows into repos, ensuring continued secret leakage on future builds.

Notably, the worm was cross-OS compatible (Linux, macOS, Windows), enabling it to bridge the gap between developer endpoints and production build systems, amplifying supply chain impact.

Worm behavior: If it discovered an npm token, the malware didn’t stop at credential theft. It weaponized its victims into malware propagators, using their access to push backdoored versions of their own packages. The result was an exponential spread to more than 180 packages poisoned in under 24 hours. Beyond credential theft, the worm queried the top 20 packages owned by each maintainer and republished them with trojanized versions, enabling rapid worm-like propagation.

The impact: How Shai-Hulud affected the software supply chain

Shai-Hulud isn’t just a breach. It’s a direct hit to the trust fabric of open source identity security. Developers worldwide rely on npm as critical infrastructure, and Shai-Hulud shows how quickly attackers can weaponize that trust. In a single day, attackers siphoned secrets and corrupted packages, causing the blast radius to extend far beyond the initial victims.

How attackers gained access

No zero-days here. The attackers simply impersonated trusted maintainers. We don’t yet have definitive attribution or a public forensic timeline, and we may never see every detail. But we know from similar incidents that maintainer accounts are most often taken over using one of a handful of well-worn techniques.

The following are the probable vectors, along with the immediate defensive steps you should assume are necessary to protect against them:

  • Targeted phishing and spear-phishing. Attackers trick a maintainer into handing over credentials or approving an OAuth or token request.

Mitigation: Enforce phishing-resistant multi-factor authentication (MFA), such as hardware keys; limit sensitive operations to locked administrative windows, and train maintainers on link and attachment hygiene.

  • Exposed or leaked tokens (repository, CI logs, or public logs). Long-lived npm, GitHub, and API tokens accidentally checked into source code, CI logs, or public Gists are harvested and reused.

Mitigation: Treat tokens as machine identities—rotate frequently, require least privilege, and scan repos and CI output for secrets (block commits that leak secrets).

  • Credential stuffing and password reuse. Reused passwords from breaches enable attackers to log in as maintainers.

Mitigation: Enforce unique passwords via single sign-on (SSO) and enterprise identity with enforced MFA and block legacy password auth where possible.

  • Compromised developer workstation. Malware on a maintainer’s machine (or a compromised remote build agent) captures credentials, tokens, or session cookies.

Mitigation: Harden endpoints, isolate build agents, require dedicated signing or builder VMs, and use ephemeral keys generated per job.

  • Compromised third-party app or OAuth integration. A malicious or compromised CI, analytics, or integration app with permissions to publish or read secrets is abused.

Mitigation: Review and tighten app permissions, adopt OAuth consent review, and remove unused integrations.

  • CI/CD pipeline compromise. Poisoned build pipelines or stored credentials in pipeline variables are abused to sign and publish trojaned packages.

Mitigation: Lock down CI variables, use short-lived service principles, and require manual approval for production publishes.

  • Session or token replay or theft (insufficient token protection). Stolen session cookies or bearer tokens are replayed to authenticate as maintainers.

Mitigation: Use token binding, shorten token lifetimes, require re-authentication for sensitive ops, and monitor for anomalous token usage.

  • Social engineering and account recovery abuse. Employing a tried and true tactic used by threat actors such as Scattered Spider, attackers manipulate support channels or platform account recovery processes to gain control.

Mitigation: Harden recovery flows (out-of-band verification), restrict recovery via corporate SSO, and require secondary approvals.

  • Insider compromise or collusion. A legitimate account is knowingly or unknowingly used by a bad actor (phished colleague, malicious insider).

Mitigation: Apply least privilege, logging and alerting for unusual publish activity, and multi-party approvals for new releases.

Assume one or a combination of these techniques. That’s how a worm, able to publish packages at scale, gets its foothold.

Why the Shai-Hulud attack is a wake-up call for identity security

The Shai-Hulud incident is more than another entry in the long list of supply chain compromises. It highlights systemic identity risks that affect every developer and enterprise that relies on open source.

Why this one matters

Massive downstream impact: A single compromised maintainer cascaded into hundreds of poisoned packages, placing thousands of projects and their users at risk.

Stealthy delivery: No malicious links, no obvious red flags. Developers ran their usual npm install commands, unaware they were triggering the attack. The attackers used routine workflows to deliver their payload.

High-value targets: The malware harvested AWS access keys, GitHub tokens, and cloud API credentials. This isn’t just package hijacking. By stealing these credentials, the malware creates the potential for IP theft, supply chain infiltration, crypto mining operations, or broader cloud breaches.

The bigger picture: Identity security in the software supply chain

Modern software development is a deeply interconnected ecosystem. When one maintainer’s account is compromised, the blast radius extends far beyond the individual. It impacts entire organizations and industries downstream. Shai-Hulud wasn’t just an opportunistic smash-and-grab malware. It was a calculated credential harvester, designed to weaponize trust at scale.

Real-world scenario

To illustrate just how quickly a supply chain attack like Shai-Hulud can escalate, let’s walk through a hypothetical—but entirely plausible—scenario. Imagine this unfolding inside a typical organization; let’s call it Sandroot Industries (a fictional company):

  • A developer runs a routine update to ngx-toastr, unknowingly pulling in a trojaned version seeded with Shai-Hulud.
  • The hidden payload quietly harvests a GitHub personal access token and an AWS IAM key left in a local configuration file.
  • Those secrets are exfiltrated to a public repo accessed by the attacker.
  • At the same time, the worm uses the stolen npm token to push malicious updates into Sandroot Industries’ internal packages, infecting other developers across the organization.

A simple, everyday dependency update triggers all of this. No red flags. No warning banners. Just business as usual—until the worm surfaces. 🪱

Identity security breakdown: Lessons from the Shai-Hulud attack

When the headlines about Shai-Hulud first broke, I felt genuine shock. Few breaches have so clearly illustrated how identity security principles apply across every layer of the software supply chain. As we pieced together the details, it became obvious that attackers exploited weaknesses in three key areas: human, machine, and software identities. Here’s how those risks play out in practice:

Human identities

  • Enforcing unique passwords via SSO and enterprise identity
  • Using MFA (preferably phishing-resistant, like FIDO2 keys) to prevent attackers from compromising maintainer accounts
  • Monitoring behavior to catch anomalies (like one account suddenly publishing dozens of updates)

Machine identities

  • Securing tokens, API keys, and cloud creds that are prime targets
  • Vaulting secrets and making them short-lived to leave attackers empty‑handed
  • Monitoring unusual key usage (odd locations, 2 a.m. cloud activity)

Software identities

Today, we mostly “trust the repo.” But package signing (think Sigstore and Cosign) could help prove a release is legitimate.

Defense in layers: Protecting against supply chain attacks

Addressing these identity risks requires a layered defense. Here’s how you can put these principles into action and fight the worm:

1. Secure developer accounts

  • Use unique passwords via SSO or enterprise identity with enforced MFA
  • Train developers against phishing lures
  • Monitor for account anomalies

2. Lockdown secrets

  • Mandate vault credentials
  • Rotate keys frequently
  • Apply least privilege to tokens

3. Harden CI/CD

  • Protect build agents like production servers
  • Audit workflows for weak spots
  • Use signed actions and require reviews

4. Manage dependencies

  • Proxy packages through an internal repo (Artifactory, Nexus)
  • Scan new dependencies for shady behavior
  • Keep a software bill of materials (SBOM) handy

5. Plan for supply chain incident response

  • Build playbooks for compromised dependencies
  • Rotate secrets fast when in doubt
  • Use threat intel feeds for early warnings

6. Maintain Zero Trust dev environments

  • Reduce the blast radius by leaning in on containers, sandboxes, and remote environments

Best practices for defending against npm supply chain attacks

  • Enable two-factor authentication (2FA) on all package accounts
  • Use unique passwords—NO REUSE, no excuses.
  • Keep secrets out of code or config files
  • Segment development, build, and production environments
  • Subscribe to advisories; know your dependencies
  • Run incident drills—it’s better to practice how you fight.

The path forward for identity-first supply chain security

Shai-Hulud reminds us that identity is now the last-standing perimeter and the most critical attack vector to protect. Attackers exploited developer identities and machine secrets to worm their way into the supply chain. We, as defenders, must adapt by adopting and implementing identity security controls. With strong identity security, least privilege, vaulting, monitoring, and solutions like CyberArk’s Identity Security portfolio, defenders can make life much harder for attackers.

Supply chain threats can feel daunting, but breaking the problem into identity-centric layers can make it manageable—and even preventable. Just as the technical community united to stop Shai-Hulud’s spread, organizations can fortify their defenses, so the next worm doesn’t burrow unchecked.

Remember: it’s not “Can we trust this code?” but “How do we trust and verify the identity of every user, every commit, and every secret?” Shine light into the tunnels, and the worms stay underground.

Andy Thompson is a senior offensive research evangelist at CyberArk Labs.

Ready to assess your organization’s exposure?

Try CyberArk’s free scan for machine identities across AWS, Azure, Google Cloud, and HashiCorp Vaults.

No Previous Articles

Next Article
Cheaters never win: large-scale campaign targets gamers who cheat with StealC and cryptojacking
Cheaters never win: large-scale campaign targets gamers who cheat with StealC and cryptojacking

A sprawling cyber campaign is turning gamers’ hunger to gain an edge into a massive payday for threat actor...