TL;DR: TeamPCP’s Mini Shai-Hulud worm compromised legitimate npm packages by stealing CI/CD secrets, hijacking OIDC tokens, and publishing malicious versions through GitHub Actions, with the payload also harvesting cloud, AI, and developer credentials, according to StepSecurity. The incident shows that pipeline trust, secret sprawl, and package provenance can fail together, turning build systems into propagation channels.
At a glance
What this is: This is a supply chain worm analysis showing how Mini Shai-Hulud spread through npm packages by abusing CI/CD secrets, OIDC tokens, and release pipelines.
Why it matters: It matters because the attack shows how package provenance, pipeline trust, and secret exposure can collapse into a single propagation path that affects both developer and machine identities.
By the numbers:
- The worm compromised 84 malicious versions across 42 @tanstack/* packages.
Context
Mini Shai-Hulud is a supply chain worm, not a routine package compromise. It abuses the trust chain around npm publishing, GitHub Actions, and OIDC-backed release automation to move from one maintainer environment into many downstream projects.
For IAM and NHI teams, the identity angle is direct: the attacker is not just stealing code, it is stealing build identities, tokens, and runner-held secrets, then using those credentials to propagate further. That makes the problem a governance issue as much as a malware problem, especially where CI/CD systems and developer tooling share trust boundaries.
Key questions
Q: What breaks when a GitHub Actions workflow component is compromised?
A: A compromised workflow component can turn CI/CD into a secret-exposure path because runner processes may hold credentials, tokens, and job data in memory during execution. If logs or memory are readable by attacker-controlled code, the workflow becomes a credential harvesting channel, not just a build step. That is why action integrity and secret minimisation must be governed together.
Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?
A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.
Q: How do security teams know whether package provenance is actually helping?
A: Provenance is helping only if it changes allow or block decisions in ways that reduce trust in unsafe release paths. If malicious packages can still be published through a compromised maintainer workflow, the attestation layer is not enough on its own. Measure whether provenance is combined with workflow isolation, identity checks, and secret containment before release approval.
Q: When should organisations prioritise package cooldowns over faster release flows?
A: They should prioritise cooldowns when the ecosystem can weaponise new releases before human review or threat intelligence catches up. In npm-heavy environments, a short delay on newly published packages can interrupt the window that worms exploit to spread. The trade-off is slower adoption, but the benefit is a smaller exposure window for malicious updates.
Technical breakdown
How the worm uses CI/CD identity to publish malicious packages
The attack starts with control of a maintainer’s release path, then pivots through GitHub Actions and OIDC. OIDC tokens are intended to replace static credentials with short-lived, federated identity, but the flow still depends on trusted runner state and correct workflow isolation. If an attacker can poison the build context or extract the token from memory, the release pipeline becomes an authority channel for signing or publishing malicious artifacts. In this case, the worm chained workflow abuse, cache poisoning, and token extraction to publish infected versions from the project’s own automation.
Practical implication: Treat release workflows as identity-bearing systems and lock down token issuance, workflow trust, and runner isolation together.
Why secret sprawl turns a package worm into environment-wide compromise
The payload does not stop at npm credentials. It searches runner memory and local files for cloud keys, GitHub tokens, vault tokens, SSH keys, AI tool configs, and other secrets, then encrypts and exfiltrates them. This is classic secret sprawl exploitation: once secrets live outside a governed vault or are available to broad runtime contexts, a single execution path can expose many unrelated systems. The breadth matters because it turns one infected package into a bridge across developer, cloud, and AI tooling environments.
Practical implication: Inventory where secrets actually exist at runtime, not just where policy says they should exist.
Why provenance can fail even when attestations are present
The article notes that the compromised packages carried valid SLSA Build Level 3 provenance attestations, which is unusual and important. Provenance tells you something about how a package was built and signed, but it does not guarantee that the maintainer’s release environment was uncompromised or that every step in the workflow was safe. When the publishing identity itself is subverted, a valid attestation can accompany a malicious artifact. That is why provenance, identity assurance, and runtime validation have to be considered separately.
Practical implication: Do not treat attestation alone as sufficient proof of package safety.
Threat narrative
Attacker objective: The attacker aims to turn trusted npm release automation into a propagation mechanism that steals secrets and distributes malicious packages at ecosystem scale.
- Entry began with compromise of a maintainer-controlled release workflow and abuse of GitHub Actions trust.
- Credential access followed through OIDC token extraction, runner memory scraping, and collection of repository and environment secrets.
- Escalation occurred when the stolen credentials were reused to enumerate package ownership and publish infected versions across multiple maintainer namespaces.
- Impact was self-propagating package compromise, secret exfiltration, and wider ecosystem exposure across npm, cloud, AI, and developer tooling.
Breaches seen in the wild
- Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
- GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.
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
Package provenance is not the same as package trust. This incident shows that a valid build attestation can coexist with malicious intent when the release identity and workflow are compromised. Security teams need to separate artifact provenance from maintainer environment integrity, because one does not guarantee the other. The practitioner conclusion is that provenance controls must be paired with stronger identity and workflow governance.
CI/CD runners have become high-value non-human identities. The worm targets runner-held secrets, OIDC tokens, and workflow permissions because those assets can publish, sign, and propagate code without human intervention. That makes the runner itself an identity boundary, not just infrastructure. The practitioner conclusion is that machine identity governance has to include release automation, not only cloud workloads and service accounts.
Secret sprawl is the real blast-radius multiplier. The payload harvested credentials from cloud, developer, messaging, and AI tool paths because organisations keep secrets across many unmanaged locations. This is exactly where the NHI and broader identity problem intersect: exposed tokens and reusable credentials let a single compromise spread across multiple control planes. The practitioner conclusion is to treat secret location and runtime accessibility as governance data, not just implementation detail.
SLSA alone did not stop a trusted-pipeline compromise. Valid SLSA Build Level 3 provenance did not prevent malicious publication because the attacker operated inside the release path. That means build standards reduce some risk but do not eliminate the need for identity assurance, runner hardening, and approval boundaries. The practitioner conclusion is to use supply chain controls as one layer, not the whole defense model.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl is now a propagation problem, not just a hygiene problem. When a worm can read runner memory, local files, and developer tooling paths, every unmanaged secret becomes a potential downstream control-plane compromise. Organisations should map where CI/CD secrets, cloud tokens, and AI tool credentials actually live, then narrow the runtime places that can see them. according to the Ultimate Guide to NHIs
Release pipelines must be treated as non-human identity systems. The attacker is exploiting automated publishing authority, not merely exploiting code. That means policy has to govern token issuance, workflow trust, and package publication rights as identity controls, not as DevOps convenience settings.
For practitioners
- Harden release-workflow identity Restrict GitHub Actions permissions, lock down OIDC audience and subject claims, and separate publishing credentials from general build jobs so a compromised workflow cannot publish packages broadly.
- Reduce secret exposure in runners Move high-value secrets out of runner memory and file-system paths where possible, and inventory every location where CI jobs can read cloud, Git, and developer tool credentials.
- Block risky package updates during cooldown Apply package cooldown policies to newly published npm versions, especially maintainers’ packages that can propagate through many repositories before a malicious release is detected.
- Search for affected package versions across the estate Use organization-wide package search and developer-device visibility to identify repositories, pull requests, and endpoints that installed compromised versions and may need revocation.
- Separate attestation from trust decisions Treat SLSA provenance as one signal and require additional checks on maintainer workflow integrity, runner isolation, and secret handling before approving release automation.
Key takeaways
- Mini Shai-Hulud shows that npm supply chain worms can spread by abusing release automation, runner secrets, and package publishing authority at the same time.
- The attack’s scale is evident in the 84 malicious versions across 42 @tanstack/* packages, with spread continuing into other maintainers’ namespaces.
- The strongest limitation is tighter control over CI/CD identity, secret exposure, and package cooldowns before malicious releases reach developers or pipelines.
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 NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set 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 exfiltrates secrets from runners, files, and developer tooling. |
| NHI-04 — Insecure Authentication | OIDC token abuse and stolen release identity drive the compromise. | |
| NHI-05 — Overprivileged NHI | Release automation had enough authority to publish malicious versions widely. | |
| Recommendation — Scan CI/CD runners and package workflows for exposed secrets and revoke any leaked credentials immediately. Harden federated authentication paths so workflows cannot mint or reuse publishing tokens outside intended scope. Reduce workflow and runner privileges so package publication cannot occur from broadly trusted automation. | ||
| MITRE ATT&CK | TA0006; TA0008; TA0040 — Credential Access; Lateral Movement; Impact | The attack chain combines secret theft, reuse, and ecosystem-wide propagation. |
| Recommendation — Map the worm to credential access, lateral movement, and impact to prioritise detections around token theft and package publishing. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on stolen and reusable secrets and tokens. |
| Recommendation — Apply authenticator management to rotate, revoke, and scope CI/CD credentials used in release automation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The worm exploits excessive publishing and runner permissions in the pipeline. |
| Recommendation — Limit release and runner permissions to the minimum required for each job and package. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised maintainer and pipeline accounts enabled the spread. |
| Recommendation — Track and remove stale, shared, or overbroad CI/CD accounts that can publish software artifacts. | ||
Key terms
- Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
- OIDC token: An OIDC token is a signed credential used in OpenID Connect to prove a user or client identity after authentication. It typically appears as an ID token, access token, or refresh token, and carries claims such as subject, issuer, audience, and expiry for validation by relying systems.
- 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.
- Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and IAM practitioners translate identity controls into practical governance decisions.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org