Mini shai-hulud npm worm shows how secret theft fuels package spread

At a glance

What this is: This is an analysis of a supply chain worm that abuses npm install-time execution to steal secrets, persist on developer machines, and republish malicious packages.

Why it matters: It matters because software publishing tokens, cloud credentials, SSH keys, and AI tool configs now sit inside the same trust boundary that IAM, PAM, and NHI governance must control.

By the numbers:

• Over 2,700 rogue GitHub repositories have already been spun up using stolen tokens.

👉 Read Aikido's analysis of the Mini Shai-Hulud npm supply chain worm

Context

Mini shai-hulud is a supply chain worm that turns package installation into code execution, secret theft, and further propagation. In practical terms, npm publishing rights and CI/CD access become an identity problem as much as a software integrity problem, because the attacker is using legitimate credentials and trusted workflows to move laterally through the ecosystem.

The primary weakness is not simply malicious code in a package. It is the combination of install-time execution, standing publish privilege, and weak controls around developer and pipeline secrets. That makes this a genuine intersection of software supply chain security, IAM, and NHI governance, especially where tokens, service accounts, and automation credentials are reused across build systems.

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 NHI secrets in build systems create such a large blast radius?

A: Build systems often hold reusable credentials for source control, cloud access, and package publishing, so one compromise can cross multiple trust boundaries. When those credentials are not tightly scoped or rotated quickly, the attacker can move from local secret theft to registry abuse, cloud access, and persistence in developer tooling.

Q: What do organisations get wrong about machine secrets in CI/CD pipelines?

A: The most common mistake is treating secrets as deployment convenience rather than identity risk. When keys, tokens, and service accounts are embedded in pipelines, ownership becomes blurred and revocation becomes slower than development. That creates hidden trust paths that are hard to audit and easy to reuse across systems.

Q: How should organisations respond when package publishing credentials are stolen?

A: Immediately revoke the stolen publishing access, review recent publishes, and rotate every adjacent credential that the compromised identity could reach. Then inspect developer endpoints for persistence, because the attacker may have left backdoors outside the package manager. Response has to cover both registry access and local workstation state.

Technical breakdown

Why install-time execution defeats post-publish scanning

The payload runs through a preinstall lifecycle hook, which means malicious code executes during npm install before a package is fully unpacked or analysed. That timing matters because static scanners and delayed takedowns only help after the first install has already happened. In this pattern, the package version is the delivery vehicle, but execution happens in the consumer's environment immediately. The attack also uses obfuscation and an optional GitHub dependency path to make the malicious behaviour harder to inspect from the npm tarball alone.

Practical implication: block or quarantine newly published package versions until they have aged past your trust threshold.

How secrets are harvested from developer and CI/CD environments

The malware searches memory, environment variables, local files, and well-known credential stores for GitHub tokens, npm tokens, cloud keys, SSH material, Vault tokens, Kubernetes service account files, Docker auth data, and database strings. This is classic NHI abuse because the attacker is not guessing passwords, they are collecting machine identities and automation secrets that already have access. Once the payload has those values, it can encrypt and exfiltrate them or use them immediately to access registries, cloud APIs, and source control.

Practical implication: treat build runners and developer endpoints as secret-bearing systems and rotate every credential they touched.

Why stolen publishing rights turn one compromise into many

After harvesting npm credentials, the worm validates them, enumerates reachable packages, injects the payload, bumps versions, and republishes. That creates propagation through legitimate publisher authority rather than through network exploitation. The effect is a credential-to-campaign transition: one maintainer account with broad rights becomes the launch point for hundreds of downstream compromises. The added persistence in VS Code and Claude Code settings extends the blast radius beyond the package manager into developer tooling, which means cleanup has to include local workstation state, not just dependency graphs.

Practical implication: scope publishing tokens narrowly, remove unused maintainer rights, and inspect developer tool configs during response.

Threat narrative

Attacker objective: The attacker wants to harvest reusable credentials and turn trusted publishing access into a self-propagating package compromise campaign.

1. Entry occurs when a developer or CI runner installs a compromised npm package that executes a preinstall hook immediately.
2. Credential access follows as the payload extracts plaintext secrets, cloud credentials, SSH keys, GitHub tokens, and automation tokens from memory and local storage.
3. Escalation happens when stolen publishing rights are used to republish tampered packages and create new attacker-controlled GitHub repositories.
4. Impact is campaign expansion across downstream environments, persistent workstation footholds, and broader secret exposure from reused NHI credentials.

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

Standing publish privilege is now a supply chain risk, not just a release-management issue. The worm does not need to compromise npm itself when one maintainer token can rewrite a large portion of a package namespace. That turns publishing rights into a privileged identity that needs lifecycle controls, not informal trust. For practitioners, the question is no longer who can publish in theory, but which accounts can still reach too much in one session.

Mini shai-hulud exposes the secret exposure window as the real control gap. The malicious code only needs minutes of access to harvest secrets, but many organisations still rely on scanning after publication or after installation. That assumption fails when the attacker can execute during the install path and leave before detection. The governance lesson is that machine identities and pipeline secrets must be treated as short-lived, tightly scoped credentials, not durable access paths.

Persistent compromise now extends into developer AI tooling and IDE state. The addition of VS Code and Claude Code backdoors shows that package compromise is no longer contained to the dependency tree. Attackers increasingly preserve access in the local working environment because they expect defenders to clean only the package layer. This broadens the identity surface to include the tools developers use to authenticate, generate, and ship code.

Credential reuse multiplies the blast radius across ecosystems. npm tokens, GitHub tokens, cloud keys, and SSH material are all usable in adjacent systems once stolen. That is why NHI governance matters here: these are not isolated secrets, but interoperable identities that can bridge source control, cloud, and build infrastructure. Practitioners should treat each token as a propagation path, not a single control object.

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.
• This broader secret-handling gap helps explain why package-based secret theft keeps succeeding, and it connects directly to 52 NHI Breaches Analysis for the downstream identity abuse pattern.

What this signals

Secret-harvesting supply chain attacks should now be treated as identity incidents. The operational lesson for security teams is that source control, CI/CD, and package publishing all depend on machine identities that can be abused faster than traditional response workflows can react. That makes secret age, credential scope, and publisher trust thresholds core programme controls, not implementation details.

Credential sprawl is the named risk this campaign keeps exposing. Once the same token can reach npm, GitHub, cloud APIs, and local developer tooling, containment becomes a cross-platform identity exercise. Teams should align package governance with secret lifecycle controls and review coverage against the OWASP Non-Human Identity Top 10.

The practical signal for practitioners is whether their build estate can prove which secrets were present on a runner, which package versions executed, and which identities those credentials could impersonate. If that evidence is missing, the programme has a visibility gap that attackers can repeatedly exploit.

For practitioners

• Block unvetted package ages Refuse to install newly published npm versions until they pass an internal age threshold, especially in CI and developer bootstrap workflows. This closes the install-time execution window that the worm depends on.
• Tighten maintainer publishing rights Review every account that can publish to high-download packages, remove shared maintainer access, and require separate credentials for publishing versus ordinary repository access. Broad publishing rights are the propagation mechanism.
• Rotate secrets from touched environments If a compromised package executed on a workstation or runner, rotate GitHub tokens, npm tokens, cloud keys, SSH keys, Vault tokens, and Kubernetes service account material from that environment, not just the package registry token.
• Inspect local persistence artifacts Search developer endpoints for unexpected changes in .vscode/tasks.json and .claude/settings.json, then remove any added tasks or configuration entries before returning the machine to service.
• Monitor for suspicious publish activity Audit recent npm publish events, GitHub Actions runs, and outbound requests during dependency installation, with special attention to unexpected Bun execution or optional dependency references such as github: repos.

Key takeaways

• The worm succeeds because install-time execution turns trusted packages into credential-harvesting delivery systems.
• The scale matters because stolen publishing rights and reused secrets let one compromise become many downstream package attacks.
• Teams need age-based package controls, narrow publishing privileges, and fast rotation of every secret touched by a compromised runner.

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.
• Standing publishing privilege: Persistent permission for a system to publish content repeatedly without a fresh approval step. For automated content workflows, this creates ongoing authority that can outlast the original business need, making lifecycle ownership and revocation the decisive controls.
• 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.
• Exotic dependency: A dependency reference that points to a Git repository or commit rather than a standard registry package. Attackers use this pattern to create an alternate execution path or hide payloads outside the normal package tarball, which complicates static inspection and dependency trust decisions.

What's in the full article

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

• The full package-level IOC list for the affected @antv, echarts-for-react, and related npm versions.
• Detailed install-time payload markers, including the exact preinstall hook and optional dependency path used by the worm.
• The complete detection and mitigation checklist for CI logs, endpoint artefacts, and outbound telemetry indicators.
• The broader historical comparison with earlier SAP and TanStack waves, including campaign markers and republishing behaviour.

👉 Aikido's full post covers the package list, persistence artefacts, and detection indicators in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader build and release workflows their programmes depend on.