Shai-Hulud npm worm exposes the weak link in secret governance

At a glance

What this is: This is an analysis of the Shai-Hulud npm supply chain attack, which used malicious package installs to steal secrets and propagate further package poisoning.

Why it matters: It matters because CI/CD and developer-tooling compromise can turn a single exposed credential into broader repository, cloud, and software supply-chain exposure across NHI and human identity estates.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 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.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read LEGIT Security's analysis of the Shai-Hulud npm supply chain attack

Context

Secret exposure in modern software delivery is not a single-event problem. Once a token, API key, or GitHub PAT leaks into a build or package workflow, attackers can use it to move from code compromise into repository access, package publishing, and cloud abuse. In this case, the primary issue is not the presence of malicious code alone but the lack of fast revocation and lifecycle control for secrets in CI/CD and maintainer environments.

That makes this an NHI governance problem as much as a supply chain one. Package signing, dependency review, and malware detection matter, but they do not stop a valid credential from being used minutes or days later. For identity teams, the important question is whether secrets, service accounts, and developer tokens are treated as governed identities with ownership, scope, and revocation paths, or as static artifacts left to spread through the delivery chain.

Key questions

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: Why do stolen developer and publishing tokens create longer-lived risk than malware alone?

A: Because tokens behave like reusable identities. A malicious package may be removed quickly, but a valid GitHub PAT or npm token can still clone repositories, publish releases, or alter workflows until it is revoked. That persistence makes identity lifecycle control more important than file-based detection alone.

Q: What do security teams get wrong about private repositories and internal pipelines?

A: They often assume private means protected. In practice, internal repositories and build runners are attractive targets because they hold the most privileged credentials and least visible automation paths. The safer assumption is that any environment with deployment or publishing access must be treated as secret-bearing and continuously monitored.

Q: How should organisations respond when a package they trust is suddenly compromised?

A: Block the affected package immediately, identify every environment that installed it, and verify whether any secrets, tokens, or browser sessions were exposed. Then review publishing identities, CI permissions, and any downstream systems that could have inherited the compromise.

Technical breakdown

How the malicious npm package used post-install execution

The campaign relied on a familiar package-manager weakness: code that runs automatically after installation. A post-install script executes in the context of the consuming environment, which means it can read environment variables, local credentials, and any tokens available to the build runner or developer machine. In supply chain terms, the attacker does not need a direct login if the package itself becomes the execution vehicle. That turns dependency trust into runtime trust, which is why package vetting alone is insufficient when secrets are present in the environment.

Practical implication: isolate package installs from secret-bearing contexts and treat post-install hooks as executable risk, not harmless metadata.

Why stolen GitHub and npm tokens turn one compromise into many

GitHub PATs and npm tokens are not just access strings. They are delegated identities with publishing, repository, and workflow privileges that can be reused until revoked. In this attack pattern, once a token is harvested, it can be used to clone private code, publish malicious versions, or alter automation, which expands the blast radius beyond the original package. This is the same control problem seen in broader NHI abuse: persistent credentials outlive the event that exposed them, so the attacker gets time to act after defenders think the initial infection is over.

Practical implication: classify developer and publishing tokens as NHIs with explicit ownership, expiration, and immediate revocation workflows.

How worm-like package propagation changes the trust model

The worm-like element matters because it shifts the incident from isolated malware to self-propagating supply chain abuse. If a compromised package can discover maintainer-scoped credentials and publish new malicious releases under the same namespace, the attacker can spread laterally through the dependency graph without further initial access. That creates a maintenance-driven compromise loop where trusted publishing rights become the propagation mechanism. The real architectural failure is assuming package provenance and maintainer identity will remain stable after a secret is stolen.

Practical implication: add provenance checks, namespace monitoring, and release approval controls that can halt malicious publishing from a stolen maintainer context.

Threat narrative

Attacker objective: The attacker aimed to harvest reusable secrets that would let them persist across repositories, packages, and cloud environments while propagating the compromise through maintainer namespaces.

1. Entry occurred when users or CI/CD systems installed malicious npm package versions that contained a post-install secrets-harvesting script.
2. Escalation followed when the script extracted GitHub PATs, npm tokens, and cloud credentials from the environment and used them to widen access.
3. Impact was the ability to publish more malicious packages, access private repositories, and potentially move into cloud environments for theft or disruption.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 exposure has become an identity lifecycle failure, not just a detection problem. Scanning can tell you that a credential was exposed, but it does not end the risk unless revocation, rebuild, and scope reduction happen quickly. The article shows a classic NHI governance gap: secrets are still treated as static by-products of development rather than managed identities with a lifecycle. Practitioners should treat exposure as the start of an access decision, not the end of an incident.

Worm-like package abuse creates a new class of supply chain blast radius. When a compromised maintainer token can publish malicious releases under the same namespace, the attack no longer depends on a single infected artifact. It uses trusted publishing rights as the propagation channel, which makes maintainer identity and package provenance inseparable. That reinforces the OWASP Non-Human Identity Top 10 focus on secret hygiene, overprivilege, and lifecycle control.

Private repositories and internal build systems are not safe by default. The campaign's logic depends on the assumption that internal systems have lower exposure, but the reality is that CI/CD runners, developer laptops, and private repos often hold the highest-value secrets. The result is a governance problem across human and machine identities, where access paths are distributed but accountability is still fragmented. Practitioners should assume their most sensitive secrets live where their least scrutinised automation runs.

Named concept: supply-chain credential persistence. This pattern describes stolen credentials that remain usable long enough to outlast detection, removal, or package cleanup. The attacker may lose the initial malicious package, but still retain access through copied tokens, cloud keys, or repository permissions. That means identity governance must be measured by how fast it can terminate usefulness, not just how well it can detect exposure.

Secret rotation must be tied to provenance and rebuild controls. Rotating tokens without rebuilding compromised artefacts leaves hidden paths intact, while rebuilding without revoking tokens leaves the attacker a second attempt. The right control model couples package verification, token revocation, and clean-source rebuilds into one response sequence. Practitioners should design incident playbooks around the attacker's remaining options, not only the detected package.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• Internal repositories are 6x more likely to contain secrets than public ones, which is why private build systems remain high-value targets for credential harvesting.
• Forward pivot: 28% of secrets incidents now originate outside code repositories, which is why Guide to the Secret Sprawl Challenge helps teams extend controls into chat and ticketing systems.

What this signals

Supply-chain credential persistence: the practical risk is not the initial package compromise but the window in which stolen secrets remain valid after exposure. That is where identity governance and software delivery meet, and it is why revocation speed matters as much as malware removal. Teams that align package controls with the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls will be better placed to terminate access before the attacker reuses it.

CI/CD runners and maintainer tools are becoming identity-rich attack surfaces. That means the next control conversation should focus on token ownership, short-lived publishing rights, and automatic invalidation after anomalous package activity, especially where build systems can reach production credentials.

The broader signal is that secrets governance must now extend beyond source code into package workflows, issue trackers, and developer collaboration channels. Organisations that only monitor repositories will keep missing the places where exposed credentials are actually created, copied, and reused.

For practitioners

• Revoke exposed tokens immediately Treat npm tokens, GitHub PATs, and cloud keys as compromised if they were present on an affected machine, runner, or maintainer account. Revocation should precede cleanup so the attacker loses reuse value before they can publish, clone, or pivot.
• Rebuild from clean sources and artefacts Remove tainted package versions, then rebuild affected projects from a trusted source repository and artifact store. Do not rely on package deletion alone, because malicious code may already have altered downstream build outputs or release artefacts.
• Inventory maintainer-scoped NHIs Map which service accounts, publishing tokens, and developer credentials can publish packages or modify workflows. Assign owners, rotation intervals, and emergency offboarding steps so maintainer access is not left as an untracked standing privilege.
• Inspect for the Shai-Hulud indicator Search GitHub organisations and CI/CD logs for a repository named Shai-Hulud, then review its history for leaked secrets and follow-on compromise. Use it as an indicator of exfiltration, not just a curiosity in the attacker workflow.
• Tighten post-install execution controls Block or review package install hooks in environments that can reach secrets, especially CI/CD runners and build agents. If post-install execution is unavoidable, separate it from secret-bearing contexts and monitor for outbound exfiltration patterns.

Key takeaways

• This campaign shows that malicious packages are only part of the problem. The lasting risk comes from secrets and tokens that remain valid after the package is removed.
• The evidence points to a scalable supply-chain pattern, not an isolated malware event. Post-install execution, maintainer token abuse, and worm-like release propagation create repeated compromise opportunities.
• The most effective controls are lifecycle controls. Fast revocation, clean rebuilds, provenance checks, and maintainer access governance are the measures that shrink the attacker’s usable window.

Key terms

• Supply Chain Persistence: Supply chain persistence is the ability of an attacker to remain active by abusing trusted software distribution paths rather than staying on one host. It often relies on repeated publication, compromised maintainer access, or reusable automation secrets that let the attacker keep reintroducing malicious artifacts.
• Post-install script abuse: Post-install script abuse happens when malicious code runs automatically during package installation and performs actions before a developer can inspect the package. It is dangerous because the install step itself becomes the execution path, letting attackers harvest data or alter the system immediately.
• Maintainer-scoped NHI: A non-human identity tied to publishing, workflow, or repository maintenance rights rather than a human login session. These identities often hold elevated permissions in package ecosystems, which makes their lifecycle, ownership, and revocation critical to supply chain security.
• Worm-like Package Propagation: A self-spreading supply chain technique where a compromised package uses stolen access to publish more malicious packages under trusted namespaces. The threat is amplified because propagation is driven by legitimate publishing rights rather than by repeated intrusion attempts.

What's in the full analysis

LEGIT Security's full article covers the operational detail this post intentionally leaves for the source:

• A full list of impacted npm packages and versions so teams can validate their own dependency inventories.
• Specific detection and response steps for identifying the Shai-Hulud repository and reviewing its contents for leaked secrets.
• Practical guidance on rebuilding compromised projects from clean sources and artifact repositories.
• The vendor's notes on using secrets scanning to identify which credentials should be revoked first.

👉 The full LEGIT Security article includes the impacted package list, exfiltration indicators, and response guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It is designed for practitioners who need to turn identity risk into operational controls across modern delivery pipelines.