Shai-Hulud shows how npm supply chain attacks harvest secrets

At a glance

What this is: This is a software supply chain attack on npm packages that turned dependency installs into secret-harvesting and exfiltration events.

Why it matters: It matters because identity teams must treat package publishing, maintainer access, and developer credentials as part of the same governance surface as code integrity.

By the numbers:

• The campaign targeted more than 50 npm packages at the time of writing.

Context

npm supply chain attacks now reach beyond package tampering and into identity compromise. When a package install can execute injected code, the attacker is no longer limited to altering software artifacts; they can inspect the local environment, collect tokens, and use those secrets to widen access.

The governance gap is straightforward: dependency controls often stop at provenance checks and version pinning, while the real exposure sits in the credentials available to build agents, developer workstations, and publishing workflows. That makes this an NHI problem as much as a software integrity problem.

Key questions

Q: What should teams do after a malicious npm package has run in CI/CD?

A: Contain the build environment, assume secrets on that system are exposed, and rebuild from a known-good baseline before restoring access. Then rotate npm tokens, cloud keys, SSH keys, and pipeline secrets that were reachable from the compromised host. The goal is to remove attacker persistence before any cleanup can be trusted.

Q: Why do NPM supply chain attacks create an identity risk as well as a code risk?

A: They become an identity risk because malicious packages often target the secrets and credentials available to build jobs, developer machines, and CI/CD pipelines. If those environments hold long-lived tokens or broad access, the compromise can move beyond code execution into authenticated reuse. That is why secrets scope and workload identity matter in supply chain defence.

Q: What are the signs that a supply chain compromise has moved from package tampering to secret theft?

A: Look for unusual package republishing, unexpected install scripts, new workflow files, outbound connections from build hosts, and unexplained secret rotation alerts. Those signals indicate the attacker is harvesting credentials or establishing persistence rather than only modifying code. The earlier those signs are caught, the smaller the blast radius.

Q: How should organisations compare package signing and secret management in npm risk reduction?

A: Package signing helps verify artifact integrity, but it does not protect secrets that are already present when a malicious install runs. Secret management reduces what the attacker can collect if execution occurs. Teams need both controls because provenance and credential exposure are separate failure points.

Technical breakdown

Injected install scripts turn package trust into execution trust

The attack inserted a minified JavaScript payload into compromised npm packages so that a routine install triggered attacker-controlled code. That script could modify package contents, repack the archive, and republish it under the maintainer’s namespace, creating a self-propagating pattern across downstream dependencies. In practical terms, the risk is not just malicious code in a package, but unauthorized code execution in the context of the build or developer environment. Once install-time execution is granted, the package stops being a static artifact and becomes a runtime delivery mechanism.

Practical implication: Treat package installation as code execution and block untrusted postinstall or republish paths where possible.

Secret harvesting targets the full developer identity surface

The malware searched environment variables, scanned files with TruffleHog, and queried cloud SDKs to collect secrets such as GitHub, npm, AWS, Google Cloud, and Azure credentials. That matters because modern developer environments concentrate reusable secrets that can outlive the package install itself. This is not simply data theft from one machine; it is a path to credential reuse across source control, CI/CD, and cloud control planes. In NHI terms, the compromised package becomes an opportunistic collector of standing privilege already present in the environment.

Practical implication: Reduce exposed secrets in developer and build environments, and assume install-time code will try to enumerate them.

Persistence and exfiltration extend compromise beyond the first install

After collection, the malware planted a malicious GitHub Actions workflow that could run on pushes and transmit repository secrets back to the attacker. It then bundled the stolen data into JSON and uploaded it to a public GitHub repository named Shai-Hulud. That shows a common supply chain pattern: initial execution creates a persistence foothold, and the foothold turns into repeated secret theft until the malicious artifact is removed. For defenders, the important point is that package compromise can become repository compromise if workflow secrets and automation tokens are reachable.

Practical implication: Review CI/CD workflows as part of supply chain response, not just the compromised package version.

Threat narrative

Attacker objective: The attacker wanted to harvest reusable developer and cloud credentials, then use package republishing and workflow persistence to widen access and exfiltrate secrets at scale.

1. Entry occurred when malicious JavaScript was injected into npm packages and executed automatically during installation.
2. Credential theft followed as the payload scanned environment variables, local files, and cloud SDKs for secrets and tokens.
3. Persistence was established by planting a GitHub Actions workflow that could continue sending secrets on subsequent pushes.
4. Impact came from publishing the collected data to a public GitHub repository and spreading the compromise through republished packages.

Breaches seen in the wild

• Solana web3.js npm compromise 2024: A phished maintainer's npm access let attackers publish two @solana/web3.js versions that stole private keys from bots and apps.
• Lottie Player npm compromise 2024: A compromised developer npm token let attackers publish three Lottie Player versions that pushed a crypto wallet drainer to websites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package integrity is now an identity control problem, not just a software supply chain problem. The attack succeeded because trusted package installation provided code execution inside environments that already held reusable secrets. That shifts the control discussion from artifact validation alone to the identities and credentials reachable at install time. Practitioners should treat maintainer access, CI tokens, and developer secrets as a single exposure surface.

Standing developer credentials create the blast radius that supply chain attackers need. The malware did not need exotic privilege escalation if GitHub, npm, and cloud tokens were already available in environment variables or local tooling. That is the core governance failure: secrets that are convenient for automation are also convenient for adversaries once execution is lost. Identity teams should interpret this as a secrets management and lifecycle issue, not a narrow malware event.

Self-propagating npm compromise exposes a weak assumption in dependency governance. The assumption that package provenance and version control are enough was built for malicious code detection, not for hostile code that republishes itself and hunts for secrets after install. That assumption fails when the package can act on the local environment and amplify reach through maintainer-owned namespaces. The implication is that dependency trust must be analysed alongside the credentials available to the install context.

GitHub Actions persistence shows how supply chain compromise crosses into repository governance. Once the malware could plant workflows, the attack moved from one-time package infection to repeated secret exfiltration on future pushes. That means repository and pipeline controls are part of supply chain response, not separate disciplines. Security teams should align package monitoring, workflow review, and secret revocation as one containment boundary.

Ephemeral package trust debt is the right concept for this campaign. A single compromised release can create a short but intense exposure window in which secrets are harvested, repackaged, and distributed faster than most review cycles can react. The practical lesson is that dependency governance must be built around the speed of install-time compromise, not the slower cadence of manual package vetting.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

What this signals

Secret exposure begins at install time, not after a breach is visible. When package code can inspect environment variables and local tooling, the main governance question becomes what secrets are present in the execution context at that moment. That is why package controls and NHI controls now overlap in every developer workflow.

Dependency governance needs to account for package-initiated credential collection. A malicious package does not need direct access to a production system if it can harvest reusable tokens from a build host or developer workstation. The practical consequence is that secret scope, location, and lifetime matter more than the package label itself.

For practitioners

• Audit package-install execution paths Block or tightly control postinstall and republish behaviour in build and developer environments so package installation cannot execute arbitrary scripts without review.
• Reduce reachable secrets in dev and CI Remove long-lived GitHub, npm, and cloud credentials from local environments and pipelines where package code can enumerate them during install.
• Inventory affected dependencies immediately Identify every direct and transitive use of the compromised npm versions and isolate systems that may have installed them during the attack window.
• Rotate exposed maintainer and cloud credentials Assume any token or key available to affected developers, repositories, or CI jobs may have been harvested and revoke it before reuse.
• Review repository workflows for persistence Search for new or altered GitHub Actions files and other automation that could continue exfiltrating secrets after the package is removed.

Key takeaways

• The campaign shows how npm compromise can become credential compromise when install-time code reaches developer and cloud secrets.
• The attack affected packages with over 2.5 billion total downloads and left only a short containment window, which shows how fast supply chain exposure can spread.
• The most effective limiters are tighter install-time execution controls, fewer reusable secrets in build paths, and faster revocation of any exposed credentials.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
• Dependency Republish Abuse: Dependency republish abuse occurs when compromised package code modifies itself or related artefacts and publishes new malicious versions under trusted package namespaces. The result is propagation through legitimate update mechanisms, which can expand exposure faster than manual review cycles can respond.

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 building or maturing an IAM programme, it is worth exploring.