Shai-Hulud shows how npm supply chains turn NHIs into wipers

At a glance

What this is: This is an analysis of a renewed Shai-Hulud malware wave that steals credentials from npm and PyPI package installs and can escalate into destructive machine-wipe behavior.

Why it matters: It matters because package ecosystems now sit inside identity and secret governance boundaries, and compromised build-time NHIs can expose cloud, GitHub, and developer access in minutes.

By the numbers:

• 170+ packages affected
• 379 GitHub repositories with stolen credentials

👉 Read OXSecurity's analysis of the Shai-Hulud npm and PyPI supply chain attack

Context

Shai-Hulud is not just another malware family. It is a supply chain compromise pattern that converts package trust into credential theft, then uses those stolen secrets to widen access across developer, cloud, and source control environments. For identity teams, the real issue is that package install time has become an identity event, not just a software delivery step.

The latest wave extends that risk with self-propagation, token monitoring, and destructive logic if revocation is detected. That combination pushes the incident beyond classic secrets leakage and into NHI governance failure, where service tokens, API keys, and GitHub-connected workflows become both entry points and persistence mechanisms. This is now a recurring pattern, not an isolated campaign.

Key questions

Q: What breaks when malicious package installs are allowed to execute code by default?

A: Malicious packages can run before review, harvest tokens from the local environment, and create persistence through repositories or automation paths. The break point is not just endpoint compromise. It is the collapse of trust between dependency installation and identity governance, because secrets become reachable during package acceptance rather than after deployment.

Q: Why do developer workstation secrets create such a large blast radius?

A: Developer workstations often hold publishing tokens, cloud keys, password vault access, and CI credentials that can be reused across many systems. When one host is compromised, the attacker can pivot from source code to package publication, cloud access, and internal tooling. The blast radius is large because the workstation becomes a portable identity hub.

Q: How do security teams know whether a package advisory has created real identity exposure?

A: They should check whether affected build or developer environments stored cloud keys, SSH keys, API tokens, or SaaS access at the time of installation. If those identities were present, the advisory is an authentication event, not just a software update, and revocation becomes mandatory.

Q: What should teams do immediately when a supply chain package steals tokens and keys?

A: Contain the affected endpoint, revoke every credential that may have been present during the install, and inspect GitHub and CI systems for persistence. Then rebaseline affected identities, rotate downstream secrets, and review whether package lifecycle controls would have prevented execution in the first place.

Technical breakdown

How malicious npm and PyPI packages execute at install time

The malware uses package lifecycle hooks and import-time execution to run before a developer ever notices a problem. In npm, preinstall or setup scripts can trigger arbitrary code during installation. In Python, malicious logic inside __init__.py runs when the package is imported. That makes the build and dependency resolution process part of the attack surface. Once execution starts, the malware can download payloads, collect environment data, and move quickly before traditional runtime controls have much visibility.

Practical implication: restrict install-time execution, review package scripts, and block untrusted lifecycle hooks in CI and developer environments.

Credential theft, exfiltration, and GitHub persistence

The payload extracts tokens, keys, and environment variables, then exfiltrates them to external infrastructure and back into attacker-controlled GitHub repositories. That is important because it turns the victim's own collaboration platform into a storage layer for stolen secrets. When secrets are uploaded into new repositories, the attacker gains durable access even after the original package is removed. This is a classic NHI abuse pattern: the malware is not only stealing credentials, it is turning identity artifacts into persistence.

Practical implication: treat any exposed developer token, API key, or GitHub secret as potentially persistent until proven rotated and invalidated.

Why token monitoring and wipe logic raise the stakes

This variant adds behavior that checks whether captured tokens are still working and can trigger destructive actions if revocation is detected. That changes the incident from passive theft to coercive persistence. The attacker is no longer only trying to retain access. They are also trying to punish remediation and create delay, which increases the blast radius across endpoints, source control, and downstream cloud access. For defenders, revocation is necessary but not sufficient unless it is paired with containment and device assurance.

Practical implication: coordinate token revocation with endpoint containment, repository audit, and cloud access review so response does not create a second failure mode.

Threat narrative

Attacker objective: The attacker wants durable access to developer and cloud identities while preserving the ability to spread, exfiltrate, and punish remediation attempts.

1. Entry occurs when a developer installs a compromised npm or PyPI package that executes malicious lifecycle or import-time code.
2. Credential access follows as the malware harvests environment variables, API keys, and tokens from the local machine and build context.
3. Escalation and persistence happen when stolen credentials are uploaded to attacker-controlled repositories and reused for further propagation.
4. Impact includes broad credential exposure, repository compromise, and destructive wipe behavior if token revocation is detected.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Miasma and Hades Supply Chain Worms — Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shai-Hulud is a non-human identity governance problem disguised as malware. Package managers, build scripts, and developer workflows now execute with access to secrets, tokens, and trust boundaries that many teams still treat as software plumbing. When those credentials are compromised, the issue is not only endpoint malware but identity collapse across the software supply chain. Practitioners should treat package execution as a governed identity event.

The attack works because organisations still assume package installation is low-risk and reversible. That assumption breaks once lifecycle hooks can execute code, harvest credentials, and reinfect through repositories. The control gap is not simply weak malware detection. It is the absence of enforcement around install-time trust, token scope, and repository write paths. Teams should reclassify package installs as high-trust operations that require policy controls.

Credential persistence in GitHub repositories is now a major extension of supply chain compromise. Uploading stolen tokens into new repositories gives attackers a durable foothold that outlives the original infected package. This makes source control part of the identity attack surface, especially where developer tokens, cloud credentials, and automation secrets share the same trust plane. The practical conclusion is that secrets governance must include repo scanning, not just vault policy.

Standing privilege makes supply chain malware far more dangerous than a one-time leak. A stolen key with broad, persistent access turns a single infection into repeated cloud and code access. That is why NHI visibility, rotation, and least privilege sit at the centre of containment. The relevant governance concept here is install-time identity exposure, meaning credentials are at risk before software is even accepted into the environment. Practitioners should govern the install path like any other privileged entry point.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Guide to the Secret Sprawl Challenge shows why secrets often remain embedded in code, config, and CI/CD long after discovery.

What this signals

Install-time identity exposure will become a standard governance concept for software teams because package execution increasingly intersects with secrets, tokens, and automation trust. If a dependency can run code during install, the identity boundary has already been crossed before deployment begins. Teams should map dependency ingestion into the same control plane as privileged access and build-time secrets handling.

The practical programme shift is toward faster revocation, narrower token scope, and stronger separation between human developer credentials and automation identities. That means pairing package policy with MITRE ATT&CK Enterprise Matrix mapping for credential access and lateral movement, then using repository scanning to find where stolen secrets persist. In supply chain incidents like this, the question is not whether malware executed once. It is how far identity reuse allowed it to travel.

Where organisations still rely on long-lived secrets in code, package registries become a high-value distribution channel for compromise. The governance response should include dependency policy, secret scanning, and tighter lifecycle control for every credential that can be touched by a build system. For readers running developer platforms, this is a sign to treat NHI visibility as a software supply chain control, not a separate identity project.

For practitioners

• Block install-time code execution by default Disallow npm preinstall hooks, Python import-time side effects, and other package lifecycle execution in CI and developer laptops unless explicitly approved. Combine this with allowlisted registries and policy checks before dependency installation. This reduces the chance that package trust becomes automatic code execution.
• Rotate exposed secrets as compromised by default Treat any API key, token, or cloud credential present on a machine that installed affected packages as compromised, even if you have no direct evidence of abuse. Revoke and reissue those credentials, then validate that downstream service accounts and GitHub tokens are not still live.
• Scan GitHub for attacker-controlled secret dumps Search public and private repositories for the malware string used by this campaign and for new repositories created by your organisation or developers after package installs. Use those findings to identify persistence paths and scope which identities the attacker may still control.
• Separate developer and automation identities more aggressively Reduce the blast radius by isolating local developer credentials from CI/CD, cloud automation, and GitHub tokens. Where possible, use short-lived credentials and distinct identities for build, deploy, and personal workflows so one compromise does not spread across the environment.

Key takeaways

• Shai-Hulud shows that package managers can become identity attack paths when install-time code reaches secrets, tokens, and cloud credentials.
• The scale is material, with 170+ affected packages, 518,765,599 monthly downloads, and 379 GitHub repositories holding stolen credentials.
• Teams should assume compromise, revoke exposed credentials, restrict lifecycle execution, and govern package installs as privileged events.

Key terms

• Install-time identity exposure: The moment a package or dependency can execute code and reach credentials during installation or import. In practice, it means software delivery steps can become identity compromise points if tokens, secrets, or automation keys are accessible before the package is trusted.
• Credential persistence through repositories: A persistence pattern where stolen tokens, keys, or secrets are stored in attacker-controlled source control or newly created repositories. This extends access beyond the original infected host and makes repository hygiene part of incident response and NHI governance.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Supply chain secret theft: The extraction of credentials, API keys, or tokens through compromised dependencies, build steps, or developer tooling. It is especially dangerous because the theft originates inside trusted software workflows, which can bypass ordinary perimeter controls and user awareness.

What's in the full analysis

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

• Package-by-package infection timeline across npm and PyPI namespaces, useful for confirming exposure scope.
• Code-level breakdown of the preinstall, setup, and import-time execution paths used by the malware.
• Examples of the encrypted credential repositories and repository strings used for persistence discovery.
• Response guidance for downgrading affected packages and handling token compromise across developer environments.

👉 OXSecurity's full post covers the infection path, stolen credential patterns, and machine-wipe logic in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management for practitioners who need to reduce exposure across modern identity programmes. It gives security teams a common control language for cloud, developer, and automation identities.