Mini Shai-Hulud shows how npm supply chain malware steals NHI secrets

At a glance

What this is: This is an analysis of a supply-chain compromise in SAP-related npm packages that used install-time execution to steal developer and cloud secrets.

Why it matters: It matters to IAM and NHI practitioners because package compromise now reaches identity controls, secret hygiene, CI/CD trust boundaries, and the lifecycle of machine credentials.

By the numbers:

• 27 days
• 17 minutes

👉 Read Aikido's analysis of Mini Shai-Hulud and SAP npm package compromise

Context

npm supply-chain attacks exploit trust in the installation path, where code can run before teams have verified what changed. In this case, the risk is amplified because the payload targets non-human identities, developer credentials, and cloud secrets at the point where software packages enter CI/CD and build workflows.

The primary governance failure is not just malicious code in a package. It is the assumption that developer tooling, package managers, and CI runners are outside the identity plane, when in practice they often hold the most sensitive machine credentials in the environment.

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 exposed secrets in CI/CD pipelines create such a large blast radius?

A: CI/CD systems often hold cloud credentials, deployment tokens, and repository access in the same execution context. When malicious code runs there, it can collect secrets from environment variables, files, and process memory, then reuse them across cloud and source control. The more privileged the runner, the larger the downstream impact.

Q: How do security teams know whether NHI provisioning is actually governed?

A: Look for three signals: every identity has an owner, every secret lands in an approved storage path, and every new object appears immediately in inventory and lifecycle workflows. If any of those is missing, provisioning is still operating as a delivery process rather than a governance process.

Q: Who is accountable when a supply chain package steals credentials and machine access?

A: Accountability usually sits across engineering, platform security, and identity teams because the failure spans software intake, endpoint execution, and credential governance. The right control owners are the teams that approve package trust, manage secret lifecycles, and define which identities may exist on developer workstations.

Technical breakdown

How preinstall hooks turn package install into execution

npm lifecycle hooks allow package code to run during installation, before the operator has completed review or validation. A malicious preinstall script can drop helper files, launch a loader, and execute an obfuscated payload while appearing to be part of normal dependency resolution. That makes package integrity, not just package provenance, the key security question. In this incident, the added files were more important than the visible package code because they triggered runtime execution on install.

Practical implication: treat install-time scripts as executable trust decisions and block or inspect them in high-risk build paths.

Why secret stealers focus on developer and CI identities

Supply-chain malware targets the identities that already have reach: npm tokens, GitHub tokens, cloud credentials, Kubernetes service account tokens, and CI secrets. Those credentials are not interchangeable. Each one can unlock a different control plane, and together they create a cross-environment blast radius that extends from developer laptops into release pipelines and cloud accounts. Once stolen, secrets become reusable identity artifacts unless they are revoked, rotated, and scoped tightly enough to limit lateral movement.

Practical implication: map each secret to its owning control plane and revoke it as an identity asset, not as a simple file leak.

How GitHub can become both exfiltration path and propagation channel

This campaign uses GitHub in two ways. First, it exfiltrates encrypted results into public repositories. Second, it searches for commit-message markers that encode tokens and then uses those tokens to access or modify additional repositories. That creates a self-propagating loop where source control is both the evidence store and the transport layer. For defenders, repository permissions and commit hygiene become part of secret containment, not just code management.

Practical implication: monitor repository creation, unusual commit markers, and automation tokens with the same urgency as cloud credential abuse.

Threat narrative

Attacker objective: The attacker wants to harvest reusable non-human credentials, propagate through trusted package workflows, and exfiltrate secrets from developer and cloud environments at scale.

1. Entry begins when a trusted npm package is modified to run a malicious preinstall hook during installation.
2. Credential access follows as the payload steals developer tokens, CI secrets, cloud credentials, and Kubernetes service account material from machines and runners.
3. Escalation occurs when stolen GitHub and CI credentials are reused to create repositories, exfiltrate results, and modify packages for further spread.
4. Impact is broader ecosystem propagation, with compromised packages distributing the same secret-stealing logic into additional developer and release environments.

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 sprawl is now an identity-risk problem, not just a hygiene problem. This campaign shows how package managers, CI runners, and developer workstations have become repositories of reusable non-human identities. When tokens, service accounts, and cloud credentials sit across multiple execution surfaces, compromise of one package can expose the governance gap between software supply chain security and identity lifecycle control. The practical conclusion is that secret governance must be treated as identity governance.

The real failure mode is standing trust in installation paths. Preinstall execution means a dependency can act before the environment has any meaningful opportunity to inspect it. That undermines assumptions in traditional change control and leaves developers, build systems, and release automation exposed to runtime credential harvesting. Installation-path trust gap: a package install event is being treated as low-risk even though it can execute arbitrary code with live access to secrets. Practitioners should treat dependency installation as a privileged execution event.

Non-human identities in CI/CD need lifecycle controls, not just detection. The article’s strongest signal is that stolen credentials were useful precisely because they were valid, reachable, and tied to automation. Rotation alone is insufficient if tokens are over-scoped, long-lived, or shared across build contexts. The discipline now is to tie every secret to an owner, a purpose, an expiry, and a revocation path. That is standard IAM thinking applied to machine identities.

Source control is becoming part of the secret-exfiltration surface. Using GitHub repositories as a dead-drop for encrypted output turns collaboration tooling into an operational channel for attackers. That changes what counts as suspicious activity in engineering environments, because repository creation, commit metadata, and automation tokens now have direct security meaning. The practitioner takeaway is to monitor source control telemetry as identity telemetry, not just development telemetry.

AI and developer tooling widen the attack surface for secrets theft. The payload’s interest in Claude configuration, MCP configuration, and local developer tooling shows that modern software environments now blend human, machine, and AI-assisted workflows. That creates a broader identity boundary than most enterprises have formally defined. Teams that have not mapped those adjacent identities will miss where compromise begins and how far it can travel.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Forward look: Secrets exposure linked to LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how fast exposed credentials can be operationalised.

What this signals

Installation-path trust is becoming a measurable identity-risk boundary. Once packages can execute code at install time, the line between software delivery and credential compromise disappears. Security teams should expect greater pressure to treat build systems, developer laptops, and package registries as identity-bearing assets, with controls aligned to OWASP Non-Human Identity Top 10 and source-control telemetry.

Build pipelines now need secret containment, not just secret detection. The key programme shift is to assume that any secret present in a CI job is already at risk of reuse by an attacker. That means narrowing token scope, isolating release identities, and making revocation fast enough to matter in minutes, not days. The best signal is whether your organisation can invalidate machine access faster than attackers can operationalise it.

Source-control behaviour is part of modern identity governance. Repository creation, commit authorship, automation tokens, and secret-sharing patterns all reveal whether a machine identity is being abused. Teams that already monitor this through the NIST SP 800-53 Rev 5 Security and Privacy Controls lens will detect misuse earlier than teams that still treat source control as purely a developer concern.

For practitioners

• Block install-time execution in high-risk repositories Restrict or inspect npm lifecycle scripts such as preinstall in CI and release pipelines, especially where package installs can access secrets, tokens, or cloud metadata. Combine policy enforcement with allowlists for trusted build steps.
• Rotate every secret touched by package compromise If a malicious dependency was installed, rotate GitHub tokens, npm tokens, cloud provider keys, Kubernetes service account tokens, and any CI secrets that were present on the affected host or runner.
• Separate build identities from developer identities Use dedicated build accounts with narrowly scoped permissions, short lifetimes, and isolated secret stores so a compromised workstation cannot directly access release or cloud control planes.
• Monitor source control for dead-drop patterns Alert on unusual repository creation, suspicious commit markers, and unexpected automation-authored changes that may indicate secret exfiltration or malware propagation through GitHub.
• Track AI and developer tooling secrets as NHI assets Inventory Claude config, MCP config, local token caches, and other developer-side credentials as non-human identities with explicit ownership, expiry, and revocation processes.

Key takeaways

• This incident shows that supply-chain malware is now a non-human identity problem because compromised packages can steal the credentials that govern cloud, CI, and developer access.
• The scale of the risk is amplified by slow secret remediation and overconfidence in secrets management, which gives attackers a long reuse window after exposure.
• Teams should respond by treating install-time execution, secret lifecycle ownership, and source-control telemetry as part of the same identity control plane.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs automatically before dependency installation completes. In supply-chain attacks, it becomes a stealth execution point that can access secrets, modify files, or launch follow-on payloads while the package still looks legitimate to the installer.
• 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.
• Secret Stealer: A secret stealer is malware designed to locate and extract credentials from files, memory, environment variables, and configuration stores. Its value to attackers is reuse, because stolen secrets often unlock cloud services, source control, and automation systems with little immediate friction.
• Build Pipeline Trust Boundary: A build pipeline trust boundary is the point where code, credentials, and automation meet during software delivery. It is a control boundary because compromise there can spread from package installs into release systems, repositories, and cloud environments if secrets are present and privileges are broad.

What's in the full analysis

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

• File-level indicators of compromise, including the malicious setup.mjs and execution.js artifacts.
• The exact GitHub commit markers and repository naming patterns used for exfiltration and propagation.
• Step-by-step detection logic for identifying affected packages in lockfiles, caches, CI logs, and internal registries.
• Manual rescan and rotation guidance for environments that may have executed the malicious install path.

👉 Aikido's full post covers the attack chain, indicators of compromise, and cleanup guidance

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 in a way that supports real-world identity programmes. It is designed for practitioners who need to connect identity controls to operational security across modern environments.