Shai-Hulud’s npm resurgence exposes weak package governance

At a glance

What this is: OXSecurity reports a renewed Shai-Hulud npm malware campaign that uses install-time execution to steal tokens, spread across packages, and persist through developer workflows.

Why it matters: This matters because npm package trust, secrets exposure, and developer tool persistence now intersect directly with IAM, NHI, and secrets governance for software delivery teams.

By the numbers:

• The malware is still spreading, and estimated to infect 444 packages with over 2 billion monthly downloads
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read OXSecurity's analysis of the Shai-Hulud npm supply chain campaign

Context

npm package compromise is no longer limited to vulnerable dependencies or typo-squatted releases. This campaign shows how install-time scripts can turn a trusted package into a delivery mechanism for credential theft, self-propagation, and developer environment persistence, with direct exposure for secrets management and software supply chain governance.

The identity angle is real. The malware targets GitHub tokens, cloud credentials, and other secrets, then survives through local developer tools and AI-assisted workflows. That makes package trust a non-human identity governance issue as much as a software integrity problem, because the exposed credentials are often the real control plane for pipelines and repositories.

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 package supply chain attacks create NHI risk?

A: Because the attacker usually wants the non-human credentials behind the build and release process, not just the infected package. Service tokens, repository tokens, and cloud keys let malware pivot from one compromise to many. When those identities have broad scope or long lifetimes, package compromise becomes an access-control problem, not just a software integrity problem.

Q: How do security teams know if exposed secrets are becoming a real risk?

A: The clearest signal is whether the secret can still authenticate and whether it can reach high-value actions after login. If a leaked key can enumerate resources, create identities, or modify policy, it is already a breach-enabling identity. Inventory alone is not enough unless revocation and scope reduction follow quickly.

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 npm preinstall hooks become an execution path

npm supports lifecycle scripts that run during package installation, including preinstall and postinstall hooks. When attackers place malicious logic in those hooks, code executes before a developer can inspect the package contents in normal use. In this case, the malware uses that execution window to run setup logic, fetch additional components, and begin credential theft immediately. The risk is amplified when teams allow broad install privileges across developer machines and build systems, because the package inherits the trust of the installation context rather than the code itself.

Practical implication: restrict lifecycle scripts in untrusted packages and treat install-time execution as a governed control surface.

Why stolen GitHub tokens and cloud secrets drive propagation

The malware is built around secrets harvesting. Once it captures GitHub tokens, environment variables, and cloud credentials, it can push malicious commits, search for additional repositories, and spread across more package maintainers and downstream projects. That creates a self-propagating loop in which one compromised identity becomes the distribution mechanism for the next wave. This is the same failure mode seen in other supply chain attacks: the code payload matters, but the identity and token material behind the package release process is what turns a single compromise into ecosystem spread.

Practical implication: scope, monitor, and rotate maintainer and CI tokens as NHI credentials, not as ordinary developer convenience secrets.

How persistence through IDEs and local AI tools changes the response model

The article says the malware persists through local AI agents and IDEs such as Claude and VS Code. That matters because developer tooling is increasingly connected to repositories, terminals, and credentials, which means compromise can survive beyond a single package install and continue influencing the workstation environment. In governance terms, this collapses the boundary between code execution and identity persistence. The control problem is not just malware removal, but revocation of every secret and session the infected workstation could still reach.

Practical implication: build revocation and re-authentication workflows for developer devices, IDE integrations, and agent-connected tools.

Threat narrative

Attacker objective: The attacker aims to harvest high-value developer credentials, spread the malware through trusted package channels, and preserve access long enough to maximise downstream compromise.

1. Entry occurs through npm preinstall script execution embedded in packages such as math_init.js and Math_Symbol.js, which runs automatically during installation.
2. Credential access follows as the malware steals GitHub tokens, cloud credentials, environment variables, and other secrets from the developer environment.
3. Escalation and propagation happen when the stolen tokens are used to spread the malware into additional repositories and packages, while persistence continues through local tools and AI-assisted workflows.
4. Impact is ecosystem-wide exposure of repositories, credentials, and package trust, with a dead-man switch intended to punish token revocation attempts.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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 install time is now an identity event. When a dependency can execute code during installation, the trust decision is not just about code provenance. It is also about which secrets, tokens, and repository permissions the installer can reach. That makes package managers part of the identity control plane, especially where CI agents and developer workstations hold reusable credentials. Practitioners should treat install-time execution as a governed access path, not a benign build step.

Shai-Hulud exposes a standing-secrets failure mode, not just a malware problem. The campaign works because GitHub tokens, cloud credentials, and environment secrets remain valid long enough to be harvested and reused. That is a classic non-human identity failure: excessive lifetime, excessive scope, and insufficient revocation speed. The relevant control gap is not missing awareness, but credentials that stay useful after compromise. Teams should measure the blast radius of every token they issue.

Persistent access through developer tools creates a trust recursion problem. Once malware can ride through IDEs and local AI tooling, the workstation becomes a bridge between code signing, source control, and secret storage. That widens the attack surface beyond the package registry and into the developer operating model. Developer-tool identity sprawl: when IDEs, assistants, CLIs, and package managers all retain overlapping credentials, revocation becomes partial and response becomes slow. Practitioners should map every developer tool that can authenticate on behalf of a person or pipeline.

npm needs permission boundaries, not only script blocking and 2FA. The article is right to point toward granular permission control over what a package can do. From a governance perspective, the category is moving toward executable artefact authorisation, where packages must be constrained in what identities and network destinations they can touch at install time. That direction aligns with broader least-privilege thinking in IAM and NHI security. Practitioners should expect package ecosystems to borrow more from application permission models.

AI-assisted development increases the consequences of secret leakage. When local AI agents and coding assistants are attached to workstations, stolen credentials can be reused in more places and by more automation than before. That does not make the AI the primary vulnerability. It does mean that machine identities, assistant integrations, and developer tokens now share the same trust boundary. Security programmes should therefore evaluate AI tooling with the same revocation, scoping, and observability expectations used for other high-trust non-human identities.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
• The NHI Lifecycle Management Guide helps teams connect visibility gaps to rotation, revocation, and offboarding decisions when package compromise becomes an identity problem.

What this signals

Developer-tool identity sprawl will become a more visible control failure as package ecosystems, IDEs, and AI assistants continue to share credentials and session state. The operational signal to watch is not only malware detection, but whether a single workstation compromise can still reach source control, cloud access, and publish pipelines after revocation.

Package trust should now be evaluated the same way teams evaluate third-party access. That means mapping which secrets an installer can reach, how quickly those secrets can be revoked, and whether build identities are isolated from human developer identities. The control question is whether the package manager can still become an unexpected identity broker.

The broader programme implication is clear: secrets governance, workload identity, and developer platform controls must converge. Teams that keep package security, NHI governance, and AI-enabled development in separate tracks will miss how quickly credentials move across those boundaries.

For practitioners

• Lock down lifecycle scripts in package installs Disable or tightly restrict preinstall and postinstall execution for packages that are not explicitly trusted. For build systems that must allow scripts, isolate them in ephemeral environments with no access to production secrets or maintainer tokens.
• Rotate and scope developer and CI tokens Treat GitHub tokens, cloud keys, and package-publish credentials as non-human identities with short lifetimes and minimal scopes. Revoke tokens after any suspected package compromise, and validate that no workflow still depends on long-lived standing access.
• Search for infected repositories and secret reuse Hunt for the IOC string in repositories, package histories, and developer machines, then verify whether stolen secrets were reused across repos or CI jobs. Cross-check against the 52 NHI breaches Report to frame the offboarding and revocation failure mode.
• Move sensitive workflows to isolated runners Separate package install, secret handling, and repository publishing into isolated runners with distinct identities. Do not allow the same credential set to reach source control, cloud access, and package distribution paths.
• Add approval barriers for newly published packages Prefer packages that have been live long enough for community review, and add internal allowlisting for high-risk dependencies. Use the Ultimate Guide to NHIs as the reference point for how long-lived credentials and third-party exposure widen blast radius.

Key takeaways

• The campaign shows that npm installation can be used as a credential theft and propagation channel, not just a software delivery mechanism.
• The scale is substantial, with more than 2 billion monthly downloads and hundreds of packages implicated, which raises the cost of delayed revocation.
• Teams need tighter install-time controls, faster token rotation, and isolated developer identities to stop package compromise from becoming ecosystem compromise.

Key terms

• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• Identity Tool Sprawl: Identity tool sprawl is the accumulation of overlapping identity, access, vaulting, and monitoring tools that do not share a single control model. The result is fragmented context, duplicated administration, and gaps where privileged access can persist without clear ownership or timely revocation.
• Standing Secret: A standing secret is a long-lived credential that remains valid until it is manually replaced or revoked. In practice, it expands attack exposure because the secret can outlive the service change process, especially when ownership and usage tracking are incomplete.
• Package Install Trust Boundary: The point at which a dependency is allowed to run code during installation or build. In supply chain attacks, this boundary is often weaker than teams assume, because build metadata and native compilation hooks can execute before ordinary review or monitoring controls trigger.

What's in the full analysis

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

• The complete indicator list, including the package names and version ranges that are currently affected.
• The malware strings, filenames, and repository markers that teams can use for internal hunting and triage.
• The install-time execution chain from preinstall script to credential theft, persistence, and self-spread.
• The full recommended response sequence for developers and platform teams managing compromised repositories.

👉 OXSecurity's full post covers the infection chain, affected packages, and recommended response steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security and platform teams connect identity governance to the operational decisions that shape blast radius.