Shai-Hulud 2.0 turns npm installs into a secrets exfiltration channel

At a glance

What this is: This is an analysis of a Shai-Hulud-style npm supply chain attack that used malicious package installs to steal secrets and create a large exfiltration network.

Why it matters: It matters because CI/CD, developer laptops, and cloud identities now share the same blast radius, so IAM, PAM, and NHI controls must treat package installs as credential-risk events.

👉 Read Unosecur's analysis of the Shai-Hulud 2.0 npm supply chain attack

Context

npm supply chain compromise is no longer just a software integrity problem. When a malicious package can execute during pre-install, the real target becomes the identity layer behind build systems, developer machines, and cloud services, because those environments often hold reusable secrets that outlive the package itself.

In this case, the attack turned ordinary dependency installation into a credential-harvesting event. That shifts the governance question from whether a package is trusted to whether the identities used by CI/CD and developers are tightly scoped, short-lived, and revocable across every environment they touch.

For NHI programmes, this is a classic example of secret sprawl meeting supply chain reach. The starting position is not unusual at all, which is precisely why these incidents keep scaling.

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 compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.

Q: How can teams tell whether secrets leakage is becoming a persistence problem?

A: Look for non-human identity behaviour that goes beyond copying data, such as new workflow creation, self-hosted runner registration, package republishing, or repeated token use from unusual locations. Those signals show the attacker is turning exfiltrated credentials into an ongoing access path rather than a one-off leak.

Q: Who is accountable when stolen pipeline credentials are used across cloud systems?

A: Accountability sits with the team that owns the pipeline identity, the secret lifecycle, and the runtime controls around it. If build jobs can access production systems, that access model must be formally governed and reviewed. Frameworks such as OWASP NHI Top 10 and NIST CSF are relevant because the issue is privileged non-human access, not just software supply chain hygiene.

Technical breakdown

Preinstall execution turns package install into code execution

npm lifecycle hooks can run before a package is fully installed, which means the installation event itself becomes an execution path. In this campaign, the malicious package used the pre-install phase to launch credential harvesting immediately, before developers or pipelines had a chance to inspect the final package state. That is important because dependency tools often treat install as a supply chain activity, not as active execution.

Practical implication: disable unnecessary lifecycle scripts in build environments and treat package installation as an execution boundary.

Credential harvesting reaches beyond repositories

The malware did not limit itself to source code. It scraped environment variables, cloud configuration paths, metadata tokens, GitHub tokens, CI/CD secrets, SSH keys, browser artifacts, and local configuration files, then packaged the output into JSON for exfiltration. That broad collection pattern matters because many organisations still assume secrets only leak from repositories, while the actual exposure surface spans endpoints, pipelines, and secret stores.

Practical implication: inventory every place secrets can exist, not just code repositories, and map each location to an owning identity.

Stolen tokens enable propagation and persistence

Once the attacker had valid tokens, they could create new GitHub repositories, register infected machines as runners, add workflows, and republish tampered packages through compromised maintainer accounts. This is why the incident behaved like a worm: stolen credentials were not just exfiltrated, they were reused to create new execution and distribution paths. In identity terms, the compromise moved from exposure to propagation through trusted automation paths.

Practical implication: monitor for unauthorized workflow creation, self-hosted runner registration, and package republishing activity across all maintainer identities.

Threat narrative

Attacker objective: The attacker aimed to harvest reusable cloud and pipeline credentials, then use them to persist, propagate, and pivot across downstream environments.

1. Entry occurred when attackers compromised maintainer accounts and published malicious npm package versions that executed during the pre-install phase.
2. Credential access followed as the malware scraped cloud keys, GitHub tokens, CI/CD variables, metadata tokens, SSH keys, and local configuration files.
3. Impact came from token reuse, repository creation, workflow backdoors, and package republishing that expanded the blast radius across many environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

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

NHI Mgmt Group analysis

Secret sprawl is now a supply chain control failure, not just a hygiene issue. This attack worked because credentials were already distributed across build agents, laptops, secret stores, and automation accounts. Once the package executed, it did not need novel privilege escalation to cause damage because the environment had already scattered the keys it needed. The practitioner conclusion is clear: the identity estate, not the registry, is the attack surface.

CI/CD identities need lifecycle governance, not just pipeline hardening. The malware abused credentials that existed long enough to be copied, replayed, and repurposed. That means access reviews, rotation cadence, and offboarding discipline must extend to service accounts, npm tokens, GitHub tokens, and runner credentials. Teams that only review human access will miss the identities actually used in the attack path.

Identity blast radius is the right concept for this class of incident. The scale of harm depended less on the malicious package itself than on how far each exposed credential could reach once stolen. A single token with broad cross-environment access can turn one install into many compromises. Practitioners should measure how many systems each secret can touch, because that determines whether a leak is contained or multiplied.

Runtime behaviour monitoring belongs in NHI governance for build systems. The attack generated repeated uploads, suspicious repository creation, and self-hosted runner registration, all of which are identity events as much as security events. Posture data alone is not enough when the compromise is active. The control gap is the absence of identity behaviour visibility for automation paths, and the practitioner conclusion is to govern those paths as first-class non-human identities.

Short-lived credentials reduce exposure, but only when republishing and token reuse are blocked. The campaign showed how temporary tokens can still be harvested and replayed if systems keep trust broad and revocation slow. This is a lifecycle problem as much as a secrets problem. The conclusion for security teams is to align expiration, scope, and revocation with the speed of package distribution, not with human review cycles.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation leaves a durable exposure window.
• Use the Guide to the Secret Sprawl Challenge to connect leak locations, ownership, and revocation into one operating model.

What this signals

Secret sprawl has become a lifecycle problem. When credentials spread across endpoints, collaboration tools, and CI/CD, the security programme has to govern discovery, ownership, rotation, and revocation as one chain rather than separate tasks. That is the practical lesson for IAM and NHI teams: a secret that cannot be tied to an identity and retired on schedule is already a governance failure.

Identity blast radius should become a standard metric for build and pipeline risk. If one token can reach GitHub, cloud control planes, and package registries, then compromise is no longer local. Teams should measure reach, not just presence, and use that to prioritise remediation across secrets stores, runners, and publishing workflows.

The right operational model is to treat package installs, workflow changes, and token reuse as identity events. That perspective aligns cleanly with the OWASP Non-Human Identity Top 10 and gives security teams a more defensible way to separate noise from compromise.

For practitioners

• Disable unnecessary npm lifecycle scripts Block pre-install and other lifecycle hooks in build environments unless there is a documented, approved business need. This closes the execution path that lets a malicious package run before review and limits the chance that installation itself becomes credential theft.
• Rotate every exposed credential class immediately Treat GitHub tokens, cloud provider keys, CI/CD credentials, npm publish tokens, SSH keys, and temporary session tokens as compromised if they touched an infected environment. Rotation must include revocation, not just replacement, or attackers can continue to reuse replayable secrets.
• Map secrets to owning identities and permissions Build a current inventory that links each secret to the identity that can use it, the systems it can reach, and whether it can assume additional roles. That relationship map is what tells you which leaked credential represents local noise and which one creates enterprise-wide blast radius.
• Monitor for GitHub persistence artefacts Search for suspicious workflows, unrecognized self-hosted runners, and repositories created by stolen tokens. Those artefacts show whether the attacker turned credential theft into persistence inside GitHub rather than stopping at exfiltration.
• Replace long-lived trust with scoped, short-lived access Prefer short-lived credentials for pipeline and package-publishing workflows, and restrict network reach from CI systems to only what each job needs. That reduces how far a leaked token can travel and makes exfiltrated credentials less reusable.

Key takeaways

• This attack shows that supply chain compromise and secret theft are now the same incident class when package installs can execute code.
• The exposure was large because stolen tokens and credentials could be reused across repositories, clouds, and automation systems.
• The control that matters most is lifecycle governance for non-human identities, including revocation, scope reduction, and persistence monitoring.

Key terms

• 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.
• Lifecycle Script: A lifecycle script is code that runs automatically during package installation or build steps, such as preinstall or postinstall hooks. These scripts are useful for legitimate automation but create a high-risk execution path because they can run before developers fully inspect the package.
• 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.
• Workspace Persistence: A condition where an AI agent leaves behind files or settings that continue to influence execution after the session ends. In agentic environments, this is dangerous because the hostile action may occur later through trusted host components, not through the agent itself.

What's in the full article

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

• The malware flow that linked pre-install execution to credential harvesting inside developer and CI/CD environments.
• The specific GitHub artefacts that exposed persistence, including runner registration and workflow abuse.
• The identity posture checks Unosecur uses to map leaked credentials back to production roles and elevated access.
• The revocation and cleanup sequence for cloud keys, npm tokens, GitHub tokens, and SSH keys.

👉 Unosecur's full blog covers the attack chain, exposed secret classes, and identity cleanup steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.