Shai-Hulud shows how npm supply chain attacks now self-propagate

At a glance

What this is: This is an analysis of a viral npm supply chain attack that used compromised maintainer credentials, post-install malware, and secret theft to spread across more than 180 packages.

Why it matters: It matters because software supply chain compromise now directly intersects with identity and secrets governance, especially where package maintainer accounts, CI tokens, and GitHub credentials are exposed.

By the numbers:

• The attack impacted over 180 packages across the npm ecosystem.
• The campaign began on September 15, 2025, and quickly escalated into one of the most significant npm compromises to date.
• The article lists 189 known-infected packages in the campaign.

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

Context

npm supply chain attacks exploit the trust model around published packages, maintainer accounts, and automated installation paths. When malicious code lands in a package that is widely consumed in build pipelines, the resulting exposure is not limited to code integrity. It can extend into secrets, source repositories, CI/CD systems, and downstream production environments, which is why package trust is now an identity and access problem as much as a software one.

This campaign matters because it shows how quickly credential abuse can turn a single maintainer compromise into ecosystem-wide propagation. The article’s subject is not just malware in a package, but the governance failure created when short-lived publishing trust, install-time execution, and secrets visibility are not controlled together. That is a typical weakness in modern development environments, not an edge case.

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 maintainer credentials make npm supply chain attacks so dangerous?

A: Maintainer credentials are effectively publishing identities, so reuse or theft lets an attacker publish malicious updates under a trusted package name. That bypasses ordinary dependency trust and can spread rapidly across downstream consumers, especially when package ownership controls and token lifecycle management are weak.

Q: What do teams get wrong about secrets in build automation?

A: Teams often assume build secrets are safe because the job is temporary, but the credential usually outlives the run. Once a token is stolen, it behaves like any other NHI with its own lifecycle, scope, and blast radius, so inventory, revocation, and rotation matter more than workflow speed.

Q: Who is accountable when a supply chain package compromise reaches developer systems?

A: Accountability typically spans the engineering team that approved the dependency path, the platform team that defined install policy, and the security function that set provenance and monitoring requirements. Frameworks such as NIST CSF and MITRE ATT&CK help assign responsibility across prevention, detection, and response.

Technical breakdown

How post-install scripts become a supply chain execution path

npm allows packages to run lifecycle scripts during install, which means a dependency can execute code before a developer or CI pipeline fully inspects it. In this attack, the rogue release dropped a large minified bundle that ran during npm install and blended into normal build activity. That matters because most pipeline controls still treat package installation as a low-risk, routine action rather than an execution event. Once code runs in the build context, it inherits access to environment variables, local files, and authenticated tooling.

Practical implication: treat package install as code execution and block or inspect lifecycle scripts in high-trust build paths.

Why secret harvesting turns a package compromise into identity exposure

The malware searched environment variables, scanned local files with TruffleHog, and planted a GitHub Actions workflow to capture future secrets. That combination turns one infected install into a continuing credential collection mechanism. The key issue is not only that secrets were present, but that they were reachable from build and developer contexts with no effective separation. In NHI terms, this is secret sprawl meeting overbroad runtime access, where tokens, cloud keys, and GitHub credentials become high-value non-human identities in motion.

Practical implication: isolate build secrets from install-time execution and rotate exposed GitHub, npm, and cloud credentials immediately.

How worm-like republishing creates autonomous blast radius expansion

The campaign did not stop at theft. If an npm token was found, the malware bumped and republished every package owned by the compromised maintainer, creating a self-propagating loop. That is why this attack behaves more like an autonomous supply chain worm than a one-off implant. The attacker no longer needs to manually move from package to package once the first trusted identity is compromised. In practice, maintainer publishing privilege becomes the replication mechanism, and package ownership becomes part of the attack surface.

Practical implication: scope publishing rights tightly, monitor package ownership changes, and require provenance checks before republishing.

Threat narrative

Attacker objective: The attacker objective was to harvest secrets, hijack publishing trust, and propagate compromise across the npm ecosystem through infected maintainer accounts.

1. Entry occurred when exposed maintainer credentials were reused to publish trojanized releases of popular npm packages.
2. Credential access and persistence followed as the malware harvested environment variables, local files, GitHub tokens, and future CI secrets.
3. Impact came from self-republishing behaviour and repository exposure, which widened compromise across packages, developer systems, and downstream build 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

Supply chain security has become an identity governance problem, not just a code integrity problem. This campaign shows that maintainer credentials, npm tokens, and GitHub access are now the control plane for software trust. When a publishing identity can republish malware into every owned package, governance has failed before runtime detection even begins. Practitioners should treat package publishing rights as privileged access with lifecycle controls, not as routine developer convenience.

Secret harvesting is the real escalation path in modern npm attacks. The malware was effective because it could reach environment variables, local files, and CI secrets during install. That means the boundary between software delivery and identity security has collapsed. In OWASP NHI terms, leaked tokens and credentials are not just artifacts of compromise, they are the mechanism that turns a dependency incident into a broader account takeover pattern.

Worm-like republishing creates a new named risk: supply chain replication through publishing privilege. The compromise spread because the attacker could use one hijacked maintainer token to regenerate trust at scale. That is a specific governance failure mode, not a generic malware issue. Security teams should recognise that publishing privilege, package ownership, and automated release pipelines now form a single blast-radius chain that must be governed together.

Build systems need policy controls that assume malicious package execution is possible. Lifecycle scripts, oversized binaries, and unexpected workflow creation are all signals that a dependency has crossed from consumption into active behaviour. That makes runtime package trust a control domain in its own right. Teams that do not separate install-time execution from secrets access will keep rediscovering the same failure under different package names.

The market implication is clear: software supply chain tooling is moving closer to identity and access governance. Dependency scanning alone cannot stop credential abuse or self-propagating package attacks. Practitioners need controls that connect maintainer privilege, token lifecycle, repository access, and CI/CD execution. The category is converging on blast-radius management, and identity teams should be part of that design now.

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.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.

What this signals

Package compromise is increasingly a governance problem that lands in identity programmes through tokens, maintainer accounts, and CI credentials. The practical shift is toward treating publishing rights and secret access as one control plane, with lifecycle ownership and auditability attached to both.

Secret trust gap: organisations still assume they will detect and remediate exposed credentials before attackers can weaponise them. In fast-moving supply chain attacks, that assumption fails because the attacker can repurpose a single credential path faster than many teams can revoke it, which is why secret remediation speed matters more than policy language alone.

Teams should prepare for more attacks that combine malware, workflow tampering, and credential theft in one chain. The right response is to connect dependency provenance, token governance, and CI/CD containment so the first infected install does not become a durable account takeover path.

For practitioners

• Restrict package lifecycle execution Disable or tightly gate post-install scripts in CI, and require explicit review for packages that execute code during install or introduce large opaque bundles.
• Rotate all exposed developer and pipeline credentials Assume any npm token, GitHub PAT, SSH key, or cloud access key available during the compromise window has been exposed, then revoke and reissue them.
• Mirror trusted registries for high-risk builds Use mirrored or allowlisted registries for production builds so a compromised public package cannot immediately reach release pipelines.
• Monitor for republishing and workflow creation anomalies Alert on unexpected package version bumps, new maintainers, and creation of GitHub Actions workflows that exfiltrate secrets or touch release automation.

Key takeaways

• This campaign shows that npm supply chain compromise is now an identity and secrets governance problem, not only a software delivery issue.
• The attack gained power by stealing credentials, abusing install-time execution, and using publishing rights to replicate across more than 180 packages.
• Teams need to control package execution, secret exposure, and publishing privilege together, or a single compromised maintainer identity can cascade across the ecosystem.

Key terms

• Supply Chain Replication: A supply chain attack pattern in which one compromised trusted component is used to create additional infected artefacts automatically. In package ecosystems, republishing rights, workflow access, or build automation can turn a single incident into broad propagation across downstream consumers.
• 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.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.

What's in the full analysis

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

• Package-by-package infection timeline and the full list of compromised npm releases
• Indicator details for malicious bundle.js hashes, workflow names, and outbound webhook traffic
• Response actions for cleaning developer machines, CI runners, and repository caches after exposure
• Practical guidance on mirroring registries, provenance checks, and publication controls

👉 Apiiro's full post covers the infection chain, compromised package list, and response details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity controls for practitioners building resilient identity programmes. It is designed for teams that need to connect access governance to real-world operational risk.