Shai-Hulud shows how npm supply chain attacks harvest secrets

At a glance

What this is: This is an analysis of a self-propagating npm supply chain attack that used compromised packages to steal secrets and spread to downstream projects.

Why it matters: It matters because package compromise can become identity compromise at scale, forcing IAM, NHI, and platform teams to treat dependency pipelines as credential-bearing attack surfaces.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

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

Context

npm supply chain attacks now function as identity attacks because compromised packages can harvest credentials during routine installs. In this case, the malware inserted a script that repackaged infected dependencies, scanned developer environments for secrets, and republished altered packages so the compromise spread downstream.

The governance gap is not just package trust. It is the assumption that software build and developer environments are separate from credential-bearing identity systems, when in practice npm tokens, GitHub tokens, cloud keys, and CI secrets all sit inside the same blast radius.

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 npm supply chain attacks create such a large IAM risk?

A: Because npm, GitHub, and cloud credentials often coexist in the same developer and build environments. A single compromised package can therefore expose multiple identity planes at once, including source control, workload access, and cloud control surfaces. The risk grows when secrets are reusable, long-lived, or readable from default install contexts.

Q: How do security teams know if package compromise has become a secret exposure event?

A: They look for install-time script execution, unexpected package republishing, workflow files added to repositories, and any evidence that credentials were present in the affected environment. If the package could reach tokens, keys, or session material, then incident scope must include rotation and revocation, not just removal of the package version.

Q: Who should own containment when a dependency attack exposes cloud and repository credentials?

A: Containment should be joint ownership between application security, IAM, cloud security, and platform engineering. The package owner can remove the malware, but only identity owners can revoke tokens, rotate keys, invalidate sessions, and review access paths that the stolen secrets may have opened.

Technical breakdown

How the injected npm payload propagates through republished packages

The attack begins when a malicious script runs during package installation and modifies the package archive before republishing it. That turns a single compromised maintainer account or package update into a propagation mechanism, because downstream consumers automatically inherit the altered dependency. The key technical feature is self-propagation through normal distribution paths, which makes trust in the registry itself part of the attack surface. Once republished, the malicious package can infect other packages owned by the same maintainer and broaden the campaign without additional manual intrusion.

Practical implication: treat dependency publish rights and package integrity checks as security controls, not release formalities.

Secret harvesting from developer machines and build environments

The malware does not need deep system compromise to be useful. It enumerates environment variables, scans filesystems for credentials, and targets common secrets such as npm tokens, GitHub tokens, and cloud access keys. That is classic secret abuse in an NHI context: the attacker is not breaking authentication in the abstract, but stealing reusable credentials that already carry access. Because these secrets often authorize more than the package registry itself, one infected install can expose cloud, source control, and CI access in a single pass.

Practical implication: scope secrets to the narrowest possible workload and monitor where they are readable during build and install steps.

Why public exfiltration turns a package attack into an access crisis

The campaign reportedly bundled collected data into a JSON file and uploaded it to a public GitHub repository. That creates a second-order risk: exposed secrets can be harvested by other actors long after the original infection is removed. In identity terms, the exposure window becomes the incident, because stolen secrets remain valid until rotation, revocation, and offboarding complete. This is why package compromise must be handled as an access event, not only a malware cleanup exercise.

Practical implication: pair package removal with immediate secret rotation, token revocation, and repository workflow review.

Threat narrative

Attacker objective: The attacker wants durable access to developer, cloud, and CI environments by stealing secrets that can be reused after the package infection is removed.

1. Entry via a malicious JavaScript bundle that executes during npm install and modifies the affected package before republishing it.
2. Credential exposure through scanning of environment variables, files, and cloud SDK-backed secret stores for npm, GitHub, and cloud access keys.
3. Impact through public exfiltration of collected secrets to a GitHub repository, extending the blast radius beyond the original infected hosts.

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 compromise has become an identity event, not just a software integrity problem. The important detail in this campaign is not only that packages were modified, but that the attacker used them to collect reusable credentials from developer and cloud environments. That collapses the boundary between software supply chain security and IAM governance, because the stolen artefacts are secrets, tokens, and keys. Practitioners should read this as an access-control failure with a code-distribution wrapper.

Ephemeral package trust is a distinct control gap. The attack succeeded because install-time execution was trusted to run with access to developer context and repository secrets. That is a governance weakness in the npm ecosystem, where one package update can inherit broad local trust without meaningful runtime segmentation. The implication is that package trust has become time-bound and contextual, not static.

Secret sprawl is the real blast-radius multiplier. Once the malware can reach GitHub tokens, npm tokens, AWS keys, and CI secrets from the same execution path, the compromise is no longer confined to one repository or one developer workstation. This is where NHI governance meets software supply chain management: the more places a secret can authenticate, the more places a single infected package can reach. Security teams should treat this as identity sprawl with execution privileges.

Maintainer compromise and developer compromise now feed the same threat pattern. A stolen maintainer account can poison packages, while a poisoned package can steal the secrets needed to move into source control and cloud environments. That means governance must span human, NHI, and build identities together instead of assuming they fail separately. The practitioner conclusion is simple: identity boundaries must be enforced where packages are published, installed, and executed.

Shai-Hulud is a named concept for self-propagating secret theft through package republishing. The campaign shows that malicious code can persist by rewriting the distribution channel itself, then using harvested credentials to widen its own reach. That is more than a malware family pattern. It is a reproducible identity abuse model that turns package trust into secret transport. Teams should design controls for propagation, not just detection after installation.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a deeper breach-pattern lens, see 52 NHI Breaches Analysis, which connects secret exposure to real-world identity compromise patterns.

What this signals

Secret exposure windows are now measured in minutes, not days. For organisations running package-heavy build pipelines, that means containment has to be automated around detection, revocation, and workflow quarantine. If exposed credentials remain usable for even a short period, the attacker can pivot from install-time compromise into cloud and source-control access before the incident team finishes scoping it.

Dependency integrity and identity hygiene now have to be governed together. Package controls matter, but they will not contain the blast radius if developer workstations and CI systems still hold high-value secrets. The practical shift is to treat build environments as credential-bearing identities and enforce least privilege across repository, cloud, and registry access paths.

The next maturity step is to align software supply chain monitoring with NHI governance, using sources like the OWASP Non-Human Identity Top 10 and the Top 10 NHI Issues to frame where package-driven secret abuse fits into broader identity risk.

For practitioners

• Inventory every dependency and transitive package Maintain an up-to-date software bill of materials and know which versions are installed in CI, developer workstations, and production build images. If a package is flagged, you need immediate reachability data to identify exposure scope before secrets rotation begins.
• Separate package publishing from secret-bearing workflows Remove npm tokens, GitHub tokens, and cloud keys from environments that only need to build or test. Use distinct duty-bound accounts and keep publishing rights out of ordinary developer sessions so a malicious install cannot inherit broad authority.
• Rotate exposed secrets as a containment step, not a cleanup task Assume any token or key accessible during the infected install may have been harvested, then revoke and replace it immediately. That includes repository secrets, cloud access keys, session tokens, and any credential that can authenticate outside the package ecosystem.
• Block unexpected package behavior in pipelines Inspect install-time scripts, republished package diffs, and unusual outbound connections from build and developer environments. Package trust should be conditional on behaviour, not just version numbers or registry presence.
• Constrain repository workflows that can re-expose secrets Review GitHub Actions and similar automation for any workflow that can read secrets on push or run without strong branch protections. Infected packages become worse when they can plant persistence in repository automation.

Key takeaways

• This campaign shows that npm supply chain attacks are also credential theft events, because malicious packages can read secrets from the environments where they are installed.
• The scale is material, with more than 2.5 billion package downloads exposed to a campaign that used only a short window before removal.
• The decisive control is not just package removal, but rapid secret rotation, token revocation, and tighter separation between build execution and identity-bearing credentials.

Key terms

• Software Supply Chain Attack: A software supply chain attack compromises trusted code, packages, or build systems so downstream users inherit the attack. In identity terms, it often becomes an access problem because the malicious code can reach secrets, tokens, or credentials that normal application logic should never see.
• Secret Exposure Window: The period between when a credential is first exposed and when it is revoked or rendered unusable. For NHI governance, this window matters because attackers often act within minutes, so delay in rotation or revocation directly increases blast radius.
• Package Integrity Control: A control that checks whether a dependency has been altered, republished, or executed in an unexpected way. It is not just about code provenance. It also limits whether install-time behaviour can access identity material, workflows, or cloud-connected secrets.
• Credential Harvesting: The act of collecting reusable authentication material such as tokens, keys, certificates, or session secrets from a system. In modern environments, credential harvesting often succeeds through low-friction access to build machines, developer laptops, and CI pipelines rather than through direct server compromise.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: LLMjacking style supply chain attack analysis of npm package compromise and secret theft. Read the original.