Mini-Shai-Hulud shows how package installs can steal NHI secrets

At a glance

What this is: Mini-Shai-Hulud is a coordinated npm and PyPI supply-chain attack that used install-time execution to steal secrets from developer and CI environments.

Why it matters: It matters because NHI and human identity controls both fail when package installs can access cloud credentials, tokens, and developer tooling without strong isolation or lifecycle governance.

By the numbers:

• A coordinated supply-chain attack published malicious versions of at least 235 packages across npm and PyPI.
• The attack first compromised 42 @tanstack/* npm packages before spreading to Mistral AI, UiPath, OpenSearch, Guardrails AI, and others.
• The @uipath/* cluster alone included 65 malicious packages, showing how scoped brand takeover can accelerate package trust abuse.
• Roughly 62 unscoped npm packages were used as plausible-looking typosquats and pivots into developer tooling and crypto ecosystems.

👉 Read FOSSA's analysis of the Mini-Shai-Hulud supply-chain attack and NHI exposure

Context

Package supply-chain attacks are no longer only a software integrity problem. In this case, install-time execution became an identity problem because the malicious packages were able to read cloud credentials, CI tokens, and developer secrets from the same environments used for normal builds and imports. That makes NHI governance part of the software delivery control plane, not a separate concern.

The core weakness is not just malicious code in a package. It is the combination of trusted installation paths, broad environment access, and credentials that remain available long enough to be harvested and exfiltrated. For teams running npm, PyPI, and developer tooling at scale, that is a familiar but still under-controlled pattern.

The attack pattern is typical of modern supply-chain abuse: the initial foothold is a trusted package update, but the real objective is credential theft and persistence inside build and developer ecosystems.

Key questions

Q: What breaks when a compromised package can read secrets during installation?

A: The main failure is that package installation becomes an identity event. If the environment exposes tokens, keys, or certificates while a dependency executes, the attacker does not need application-level access first. They can steal reusable credentials and move into cloud, CI/CD, or internal systems that trust those secrets.

Q: Why do NHIs make supply-chain attacks harder to contain?

A: NHIs are often present in many places at once, including developer laptops, build agents, and CI pipelines. That creates a larger blast radius than a single user account because one compromised package can reach multiple token types and services. Containment depends on rotation, revocation, and isolation of the environments where those secrets live.

Q: What do security teams get wrong about package-level secret exposure?

A: Teams often focus on whether the package is malicious and miss whether the environment is exposed. A benign-looking install path becomes dangerous when scripts can read local files, SDK config, and environment variables. The real control question is which secrets are reachable by untrusted code during install or import.

Q: How should teams respond when malicious packages are found in build systems?

A: Contain the affected pipelines first, then rotate every credential class that may have been accessible to package code, including cloud keys, CI tokens, and publish tokens. After that, inspect developer tooling for persistence and verify whether any downstream repositories or artifacts were built while the malicious package was present.

Technical breakdown

Install-time execution turns dependency trust into code execution

The attack used lifecycle hooks such as prepare and preinstall so the payload ran during package installation, before application code, sandbox validation, or manual review. In npm, dependency resolution can trigger code from nested Git-hosted packages or package scripts; in PyPI, import-time logic can defer the malicious action until a real import occurs. That separation helps the attacker evade static review and some sandbox checks because the artifact looks inert until the trigger condition is met. The key technical point is that package managers often treat installation as trusted orchestration, not as an execution boundary.

Practical implication: treat package install and import paths as execution surfaces and control them with sandboxing, script restrictions, and allowlisting.

Secret harvesting targets both local files and runtime environments

Once executed, the payload searched standard credential locations and environment variables for AWS IAM keys, cloud SDK configuration, Kubernetes service-account tokens, Vault tokens, GitHub tokens, and CI secrets. That makes the attack effective across developer laptops, build agents, and ephemeral CI jobs because the same credential classes often exist in each. The payload did not need deep privilege if the environment already contained high-value NHI secrets. In practice, this is credential discovery followed by rapid exfiltration, not a noisy exploit chain. The design exploits the fact that many engineering environments still assume local trust and broad secret availability.

Practical implication: reduce secret exposure windows and remove long-lived credentials from developer and build environments.

Persistence moved beyond the package into developer tooling

The campaign also modified files in locations such as .claude and .vscode so the implant could survive a simple dependency cleanup. That is a persistence pattern aimed at developer workflows rather than just package registries. It means remediation must look for altered tooling, startup scripts, and local automation as well as the compromised dependency itself. The attacker is effectively trying to turn one package install into a broader workstation or pipeline foothold. For identity teams, this is where NHI governance intersects with endpoint and developer environment hardening.

Practical implication: inspect developer tooling persistence locations and not just the compromised package manifest.

Threat narrative

Attacker objective: The objective was to harvest reusable credentials and maintain access inside developer and CI environments for follow-on compromise and supply-chain abuse.

1. Entry began with malicious package versions published to trusted npm and PyPI namespaces, then triggered through normal install or import flows.
2. Credential access followed when the payload searched local files, SDK paths, and CI environments for cloud keys, GitHub tokens, Vault tokens, and other NHIs.
3. Impact came from exfiltration to external infrastructure and persistence inside developer tooling, giving attackers durable access to exposed environments.

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 installation is now an identity event, not just a software event. This attack worked because install-time execution had access to credentials that should have been isolated from untrusted package code. NHI governance has to extend into developer and build environments, because the compromise path was credentials, not source code alone. Practitioners should treat dependency execution as a governed access decision.

Standing NHI exposure created the blast radius here. The article shows AWS IAM credentials, GitHub tokens, Vault tokens, and CI secrets were reachable from routine workflows. That is a classic lifecycle failure where secrets remain available longer than the trust boundary justifies. The relevant control gap is not merely detection, but reducing the number of reusable credentials available at install and import time.

Secret sprawl becomes a supply-chain amplifier when package managers can reach it. We would name this the install-time secret exposure window. It describes the period in which developer tooling, CI runners, and package hooks can all see the same reusable credentials before any review or containment happens. The practical conclusion is that secret location and reachability matter as much as secret strength.

Persistence inside developer tooling raises the maturity bar for response. If incident handling stops at deleting the malicious dependency, the attacker may still retain footholds in local automation files and IDE configuration. This is where endpoint, identity, and pipeline controls converge. Teams should assume package compromise can become environment compromise unless tooling persistence paths are explicitly hunted.

MITRE ATT&CK and OWASP NHI both describe parts of this pattern, but neither alone is enough. ATT&CK captures the execution and credential-access stages, while NHI guidance frames the secrets lifecycle failure. The governance lesson is that supply-chain defense must join code provenance, script execution control, and secret lifecycle management into one operating model. Practitioners should align those controls before the next package wave.

From our research:

• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• For a broader breach lens, The 52 NHI breaches Report shows how identity failures repeatedly convert access into impact across real incidents.

What this signals

Secret reachability is now a control surface. If untrusted package code can see cloud keys, CI tokens, or developer credentials, then the question is no longer only whether secrets are rotated. The real issue is whether they are present in execution contexts that should never see them. Teams should align build isolation, secret scoping, and NHI lifecycle controls as one programme, not separate workstreams.

The next step for many organisations will be tightening package execution policy and mapping which credentials exist in developer tooling, CI runners, and ephemeral build jobs. That work should be anchored in the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix, because the attack chain here is both an execution problem and a credential-access problem.

A useful operating concept is the install-time secret exposure window. Once teams name that window, they can measure it, reduce it, and audit it like any other privileged access path. The organisations that treat package installation as governed access will be better placed to absorb the next wave of supply-chain credential theft.

For practitioners

• Restrict package script execution Disable or tightly control install-time hooks such as preinstall and prepare in build pipelines where possible, and run package installs in isolated environments that do not contain cloud credentials or developer tokens.
• Inventory exposed NHI secrets Search developer laptops, CI runners, and container images for AWS IAM credentials, GitHub PATs and OIDC tokens, Vault tokens, npm publish tokens, and Kubernetes service-account tokens that could be reached by package code.
• Rotate the credential classes named in the attack Prioritise rotation of cloud keys, GitHub tokens, CI tokens, and Vault tokens on any host or pipeline that could have executed the malicious packages, then revoke unused secrets and shorten TTLs.
• Hunt for persistence in developer tooling Inspect .claude, .vscode, startup scripts, and task files for unauthorized edits, because the attack attempted to persist beyond dependency removal and basic package cleanup.
• Correlate build logs with suspicious egress Review CI and developer build logs for network connections to filev2.getsession[.]org and git-tanstack[.]com, then isolate any workflow that contacted those domains during the exposure window.

Key takeaways

• Mini-Shai-Hulud shows that package installation can be a credential-access event when secrets are reachable from developer and CI environments.
• The impact was broad because the campaign targeted reusable NHIs such as cloud keys, GitHub tokens, Vault tokens, and publish credentials.
• Containment requires both dependency hygiene and environment hardening, including secret rotation, install-time execution control, and persistence hunting.

Key terms

• 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.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Persistence in Developer Tooling: A technique where malicious changes are written into IDE settings, automation files, or local helper scripts so the attacker keeps execution capability after the original package is removed. This extends the compromise beyond the dependency and makes cleanup incomplete if teams only replace the package version.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.

What's in the full article

FOSSA's full post covers the operational detail this analysis intentionally leaves at the governance level:

• Package-by-package remediation guidance for the affected npm and PyPI ecosystems
• Detection workflow details for FOSSA-tracked repositories and Malware issues
• Specific credential rotation steps for AWS IAM, GitHub, npm publish, and Vault tokens
• File and log paths to inspect in developer environments and CI build records

👉 The full FOSSA post covers affected packages, install-time mechanics, and remediation steps in detail.

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 control. It is designed for practitioners who need to connect identity governance to real attack paths across cloud, development, and automation environments.