Shai-hulud npm attacks expose why NHI controls still fail

At a glance

What this is: This is an analysis of a large npm supply-chain attack that used compromised maintainer credentials, malicious package updates, and GitHub repositories to exfiltrate secrets at scale.

Why it matters: It matters because NHI controls must now account for package trust, CI/CD execution, and secret exposure as one attack surface rather than separate domains.

By the numbers:

• Over 800 packages were poisoned in the late-November Shai-Hulud wave.

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

Context

The core problem is trust in software dependencies that can execute before teams notice what changed. In NHI terms, the package manager, the CI pipeline, the developer workstation, and the secrets stored in those environments all become part of the same identity and access path when malicious code runs with inherited privileges.

That makes this incident more than a supply-chain event. It is a governance failure for non-human identities because credentials, tokens, certificates, and automated runners were exposed through normal build behaviour, not through a single stolen login. The starting position here is increasingly typical for modern development, which is why the control gap matters.

Key questions

Q: How should security teams handle npm packages that run code during install?

A: Security teams should treat install-time scripts as executable code and restrict them by policy. That means allowlisting trusted packages, blocking unnecessary lifecycle hooks, and testing dependency changes in isolated environments before they reach CI. The main goal is to prevent package installation from becoming a hidden execution path for secret theft.

Q: Why are CI/CD systems such high-value targets for NHI abuse?

A: CI/CD systems often hold cloud keys, API tokens, and repository credentials in one place, which makes them efficient targets for attackers seeking multiple reusable secrets. Once malicious code executes there, it can harvest identity material at scale. That is why build environments need tighter segmentation than general developer workstations.

Q: What is the difference between secret rotation and secret containment?

A: Secret rotation replaces exposed credentials after compromise, while secret containment reduces how far those credentials can reach in the first place. Rotation is reactive and necessary, but containment lowers the blast radius by separating build, deploy, and cloud access. Strong NHI governance needs both, because rotation alone does not stop repeated exposure.

Q: When should organisations revoke GitHub runners and other automation workers?

A: Organisations should revoke automation workers whenever they cannot verify registration, attestation, or recent behaviour after an incident. A runner can function as a persistent access point even after the original malware is removed. If a worker identity is uncertain, it should be treated as compromised and rebuilt from a clean baseline.

Technical breakdown

How malicious npm packages become NHI entry points

npm packages can execute code during install through lifecycle scripts such as preinstall and postinstall. That matters because developers often treat dependency installation as passive, but these hooks run with the same environment access as the local user or build agent. In a CI/CD context, that can include cloud credentials, repository tokens, and environment variables. If attackers compromise maintainer credentials, they can republish a trusted package and turn routine installation into code execution. The key NHI issue is not the package alone. It is the inherited trust chain from publisher to registry to build system to secrets store.

Practical implication: Restrict lifecycle scripts and treat package installs as execution events, not simple downloads.

Why secret harvesting in build environments scales so quickly

Build systems concentrate secrets because they need access to registries, clouds, and source control. Once attacker code runs in that environment, it can enumerate files, environment variables, cached credentials, and tool outputs without needing separate privilege escalation. The article describes use of TruffleHog, which reflects a broader pattern: adversaries automate secret discovery immediately after entry so that one compromise yields multiple reusable credentials. In NHI terms, that creates a blast-radius problem. One poisoned dependency can expose many non-human identities at once, including cloud keys and automation tokens.

Practical implication: Segment build-time secrets, shorten credential lifetimes, and monitor for mass token exposure after dependency execution.

How persistence is created through rogue GitHub runners

A GitHub runner is a worker that executes jobs from Actions workflows. When attackers register a rogue runner on victim machines, they can preserve access even after the initial malicious package is removed. That persistence matters because the runner becomes a trusted execution target inside the automation plane, which can receive future jobs or be used to collect additional data. This shifts the incident from one-time theft to durable control of the automation layer. For NHI governance, the runner is an identity with execution authority and therefore needs the same registration, attestation, and revocation discipline as other privileged workloads.

Practical implication: Inventory and revoke unauthorized runners as part of incident response, and require attestation for all automation workers.

Threat narrative

Attacker objective: The attacker objective was to extract reusable non-human credentials at scale and preserve access to affected automation environments.

1. Entry occurred through poisoned npm packages republished with stolen maintainer credentials and executed during install.
2. Escalation happened when install-time code harvested tokens, cloud keys, and environment variables from developer and CI systems.
3. Impact followed when stolen secrets were uploaded into public GitHub repositories and rogue runners created persistent access.

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

Package trust has become an identity problem, not just a software integrity problem. When a malicious dependency can inherit execution rights inside a build system, the real control question is whether the organisation can verify who or what is authorised to run. NHI governance must therefore extend to package registries, build hooks, and automation workers. Practitioners should treat dependency execution as an access decision, not merely a code-review concern.

Ephemeral build environments still leak durable access when secrets are long-lived. The incident shows that short-lived execution does not matter if the environment contains reusable keys, tokens, or cloud credentials. That combination creates ephemeral credential trust debt, where a temporary process can expose identities that outlive the process itself. Teams should reduce the standing value of every secret that touches CI/CD.

Identity blast radius is now the metric that matters most in supply-chain incidents. The attack did not need to compromise the entire enterprise to be damaging. It needed only enough access to turn trusted automation into a secret-extraction channel. That means detection speed is useful, but containment through least privilege, runner control, and secret segmentation is the real determinant of loss. Practitioners should measure how many identities a single build can expose.

Security teams need to stop separating developer tooling from NHI governance. Package managers, GitHub runners, cloud tokens, and environment variables are all parts of the same identity system when automation is involved. A control model that leaves any one of them outside governance will keep failing in the same way. The right response is unified policy across dependency execution, secret handling, and workload identity.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to the State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history, according to the State of Secrets Sprawl 2025.
• For a broader supply-chain lens, see the 52 NHI breaches Report for recurring identity and secret exposure patterns across real incidents.

What this signals

Secret exposure is now a baseline operating condition for modern software delivery. With 4.6% of public GitHub repositories already containing at least one hardcoded secret, per the State of Secrets Sprawl 2025, teams should assume package-related incidents can expose live credentials unless controls are built into the pipeline itself. The practical shift is toward reducing secret value, not only improving detection speed.

Ephemeral execution does not eliminate identity risk when the environment is reusable. CI workers, build caches, and developer tools can all become amplification points if they share the same credentials. The next governance step is to treat automation workers as first-class non-human identities and place them inside a revocation and attestation model, not an informal DevOps exception.

Identity blast radius should become a board-level metric for software supply-chain resilience. The question is no longer whether a package can be malicious, but how much access one execution path can expose before containment begins. Teams that can answer that quickly will be better positioned to limit both operational disruption and secret reuse across downstream systems.

For practitioners

• Restrict dependency execution in build pipelines Disable or tightly control preinstall and postinstall scripts, and require allowlisted packages or reviewed exceptions for any install-time code execution.
• Rotate exposed non-human credentials immediately Assume tokens, cloud keys, and certificates on affected developer and CI systems are compromised and replace them before reusing any environment.
• Audit and revoke rogue automation workers Inventory GitHub runners, CI agents, and other automation workers, then remove any unapproved runner registrations and reattest trusted ones.
• Segment secret access by build stage Separate source control, build, and deployment credentials so one compromised package cannot expose the full set of non-human identities.
• Scan for secret sprawl after every package incident Search repositories, logs, caches, and artifact stores for reused credentials, then validate that remediation removed all reachable copies.

Key takeaways

• Trusted npm dependencies can function as execution channels for secret theft, which makes package hygiene a non-human identity control problem as much as a software supply-chain issue.
• The scale of exposure comes from concentrated build credentials, reusable tokens, and automation workers that share too much privilege.
• Practitioners should reduce blast radius through script controls, secret segmentation, runner attestation, and immediate rotation after any dependency incident.

Key terms

• Non-Human Identity: A non-human identity is any machine account, token, key, certificate, bot, workload, or automated agent that can authenticate and act in a system. These identities often outnumber human users and need separate lifecycle, privilege, and revocation controls because they are created and consumed by software.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems that can be reached if one credential or automation path is compromised. In NHI environments, the size of that blast radius is often determined by shared secrets, overprivileged runners, and weak segmentation.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, logs, caches, build systems, and collaboration tools. It increases the chance that one compromise exposes many usable non-human identities, which is why discovery, rotation, and storage discipline must be treated as core governance tasks.
• Automation Worker: An automation worker is a build agent, CI runner, or similar execution environment that processes jobs on behalf of software systems. Because it can inherit broad access to source control and cloud services, it must be managed as a privileged non-human identity rather than a disposable utility.

Deepen your knowledge

NHI supply-chain risk and automation trust boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening CI/CD governance after a package compromise, it is worth exploring.

This post draws on content published by Backslash Security: Shai-Hulud Strikes Again: Massive npm Attack Exposes Thousands of Secrets. Read the original.