TL;DR: Shai Hulud 2.0 is an ongoing npm supply chain attack in which malicious packages masquerade as legitimate dependencies, then steal sensitive information, execute code, or open backdoors while spreading through transitive references, according to Arnica. The security problem is not just package compromise but the time it takes teams to identify where a package exists and whether it reached production.
At a glance
What this is: This is an analysis of Shai Hulud 2.0, an npm supply chain attack that exploits package trust and transitive dependency spread to create hidden exposure across development and deployment environments.
Why it matters: It matters because identity, access, and release controls only help if teams can rapidly map package use, trace deployed exposure, and contain compromised dependencies before they reach production.
Context
Shai Hulud 2.0 highlights a visibility gap in supply chain security: teams can inherit risk from packages they never intentionally added, then struggle to prove where those components exist. In modern software delivery, dependency trust is often broader than repository ownership, which makes detection and containment harder when a package is compromised.
The identity angle is indirect but real. Build pipelines, CI runners, and deployment paths all rely on non-human identities, tokenised access, and automated trust between systems. When a malicious package enters that chain, the security question becomes not only whether the code is unsafe, but whether organisations can trace which identities, repos, and images touched it.
Key questions
Q: What breaks when a compromised npm package is only visible in source control?
A: Incident response breaks because source visibility does not prove deployed exposure. A package may be present in a repository, a lockfile, or a build cache without reaching production, and the reverse can also happen through nested dependencies. Teams need a source-to-image view to separate real risk from theoretical presence.
Q: Why do transitive dependencies increase supply chain risk in JavaScript projects?
A: Transitive dependencies expand the attack surface because teams often install a small set of direct packages while inheriting hundreds more indirectly. That hidden depth makes it easier for vulnerable, abandoned, or poisoned packages to enter production unnoticed. If controls only inspect top-level packages, security teams miss where risk actually accumulates.
Q: How can security teams tell whether a flagged package reached production?
A: They need provenance that connects source manifests, build outputs, and runtime images. If those layers are not linked, teams cannot distinguish a harmless repository reference from a deployed artifact that now carries compromise. Production exposure should be confirmed with artifact-level evidence, not assumption.
Q: How should teams limit the spread of malicious packages through automation?
A: Constrain the non-human identities that run builds, pull dependencies, and publish artifacts. Narrow repository scope, shorten token lifetime, and separate build permissions from release permissions so an infected package cannot use automation as a propagation path.
Technical breakdown
How malicious npm packages spread through transitive references
Supply chain attackers often target package ecosystems because a single compromised dependency can propagate into many repositories through transitive references. Transitive exposure means a team may consume a package indirectly through another dependency, so the malicious code is not obvious in the top-level manifest. That makes inventory and provenance more important than simple package approval. In npm environments, the attack surface includes source code, lockfiles, build outputs, and container images. A package can remain present even after the original repository owner has cleaned up obvious references. The practical control problem is knowing where the package exists at every stage of delivery, not just in source.
Practical implication: Map dependencies from source to image so hidden transitive packages are found before they are shipped.
Why SBOM visibility is necessary but not sufficient
A software bill of materials gives teams a structured view of components, but it is only as useful as its freshness, scope, and linkage to runtime artefacts. If the inventory is stale, incomplete, or disconnected from deployed images, it will miss the exact exposure created by a live supply chain event. That is why package-centric search and source-to-image mapping matter: they turn an inventory document into an operational detection and response tool. The key distinction is between knowing a package exists somewhere and knowing whether it was actually built, referenced, or deployed. Without that linkage, incident response stalls at triage.
Practical implication: Treat SBOMs as an exposure index only when they are linked to current build and deployment data.
How non-human identities amplify build and release risk
CI runners, automation tokens, package managers, and deployment services act as non-human identities in the software delivery chain. If those identities have broad repository or registry access, a malicious package can exploit trusted automation to move faster than manual review can contain it. The issue is not just the package itself, but the credential and privilege path that lets it reach build, test, or image layers. This is where identity governance intersects with supply chain security: access scope, token lifetime, and workload trust determine whether a package compromise stays local or spreads across environments.
Practical implication: Constrain CI and release identities so dependency compromise cannot automatically become production exposure.
Threat narrative
Attacker objective: The attacker aims to gain trusted footholds in software delivery workflows, steal sensitive material, and widen compromise through dependency propagation.
- Entry begins when threat actors publish malicious npm packages that masquerade as legitimate dependencies and are pulled into development workflows.
- Credential and execution abuse follows when the installed package steals sensitive information, executes remote code, or opens backdoors inside engineering environments.
- Impact occurs when the compromised dependency propagates through transitive references or outdated pins, leaving teams exposed across repositories and deployed images.
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.
- Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.
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 visibility is now a security control, not an inventory convenience. Shai Hulud 2.0 shows that dependency compromise is operationally useful to attackers only when defenders cannot rapidly map package presence across repositories, files, and images. The governing problem is exposure latency, not simply package trust. Practitioners should treat package discovery speed as a core element of software supply chain defence.
SBOM quality is determined by how well it links source, build, and runtime state. A static list of components does not answer the questions that matter during an active supply chain event. If a package appears in source but not in the deployed image, the risk is different from a package that reached production through a build pipeline. Teams need provenance linkage, not just component enumeration, to make response decisions quickly and defensibly.
Shai Hulud 2.0 exposes dependency reachability debt. Large codebases accumulate outdated references, indirect package usage, and abandoned pins that widen the window for hidden exposure. That is a governance failure because the organisation cannot state with confidence which software paths are still live. The practical conclusion is that software ownership must include reachability and deployment state, not only repository hygiene.
Non-human identity governance belongs in supply chain response. Build runners, automation tokens, and release services are the identities that move malicious packages from code to artifact. If those identities are over-privileged, the attacker does not need to break the pipeline, only to ride it. Practitioners should align package visibility with credential scope so exposure analysis and access control operate as one control plane.
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: AI Supply Chain Security and AI-BOM Guide
What this signals
Shai Hulud 2.0 is a useful reminder that package compromise becomes a governance problem only when organisations cannot trace exposure fast enough to make containment decisions. Dependency reachability debt: when old references, transitive pulls, and undeployed manifests stay mixed together, incident response loses the ability to separate real production risk from noise.
The broader pattern is that software supply chain defence now depends on joining inventory, provenance, and non-human identity controls. 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
For practitioners
- Build package-to-repo exposure mapping Create a package-centric inventory that shows every repository, file, and container image where a given npm package appears. Prioritise transitive references and stale lockfile entries because those are the places defenders usually miss during an active campaign.
- Link SBOM data to deployed images Verify whether a flagged dependency actually made it into a runtime artifact, not just whether it exists in source control. Join source manifests, build outputs, and image attestations so incident triage can separate theoretical exposure from production risk.
- Review CI runner and release token scope Limit non-human identities that can pull packages, build artifacts, or publish releases. Narrowing token lifetime and repository scope reduces the chance that a malicious dependency can use automation to spread across environments.
- Prioritise stale or transitive package paths Search for packages that are no longer actively maintained, appear only through nested dependencies, or are referenced in older branches and images. These paths often outlive visible remediation and keep compromised components reachable.
Key takeaways
- Shai Hulud 2.0 shows that npm package compromise can spread quietly through transitive references and outdated dependencies, making exposure harder to spot than the initial malicious upload.
- The control gap is not only package approval but the ability to prove where a package exists, whether it was built, and whether it reached a deployed image.
- CI runners, release tokens, and other non-human identities determine whether a dependency incident stays contained or turns into broader software supply chain exposure.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Compromised npm dependencies act like third-party non-human identities in the software supply chain. |
| NHI-08 — Environment Isolation | The article centers on keeping malicious package exposure from moving between source, build, and deployment environments. | |
| Recommendation — Inventory third-party package trust paths and isolate any dependency that can influence build or release automation. Separate source, build, and runtime environments so compromised packages cannot traverse all three unchecked. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The attack pattern includes secret theft and downstream data theft through compromised packages. |
| Recommendation — Map package-based secret theft to TA0006 and exfiltration paths to TA0010 in your detections. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party package trust and supply chain exposure are part of provider and dependency governance. |
| Recommendation — Review third-party dependency oversight under CIS-15 and revoke high-risk package trust relationships. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity Checking | Package tampering and undeployed exposure require integrity verification across build artefacts. |
| Recommendation — Apply PR.DS-08 to verify package integrity from source through build artifacts and deployments. | ||
Key terms
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Source-to-Image Mapping: Source-to-image mapping is the process of tracing a dependency from code reference to build artifact and then to the deployed container image. It gives security teams evidence of whether a package is merely present in source or has actually reached a runtime environment.
- 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.
- Dependency Reachability: Dependency reachability is the question of whether a vulnerable library or function can actually be invoked in the deployed application path. It matters because not every disclosed package flaw creates equal risk. Teams use it to separate theoretical exposure from issues that can be exploited in practice.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect software delivery controls to the identity layer that governs automation and release paths.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org