Shai Hulud 2.0 exposes how npm worm attacks amplify secret risk

At a glance

What this is: Cycode says Shai Hulud 2.0 turns npm compromise into a secret-theft and self-replication campaign that spreads through packages and public GitHub repositories.

Why it matters: It matters because teams handling npm, CI/CD, and developer secrets need to treat exposed tokens as active propagation paths, not just isolated leak events.

By the numbers:

• Cycode reports 775 GitHub PATs, 373 AWS keys, 300 GCP keys, and 115 Azure keys were stolen.
• The campaign has affected more than 25,000 compromised GitHub repositories and 492 to 800 plus republished npm packages.

Context

Shai Hulud 2.0 is a supply chain worm that uses compromised npm packages to steal secrets and then reuse those secrets to spread. The governance gap is not just package trust, but the way developer credentials, CI/CD tokens, and repository permissions can become part of the propagation chain.

For identity and access teams, the important question is whether machine credentials, automation tokens, and developer access are governed as a live attack surface. When package compromise can lead directly to token theft, repository abuse, and workflow tampering, secrets management and software supply chain security become one control problem rather than two separate programmes.

Cycode’s article frames a pattern that is already typical of modern dependency-driven attacks: secrets are harvested first, then used to widen access, accelerate replication, and hide in ordinary developer workflows.

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 exposed machine secrets make supply chain attacks worse?

A: Because machine secrets are often reusable across package publishing, repository access, and cloud operations. If attackers steal tokens or keys, they can use legitimate identities to publish malicious updates, create repositories, and expand access without needing a separate intrusion path. That multiplies the blast radius of the initial compromise.

Q: What are the signs that secret theft is spreading through a developer environment?

A: Watch for unexpected package publication, new public repositories, unfamiliar GitHub Actions workflows, unusual token use, and secrets appearing in places that do not match normal developer activity. Those signals matter because the attacker is often using valid credentials, so the anomaly is in behaviour and context, not just failed authentication.

Q: Should organisations treat npm automation tokens as machine identities?

A: Yes. npm automation tokens function as machine identities because they authenticate systems, publish software, and can be used without a human in the loop. They should be inventoried, scoped narrowly, monitored continuously, and revoked on task completion or suspected compromise, just like any other privileged non-human credential.

Technical breakdown

How npm post-install compromise turns dependencies into an entry point

npm packages can execute post-install scripts, which means a malicious dependency can run code as soon as it is installed. In a supply chain worm, that first execution step is enough to enumerate local secrets, inspect developer tooling, and reach into CI/CD contexts. The technical risk is not the package manager alone, but the trust granted to package lifecycle events and the breadth of credentials available on developer machines and build runners.

Practical implication: treat dependency installation as an execution event and reduce the credentials available during package builds.

Why stolen API keys and GitHub tokens create self-propagation

Once a worm steals API keys, cloud credentials, or GitHub and npm tokens, it can publish malicious package updates, create repositories, and exfiltrate data under legitimate identities. That is what turns secret theft into replication. The attacker does not need persistent kernel-level access if package publication rights, repository writes, and workflow permissions are already tied to reusable tokens.

Practical implication: scope tokens narrowly and assume any exposed credential can be used for both theft and onward spread.

How stealth and fail-safes increase dwell time and impact

Shai Hulud 2.0 hides core logic with Bun, stores stolen data in randomly named public repositories, and raises its package infection cap to increase spread before detection signatures catch up. The destructive fail-safe that wipes the user home directory if authentication fails adds coercive pressure and increases operational damage. The technique shows that modern dependency malware blends stealth, scale, and sabotage in one chain.

Practical implication: detection must cover unusual repo creation, anomalous package publishing, and destructive fallback behaviour, not just signature matches.

Threat narrative

Attacker objective: The attacker wants to steal reusable secrets, expand through trusted package channels, and convert one infected dependency into a broader supply chain compromise.

1. Entry occurs when a developer installs a compromised npm package that runs malicious post-install logic.
2. Credential harvesting follows as the malware searches for API keys, cloud credentials, and npm or GitHub tokens on developer systems and in CI/CD contexts.
3. Escalation happens when stolen tokens are used to publish malicious package updates, create public repositories, and expand the infection across additional packages.
4. Impact is achieved through widespread secret exposure, repository compromise, and the destructive wipe of local home directories when authentication fails.

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.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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

Shai Hulud 2.0 is a secrets governance failure as much as a supply chain attack. The worm works because package trust, developer credentials, and CI/CD token scope are allowed to overlap. Once those three surfaces intersect, one malicious install can become both a leak event and a propagation event. The practitioner lesson is to govern package trust and secret lifecycle together, not as separate domains.

Randomised exfiltration infrastructure is a named shift in the attacker playbook. By moving stolen data into randomly named public repositories, the campaign weakens pattern-based detection that relied on fixed repo names. That forces defenders to look at repository creation behaviour, ownership anomalies, and token misuse rather than a narrow IOC list. The implication for the field is that secrets abuse is now dynamic infrastructure abuse.

Secret exposure now changes the blast radius of dependency compromise. The article’s scale data shows that thousands of repositories and secrets can be implicated once a worm reaches a package ecosystem with broad developer adoption. That is why the decisive control is not just detecting the infected package, but shortening the time between exposure and credential revocation. Practitioners should treat exposed machine secrets as active propagation fuel.

OWASP-NHI becomes relevant here because the attack depends on machine identities, not only human accounts. npm automation tokens, GitHub PATs, cloud keys, and CI/CD runner credentials behave like non-human identities when they are used to authenticate systems and publish artefacts. The governance failure is overlong secret validity and insufficient offboarding of machine access. The practitioner conclusion is to inventory, classify, and revoke these identities with the same discipline used for privileged human accounts.

Shai Hulud 2.0 shows why supply chain security and identity governance are converging. The worm does not just compromise code, it abuses the identities that move code through modern delivery pipelines. That means access review, secrets rotation, and package integrity controls now have to be designed as a single control plane. The field should read this as validation that machine identity governance is becoming a core supply chain control.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Secret sprawl has become a propagation mechanism, not just a hygiene issue. When dependency compromise can reach API keys, cloud credentials, and automation tokens, the programme question changes from “how many secrets are exposed?” to “how quickly can we invalidate them once exposed?” That is a materially different governance model for CI/CD, developer laptops, and build runners, and it should be treated that way in risk registers.

OWASP-NHI fits this pattern because the abused assets are machine identities with publish and deploy rights. The practical consequence is that lifecycle control, offboarding, and scope review for machine credentials need the same attention as privileged human access. Teams that still treat those secrets as static implementation details will keep losing the race between exposure and reuse.

For practitioners

• Audit package installation trust paths Identify where post-install scripts can run with access to secrets, tokens, or repository credentials, then reduce those privileges during dependency installation.
• Rotate all exposed machine secrets Assume API keys, cloud credentials, npm automation tokens, GitHub PATs, and CI/CD credentials on developer endpoints or runners may already be compromised.
• Inspect repository and workflow creation activity Look for unknown GitHub Actions files, unexpected public repositories, and anomalous package publishing from accounts that normally do not create them.
• Tighten automation token scope and offboarding Treat npm and GitHub automation tokens as machine identities with lifecycle ownership, short validity, and explicit revocation when the task ends.

Key takeaways

• Shai Hulud 2.0 shows that npm compromise becomes much more dangerous when stolen secrets can be reused to publish, exfiltrate, and spread.
• The article’s figures point to large-scale secret exposure, with thousands of repositories and more than 14,000 secrets implicated.
• The limiting control is rapid revocation and tighter token scope, because detection alone does not stop a worm that can already authenticate as a trusted system.

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.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.
• CI/CD Pipeline Poisoning: CI/CD pipeline poisoning is the compromise of build, test, or deployment automation so malicious code, secrets, or configuration changes are introduced into software delivery. It targets the trusted path between source and production, often by altering scripts, dependencies, runners, credentials, or approvals, turning automation into a supply chain attack vector.

Deepen your knowledge

The 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 identity lifecycle control to the risks created by automation tokens, API keys, and service credentials.