Shai Hulud 2.0 exposes how npm worm attacks amplify secret risk

At a glance

What this is: This is Cycode's analysis of Shai Hulud 2.0, a self-propagating npm supply chain attack that steals secrets, hides its execution, and expands exfiltration through public GitHub repositories.

Why it matters: It matters because npm package compromise can now become both a secrets incident and a CI/CD compromise, forcing IAM and NHI teams to treat developer tokens, cloud keys, and pipeline access as one linked attack surface.

By the numbers:

• Cycode reports more than 25,000 compromised GitHub repositories tied to the campaign's spread.
• Cycode says the attack has affected roughly 350 maintainers as it moved through the npm ecosystem.

👉 Read Cycode's analysis of Shai Hulud 2.0 and npm secret theft

Context

Shai Hulud 2.0 is a software supply chain attack that turns package trust into credential theft and repository abuse. The primary governance gap is the assumption that package installation, developer tokens, and CI/CD workflows can be monitored separately when attackers are using them as one continuous path into build and source code systems.

The identity dimension is real even though the entry point is software supply chain compromise. npm automation tokens, GitHub PATs, cloud credentials, and self-hosted runner access all behave like non-human identities once they can authenticate, exfiltrate, and republish without human oversight. That makes this a governance problem for IAM, PAM, and NHI control owners as much as for application security teams.

Cycode's description is more aggressive than a typical package malware case because it blends self-replication, secret harvesting, and destructive fallback behaviour. That combination is atypical in scale, but the underlying pattern of exposed developer credentials and over-trusted pipelines is already familiar.

Key questions

Q: What breaks when a malicious npm package can read developer secrets during install?

A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.

Q: Why do npm supply chain attacks create such a large blast radius?

A: Because install-time code can inherit access from developer laptops and CI runners, which often already hold cloud tokens, GitHub credentials, and automation secrets. One malicious dependency can therefore expose many non-human identities at once, and each identity may unlock more accounts, repositories, or secret stores.

Q: How do security teams know if exposed secrets are becoming a real risk?

A: The clearest signal is whether the secret can still authenticate and whether it can reach high-value actions after login. If a leaked key can enumerate resources, create identities, or modify policy, it is already a breach-enabling identity. Inventory alone is not enough unless revocation and scope reduction follow quickly.

Q: Who is accountable when a supply chain worm uses stolen tokens to create infrastructure?

A: Accountability sits with the teams that own software supply chain controls, CI/CD identity governance, and secrets lifecycle management. If a compromised token can create repositories or modify workflows, the issue is not only malware response. It is a governance failure across token scope, revocation speed, and build-system trust.

Technical breakdown

How npm package infection becomes credential access

The attack begins when a developer installs a compromised npm dependency and its post-install logic executes. In the earlier wave, the malware scanned for secrets such as API keys, cloud credentials, and npm or GitHub tokens. In Shai Hulud 2.0, the same basic entry path is paired with stealthier execution, including use of the Bun runtime to hide the core malicious logic. The technical point is that package trust becomes runtime code execution, and runtime code execution becomes credential discovery. Once a token is present on a workstation or in CI, the attacker no longer needs a vulnerability in the target application. Practical implication: treat package installation as a credential exposure event until proven otherwise.

Practical implication: monitor post-install activity and assume every developer token touched by the infected host may need rotation.

Why self-replication turns one compromise into many

This worm is designed to use stolen npm tokens to publish malicious versions of other packages owned by the victim, which turns a single compromised maintainer into a propagation point. The second version also raises the infection cap from 20 to 100 packages, making blast radius a function of token scope and package ownership rather than just the initial infection. Randomly named public GitHub repositories make the exfiltration channel harder to signature-match, which weakens detection models that depend on fixed names or hashes. For identity teams, the important architectural lesson is that publishing rights and repository write access are privileged non-human capabilities. Practical implication: constrain maintainer and automation token scope so one token cannot cascade across package namespaces.

Practical implication: segment package publishing rights and GitHub write permissions so one compromised credential cannot self-propagate.

What the fail-safe tells us about attacker intent

Shai Hulud 2.0 includes a destructive fail-safe that wipes the user's Home directory if authentication to GitHub or npm fails. That changes the incident from pure theft to dual-purpose sabotage, where the attacker wants both persistence and disruption. It also means defenders should not treat the campaign as a low-noise secret theft problem. The presence of destructive behaviour usually indicates the operator is willing to trade stealth for impact once containment begins. In practice, that raises the urgency of isolating affected endpoints, preserving evidence, and revoking credentials before the malware can pivot from exfiltration to destruction. Practical implication: build incident playbooks that assume both data theft and local system damage.

Practical implication: preserve host evidence first, then contain affected endpoints before the wipe logic can execute.

Threat narrative

Attacker objective: The attacker aims to steal high-value secrets, expand package compromise across the npm ecosystem, and preserve leverage through both exfiltration and destructive fallback behaviour.

1. Entry occurs through a compromised npm package installed by a developer or CI pipeline, which executes malicious post-install code.
2. Credential access follows when the malware scans the environment for API keys, cloud credentials, GitHub PATs, and npm automation tokens, then exfiltrates them to public repositories.
3. Escalation and propagation occur when stolen npm tokens are used to publish malicious package versions and spread the worm to additional maintainers and projects.
4. Impact includes repository exposure, credential compromise, and potential local destruction through the fail-safe that wipes the user's Home directory.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shai Hulud 2.0 is a credential governance failure, not just a malware event. The campaign succeeds because developer tokens, cloud keys, and package publishing rights are treated as separate control planes when they are really one trust chain. Once a compromised npm package can reach secrets, GitHub, and CI/CD in one flow, lifecycle controls become the deciding factor. Practitioners should manage these credentials as linked non-human identities rather than isolated secrets.

Secret sprawl is now the amplifier for supply chain worms. The attacker does not need deep exploitation when exposed credentials already exist in developer machines, pipelines, and repository workflows. Cycode's data shows the campaign surfaced thousands of repos and more than fourteen thousand secrets, which is enough to make blast radius management the primary control problem. Secret propagation window: once a secret exists across endpoints and pipelines, the time to theft is often shorter than the time to detection. Practitioners should focus on shortening exposure windows and reducing token reach.

Self-replication changes the governance model from detection to containment. A worm that can republish itself across package namespaces punishes slow approval cycles, broad maintainer privileges, and weak offboarding. The right control question is not whether a package is infected after the fact, but whether one identity can still publish, install, and exfiltrate across multiple systems without a fresh trust decision. Practitioners should treat package publishing as a privileged workflow requiring scoped, revocable access.

Destructive fallback logic shows that supply chain compromise can cross into resilience planning. The Home directory wipe logic means this campaign can produce endpoint damage even when exfiltration is disrupted. That is a useful warning for SOC and resilience teams because containment has to protect both credentials and local evidence. Practitioners should align NIST CSF detection and response activities with endpoint isolation and credential revocation workflows.

OWASP Non-Human Identity Top 10 fits this pattern directly. The attack maps to exposed secrets, overprivileged automation, and weak lifecycle control for npm and GitHub tokens. That makes it a practical example of why non-human identities need the same governance discipline that enterprises already apply to human access. Practitioners should use the incident to review token scope, rotation, and offboarding together rather than as separate hygiene tasks.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection without rotation leaves a standing attack path.
• For a broader supply-chain view, review the Shai Hulud npm malware campaign analysis for how secret theft turns into package propagation.

What this signals

Shai Hulud 2.0 is a reminder that secret management, package trust, and CI/CD governance can no longer be run as separate programmes. Once npm tokens, GitHub PATs, and cloud keys are all part of the same attacker path, teams need a single exposure model that follows the credential across build, publish, and repository stages.

Secret propagation window: the useful metric is not how many secrets you can detect, but how quickly you can revoke them before they are reused. That is why NHI lifecycle governance, repository monitoring, and pipeline isolation have to move together, with the OWASP Non-Human Identity Top 10 providing a practical control lens.

For programmes that rely on self-hosted runners and package automation, the next step is to treat publishing rights as privileged access and to validate them with the MITRE ATT&CK Enterprise Matrix. That shift changes response from repo cleanup to identity containment, which is where the real recovery work begins.

For practitioners

• Audit npm dependency trust paths Scan projects for the compromised packages referenced in the campaign, pin known-good versions, and review post-install execution paths for unexpected scripts.
• Rotate all exposed developer and pipeline secrets Assume GitHub PATs, npm automation tokens, cloud credentials, and database passwords on developer machines or in CI/CD may already be compromised.
• Restrict package publishing and repository write access Limit who and what can publish packages, create GitHub Actions workflows, or republish from a maintainer account, and remove broad standing permissions.
• Hunt for suspicious public repositories and workflow files Search for newly created public repositories, unfamiliar YAML workflow files, and repo visibility changes that could indicate exfiltration or tampering.
• Build containment playbooks for dual-purpose malware Prepare response steps that isolate endpoints, preserve forensic evidence, and revoke credentials before destructive fallback logic can trigger local loss.

Key takeaways

• Shai Hulud 2.0 shows how a software supply chain worm can become a full credential compromise when npm trust, GitHub access, and CI/CD privileges are linked.
• The campaign's scale and secret theft prove that detection is not enough if exposed tokens remain valid and reusable across build and publishing systems.
• Practitioners need shorter token lifecycles, narrower publishing rights, and containment playbooks that assume both exfiltration and destructive fallback behaviour.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• CI/CD security testing: The use of automated security checks inside continuous integration and continuous deployment pipelines. This includes tools that evaluate code, running applications, and interactive behaviour so vulnerabilities can be found and blocked before deployment becomes irreversible.

What's in the full article

Cycode's full blog post covers the operational detail this post intentionally leaves for the source:

• The full compromised package list and indicators of compromise used for exposure checks
• Examples of the malicious GitHub repository naming patterns and workflow artefacts
• Cycode's remediation workflow for secret detection, priority ranking, and pipeline investigation
• The published impact table showing affected packages, maintainers, repos, and stolen key types

👉 Cycode's full post covers the affected packages, IoCs, and response steps in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It gives practitioners a common control language for reducing exposure across pipelines, tokens, and automated access paths.