TL;DR: Shai-Hulud v2 has affected 525+ npm packages and 132 million monthly downloads, with new behaviour that steals secrets and adds GitHub Actions persistence, according to Semgrep and Aikido. The incident shows that leaked secrets, token scope, and runner trust assumptions now create a combined supply chain identity problem, not just a malware problem.
At a glance
What this is: This analysis covers the Shai-Hulud npm worm v2 and shows how secret theft, token abuse, and GitHub Actions persistence turn package compromise into a supply-chain identity problem.
Why it matters: It matters because IAM, secrets, and CI/CD governance now intersect in one attack path, and teams need to treat package maintainers, runners, and cloud tokens as one trust chain.
By the numbers:
- 525+ packages have been affected by the Shai-Hulud v2 wave.
- 132 million monthly downloads were tied to the affected package set.
Context
Shai-Hulud v2 is a supply-chain worm that moves through npm packages, but the security problem is broader than package infection. The article shows how stolen tokens, readable secrets, and weak runner trust combine into a reusable identity pathway across development and cloud environments.
In practical terms, this means the control boundary is no longer the package registry alone. Identity, secret handling, and CI/CD execution have become one chain, so a compromise in one place can propagate through maintainers, runners, and downstream deployments.
Semgrep’s coverage frames a problem that is now typical for modern supply chains rather than an edge case: attackers are exploiting the identities and credentials that glue build systems together.
Key questions
Q: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.
Q: Why do npm tokens and build credentials increase supply chain risk so quickly?
A: Because they are reusable non-human identities with privileges that outlive a single session. If an attacker steals a token that can publish packages or write automation, the compromise can spread from one repository to many others, turning a local infection into ecosystem-wide propagation.
Q: What are the signs that a CI/CD runner has been used as persistence?
A: Look for unfamiliar workflows, new repository-level automation, unusual runner registration activity, and logs showing self-hosted execution tied to suspicious repository events. In this pattern, persistence is not a stolen password, but a workflow that keeps reintroducing attacker-controlled code into trusted build infrastructure.
Q: How should teams respond when a tainted package may have touched production-connected secrets?
A: Assume the affected environment is exposed, isolate it from sensitive systems, revoke credentials that were reachable from that host or runner, and inspect for persistence before restoring trust. The response priority is credential containment first, then host cleanup, then rebuild from verified artifacts. Waiting for proof of theft usually wastes the containment window.
Technical breakdown
How the worm turns package installation into credential theft
Shai-Hulud v2 rides on a malicious preinstall hook, so code runs as part of normal package installation rather than after a separate exploit step. Once execution starts, the malware searches local files, environment variables, and GitHub Actions artifacts for tokens and secrets, then uses discovery tooling such as Trufflehog to surface credentials already present in the build or maintainer context. That matters because package installation is treated as routine trust, yet it executes with enough access to expose cloud keys, npm tokens, and GitHub tokens in one pass.
Practical implication: inspect package install paths as credential-exposure points, not just dependency integrity points.
Why GitHub Actions persistence changes the blast radius
The second variant adds a persistence layer by planting a GitHub Actions workflow that can be triggered through repository activity. In the article’s example, a vulnerable workflow tied to discussions can be used to execute arbitrary code on self-hosted runners, which means the malicious package is no longer only a one-time secret harvester. It can establish a repeatable foothold inside CI/CD infrastructure, extending impact beyond the original install event and making the runner itself part of the attack surface.
Practical implication: treat workflow definitions and self-hosted runners as privileged execution assets that require separate review and hardening.
How npm token scope enables self-propagation
The propagation step depends on valid npm maintainer tokens. After validating a token, the worm can query package ownership, pull the tarball, inject a preinstall script, add malicious files, repack the archive, and publish a new infected version. This is a classic supply-chain identity pattern: delegated publishing authority becomes the propagation mechanism. The critical weakness is not just token theft, but token scope that is broad enough to let the attacker act as the maintainer across multiple packages.
Practical implication: reduce publishing-token scope and separate package release authority from day-to-day developer access.
Threat narrative
Attacker objective: The attacker wants reusable maintainer access that exposes secrets, persists in CI/CD, and self-propagates through npm package publishing.
- Entry occurs through a malicious npm package install, where the added preinstall hook executes during routine dependency handling.
- Credential harvest follows as the malware scans files, environment variables, GitHub Actions artifacts, and cloud provider material for AWS, GCP, Azure, npm, and GitHub tokens.
- Escalation and persistence occur when the worm uses valid maintainer tokens to republish infected packages and seeds a GitHub Actions workflow that can execute on self-hosted runners.
- Impact is broader supply-chain compromise, with stolen secrets, infected package versions, and potential code execution on runner infrastructure spreading through downstream consumers.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Supply-chain identity is now the control plane, not a side effect: This worm succeeds because package publishing, secret storage, and runner execution are treated as separate governance problems. They are not separate at attack time. The operational conclusion is that npm maintainers, CI runners, and cloud tokens form one identity system, and the weakest trust decision in that chain defines the blast radius.
GitHub Actions trust assumptions are now a persistence risk: The article shows that workflow execution can become a backdoor when self-hosted runners accept repository-triggered actions too readily. That is not just a workflow flaw, it is an identity boundary failure between code authorship and code execution. Practitioners need to treat workflow-triggered runner access as privileged access governance, not build convenience.
Package maintainer authority is too broad for modern supply-chain threat models: The ability to republish an altered package from a stolen token turns release privilege into propagation privilege. That means least privilege for npm is no longer about who can publish, but about how much downstream trust a single publishing credential can exercise. The practitioner takeaway is to separate release authority from broad package estate control.
Identity blast radius should replace isolated token management as the governing concept: A token that can reach npm, GitHub, and cloud environments creates a cross-system blast radius that conventional per-platform controls miss. Identity blast radius: the total set of systems an identity can affect once a single secret is exposed. Teams should govern that radius explicitly rather than assuming each platform’s controls will contain it.
Secret exposure, not malware novelty, is the durable lesson: The worm’s mechanics matter less than the governance pattern it exploits. Readable secrets, wide token scope, and runner trust are the reusable ingredients, so the field should treat this as evidence that supply chains need identity lifecycle governance across build, publish, and execution stages. The practitioner conclusion is to manage these as linked identities, not isolated tools.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Identity blast radius: npm publishing, GitHub workflow execution, and cloud token exposure now belong in the same governance model. Teams that still review them separately will miss how a single maintainer credential can cross build, release, and infrastructure boundaries.
The immediate programme change is to treat package installation as a high-risk execution event and self-hosted runners as privileged identity infrastructure. That shift aligns with zero standing privilege thinking even though the attack is in a supply-chain context, because the real issue is uncontrolled delegated access.
The broader signal is that secret scanning alone is insufficient when the attacker can also republish packages and seed persistence. Governance has to track where identities can act, not only where secrets are stored.
For practitioners
- Audit package publishing tokens for scope creep Map which npm tokens can publish, modify metadata, or touch multiple packages, then separate routine developer access from release authority and remove unnecessary workflow scopes.
- Review self-hosted runner trust paths Inventory runners that accept repository-triggered jobs, inspect workflow files for command injection exposure, and isolate runners that can execute code from untrusted repository content.
- Rotate exposed cloud and developer secrets Treat AWS, GCP, Azure, GitHub, and npm credentials as compromised if they were present on affected machines or in repositories touched by the worm.
- Scan dependency installs for malicious preinstall hooks Check package manifests for unexpected preinstall scripts such as setup_bun.js and validate whether install-time execution is permitted in your environment.
Key takeaways
- Shai-Hulud v2 shows that npm compromise becomes much more dangerous when package install, token scope, and runner trust are managed as separate problems.
- The incident’s scale is material, with 525+ packages and 132 million monthly downloads affected, which means downstream exposure can spread well beyond the initial maintainer account.
- The limiting control is identity governance across publishing rights, workflow execution, and secret rotation, not just malware detection after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The worm steals secrets from files, env vars, and CI artefacts. |
| NHI-03 — Vulnerable Third-Party NHI | The attack propagates through maintainer credentials and package publishing authority. | |
| NHI-04 — Insecure Authentication | Stolen npm and GitHub tokens are the main authentication mechanism abused here. | |
| Recommendation — Scan install paths and build artefacts for leaked NHI secrets and revoke exposed credentials quickly. Review third-party package identities and limit publishing access to the minimum required scope. Harden token issuance and replace broad-lived authenticator use with narrower, monitored credentials. | ||
| MITRE ATT&CK | TA0006;TA0003;TA0010 — Credential Access; Persistence; Exfiltration | The malware steals tokens, establishes persistence, and exfiltrates secrets. |
| Recommendation — Map the worm’s stages to credential access, persistence, and exfiltration to prioritise detection coverage. | ||
| CIS Controls v8 | CIS-5 — Account Management | Token scope and runner access are account governance problems. |
| Recommendation — Apply account management controls to publish-only access, runner identities, and privileged automation. | ||
Key terms
- Supply Chain Identity: The collection of credentials, tokens, workflow permissions, and publishing rights that let software move from source to deployment. In NHI terms, it is the identity layer of the pipeline, and when it is weak, compromise can propagate through legitimate automation rather than obvious malware channels.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Self-hosted runner: A CI/CD execution environment managed by the organisation rather than the platform vendor. It often has broad access to source, secrets, and deployment targets, which makes it a high-value persistence and exfiltration point if workflow controls are weak.
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org