Shai-Hulud 2 shows how npm supply chain malware reaches secrets

At a glance

What this is: This is an analysis of Shai-Hulud 2, an npm supply chain malware wave that uses preinstall scripts to harvest secrets from developer and CI/CD environments.

Why it matters: It matters because npm package compromise can turn routine dependency installs into credential theft across CI/CD, cloud access, and developer workflows, which directly affects NHI governance and secrets control.

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.
• 27 days
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Apiiro's analysis of Shai-Hulud 2 and npm secret theft

Context

npm supply chain attacks become especially dangerous when installation-time code can run in developer laptops, CI jobs, and build systems without meaningful scrutiny. In this case, the key failure is not simply malicious package publication, but the trust placed in lifecycle scripts and the broad blast radius of secrets stored in local environments, cloud tooling, and automation.

For identity and access teams, the important issue is that stolen secrets are often non-human identities in practice: API tokens, SSH keys, cloud credentials, and CI/CD variables that carry real access without strong lifecycle governance. This pattern sits at the intersection of software supply chain security, NHI control, and privileged access hygiene.

The starting position here is not atypical. Many organisations still treat dependency install paths as developer-only events, even though they can execute code with access to production-adjacent credentials.

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 developer secrets make supply chain incidents much harder to contain?

A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.

Q: How do security teams know when secret sprawl is becoming unmanageable?

A: When they cannot confidently answer where each secret exists, which workloads depend on it, and how quickly it can be retired without breaking business services. If the answer requires manual archaeology across code, tickets, and pipelines, the sprawl is already beyond routine control.

Q: Who is accountable when a compromised package exposes cloud or developer secrets?

A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.

Technical breakdown

Why preinstall scripts are a high-risk execution path

npm lifecycle scripts can execute automatically during package installation, which makes preinstall especially dangerous because it runs before many teams inspect package contents. Attackers abuse that trust boundary by hiding malicious logic inside seemingly ordinary dependencies and using obfuscation or alternative runtimes to reduce detection. In supply chain terms, the package is not only code to be consumed, but a delivery mechanism for runtime execution inside trusted build and developer environments.

Practical implication: restrict lifecycle script execution in CI and subject dependency installs to policy-based inspection before code runs.

How secrets are harvested from developer and CI environments

Once the malicious script executes, it can enumerate environment variables, configuration files, local caches, and authentication material stored by tooling. That includes API tokens, SSH keys, cloud access keys, npm credentials, and secrets embedded in workspace files. The real risk is not just disclosure of a single credential, but the transfer of multiple identities from one environment into attacker-controlled infrastructure, which enables downstream access, persistence, and impersonation.

Practical implication: treat developer and CI secrets as live credentials with exposure paths, not as static configuration data.

Why exfiltration to attacker repositories amplifies the incident

Using attacker-controlled GitHub repositories gives the campaign a durable collection point and an easy way to structure stolen material for later abuse. That turns an initial compromise into a repeatable harvesting system where exfiltrated secrets can be indexed, searched, and operationalised at scale. The fallback destructive behaviour described in the article adds pressure, but the primary effect is credential concentration that expands the blast radius across unrelated systems and teams.

Practical implication: monitor for unexpected repository creation and repo-level workflow changes as indicators that credential theft has already occurred.

Threat narrative

Attacker objective: The attacker wants to convert a single dependency installation into broad credential harvesting that enables follow-on access across developer, CI/CD, and cloud environments.

1. Entry occurs when a victim installs a trojanised npm package that contains a malicious preinstall script.
2. Credential access follows as the obfuscated Bun payload steals API tokens, SSH keys, cloud access keys, and environment secrets from the execution context.
3. Impact occurs when stolen secrets are exfiltrated into attacker-controlled GitHub repositories and can be reused to access downstream systems, pipelines, and cloud resources.

NHI Mgmt Group analysis

Secret harvesting is now a supply chain outcome, not a side effect. This campaign shows that package compromise increasingly targets credentials rather than code integrity alone. Once installation-time execution reaches developer and CI environments, API tokens, SSH keys, and cloud access material become the primary prize. Practitioners should treat secrets exposure as the first-order business risk of dependency compromise.

Lifecycle script execution is a governance boundary, not just a build setting. Preinstall and similar hooks can turn dependency resolution into arbitrary code execution inside trusted environments. That makes script policy, registry trust, and build isolation part of identity governance for machine access. Teams that ignore this boundary leave non-human identities exposed to theft before any application logic is reached.

Shai-Hulud 2 sharpens the secret sprawl challenge. The article’s mechanics map directly to the broader problem of secrets scattered across local machines, pipelines, and repositories. Fragmented secret stores and inconsistent rotation practices make mass exfiltration far easier to monetise. The practical conclusion is that identity governance must extend from issuance to runtime use and rapid revocation.

The named failure mode here is installation trust collapse. Organisations assume package installation is a low-risk activity, but this attack turns it into a credential collection event. That assumption fails when dependency scripts can read environment secrets and create attacker-owned repositories before defenders notice. The right lens is not “malicious package detection” alone, but where the control plane for NHI secrets actually resides.

OWASP NHI guidance is directly relevant because the abused assets are machine identities. API tokens, cloud keys, and CI variables function as identities with privileges, not passive configuration values. This attack reinforces the need to govern creation, scope, rotation, and offboarding for every secret that can authenticate a workload or automation flow. Security teams should assess whether their NHI controls extend to developer tooling and build orchestration.

What this signals

Secret exposure now behaves like an identity incident, not a code hygiene issue. If a package install can surface authenticators for cloud and source control, then governance must move closer to the runtime boundary where those secrets are consumed. Teams should expect more pressure to connect software supply chain controls with OWASP Non-Human Identity Top 10 and NHI lifecycle management.

Runtime trust will become a differentiator in how organisations manage developer tooling. Build systems, dependency managers, and secret scanners will increasingly be judged by how quickly they can detect and revoke credential exposure, not just by whether they block known malware. The programme-level signal to watch is the time between exposure, detection, and invalidation.

Secret sprawl is the hidden multiplier in this campaign. When credentials are spread across multiple managers, local files, and CI variables, a single malicious package can reach far more than one application. That is why lifecycle governance, short-lived credentials, and the Secret Sprawl Challenge matter together.

For practitioners

• Block lifecycle script execution in high-trust pipelines Disable or tightly gate npm lifecycle scripts in CI and build environments, especially where dependency installs can reach secrets or signing material. Use allowlists and policy checks before any package script is permitted to run.
• Inventory every secret exposed to package installs Map API tokens, SSH keys, cloud credentials, npm tokens, and environment variables that are present during dependency resolution. Prioritise anything that can authenticate to cloud, source control, or deployment systems.
• Rotate credentials as a containment action, not a routine task If a compromised package may have run, rotate all affected secrets immediately and rebuild affected systems from trusted sources. Reimage developer workstations and clean CI runners when you cannot prove execution did not occur.
• Watch for attacker-owned GitHub repositories and workflow files Search for newly created repositories, suspicious workflow files under .github/workflows/, and structured JSON dumps of secrets such as cloud.json or truffleSecrets.json. These are strong indicators that exfiltration already occurred.
• Treat secret scanning as an identity control Combine secret scanning, branch protections, and automated revocation so leaked credentials are not merely detected but invalidated before reuse. The control objective is to reduce the window between exposure and attacker access.

Key takeaways

• Shai-Hulud 2 shows that npm supply chain malware can convert ordinary dependency installs into credential theft across developer and CI environments.
• The operational risk is amplified by machine identities such as API tokens, SSH keys, and cloud credentials, which attackers can reuse quickly once exposed.
• Teams need script controls, secret lifecycle governance, and rapid revocation to limit blast radius before stolen credentials are weaponised.

Key terms

• 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.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Supply Chain Malware: Malware delivered through trusted software distribution paths such as packages, dependencies, or build tooling. It succeeds by inheriting trust from legitimate workflows, which makes publication-time checks insufficient if the malicious behaviour appears only after install or in a later version.

What's in the full analysis

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

• Package-by-package indicators of compromise and the specific npm versions implicated in the campaign
• Step-by-step response guidance for validating whether Bun payloads executed in developer or CI environments
• Concrete repository and workflow artefacts to search for, including structured secret dumps and malicious .github/workflows files
• Apiiro's recommended hardening measures for CI, dependency handling, and secret handling in active delivery pipelines

👉 Apiiro's full post covers indicators of compromise, response steps, and hardening guidance for affected environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to real-world access risk across modern environments.