Mini Shai-Hulud shows how npm worms turn CI/CD secrets into spread

At a glance

What this is: This analysis explains how the Mini Shai-Hulud npm worm turned package installs into secret theft and further propagation across the software supply chain.

Why it matters: It matters because CI/CD secrets, token hygiene, and package provenance are now intertwined with NHI governance, especially where build systems can publish or deploy on behalf of teams.

By the numbers:

• The compromise spread across more than 300 packages and involved over 600 malicious versions published in two coordinated waves.
• The campaign lists over 130 credential file paths on host systems as search targets for secret harvesting.
• 2, ore than 2,500 public GitHub repositories were created using exfiltrated credentials during the campaign.

👉 Read Arnica's analysis of impacted @antv packages in SBOMs

Context

Mini Shai-Hulud is a supply chain worm that weaponises package installation, CI/CD runtime access, and stolen tokens. In practice, that means the security boundary is no longer just the repository or lockfile, but the identity and secret estate attached to the build process itself.

For identity and access teams, the important issue is not only malware in npm. It is the governance gap created when service accounts, GitHub Actions runners, developer laptops, and publishing tokens are trusted to install, read, and republish code with little runtime containment.

The article’s findings are typical of modern supply chain abuse: the initial package infection is only the start, and the real damage comes from secret extraction plus reuse of those credentials to propagate further.

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 CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: How do security teams know whether a package worm has already reached them?

A: They should look beyond the affected dependency list and inspect runner execution history, secret exposure scope, and unexpected publish activity. A clean SBOM does not prove safety if a compromised package already executed and harvested credentials during build or local install.

Q: Who is accountable when a CI/CD token is used to publish poisoned packages?

A: The accountable teams are the owners of the build and package-publish identities, because those identities controlled the action path. Governance should assign ownership for token scope, rotation, revocation, and monitoring, and it should treat publish rights as privileged access with clear lifecycle control.

Technical breakdown

How npm supply chain worms use install-time execution

npm packages can run code during install through lifecycle scripts and related hooks, which makes the installation step a privileged execution point. In a worm scenario, malicious package code can read environment variables, inspect the local filesystem, and interact with CI/CD runner state before developers realise anything unusual happened. The risk is amplified when the build system trusts dependency installation as a routine, low-friction operation. Once execution happens inside a pipeline, the attacker inherits whatever identity the runner or developer context already holds, including tokens, cloud credentials, and publishing rights.

Practical implication: Treat dependency install as an execution boundary and restrict install-time script execution wherever feasible.

Why masked secrets are still exposed in CI/CD runners

Masking protects how secrets appear in logs, not how they exist in memory or process state. A malicious package running inside a GitHub Actions runner can read plaintext secrets from memory, environment variables, and accessible files even when log output shows redaction. That is why “masked” does not mean “safe” in a compromised build. If a pipeline can fetch, build, and publish, it is already an identity-bearing runtime. Those identities need tighter scoping, shorter lifetime, and stronger separation between build, test, and release activities.

Practical implication: Assume any secret reachable by the runner is exposed once malicious code executes, and scope runner identities accordingly.

How stolen tokens turn secret theft into propagation

The second stage of the worm is what makes it dangerous at scale. Stolen CI/CD or publishing tokens let the attacker publish poisoned packages from compromised accounts, which converts one successful secret theft into many downstream installations. This is a non-human identity problem as much as a malware problem, because the token, not the human user, performs the publish action. That creates a lifecycle gap: if tokens are not tightly governed, rotated, and constrained to specific repositories or package scopes, they become a reusable distribution channel.

Practical implication: Bind publish tokens to narrow scopes and continuously revoke credentials that can publish packages from build systems.

Threat narrative

Attacker objective: To steal reusable secrets and weaponise them for wider package distribution and downstream compromise.

1. Entry begins when a developer or CI/CD job installs a compromised npm package that executes malicious install-time code.
2. Credential access follows as the worm reads runner memory, environment state, and credential file paths to harvest secrets in plaintext.
3. Escalation and propagation occur when stolen tokens are reused to publish additional poisoned packages from compromised accounts, expanding the blast radius.
4. Impact is supply chain contamination across repositories, containers, and downstream builds that trust the infected packages.

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

Pipeline identity is now part of the attack surface. The worm succeeds because build systems carry secrets, tokens, and publish rights that were never designed for hostile code execution. That makes CI/CD runners a form of non-human identity governance problem, not just a malware containment problem. Teams should treat the build pipeline as an identity-bearing runtime with its own lifecycle, scope, and revocation rules.

Standing publish privilege is the real blast-radius multiplier. The issue is not simply that a package was poisoned, but that stolen tokens could publish again from trusted accounts. This is classic zero standing privilege logic applied to software delivery: if build or package-publish identities can act broadly and persistently, one compromise becomes many. Practitioner conclusion: reduce publish scope until stolen credentials have minimal downstream value.

Secret masking does not equal secret protection. The campaign exposes a governance assumption that masked CI/CD secrets are effectively hidden from attackers. They are not. Once malicious code runs in the runner context, memory scraping and filesystem enumeration make masked values reachable. Practitioner conclusion: build controls must assume active secret extraction, not passive log leakage.

Shai-Hulud is a named concept for credential-fed package propagation. The campaign combines malicious dependency execution, secret harvesting, and token reuse into a self-spreading supply chain pattern. That matters because standard SBOM checks can identify affected packages, but they do not by themselves explain which identities can still publish, deploy, or re-infect adjacent systems. Practitioner conclusion: identity governance must extend into software supply chain monitoring.

Package reputation without runtime control is incomplete. The article shows that blocking known bad versions is necessary but not sufficient when secrets may already have been exposed during install. This is why software supply chain security, NHI governance, and build isolation need to be handled together rather than as separate workstreams. Practitioner conclusion: align package vetting with credential containment and post-install token review.

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.
• Track leaked-secret remediation alongside build identity containment, because the 27-day recovery window gives attackers time to repurpose exposed credentials across pipelines and package registries.

What this signals

Secret exposure has become a response-speed problem. Once a build context is compromised, the value of credential rotation depends on how quickly teams can identify every reachable secret and revoke it. The longer the remediation delay, the more time attackers have to publish, deploy, or pivot with stolen automation identities.

SBOM coverage must now be paired with identity review. Package inventory tells you what was installed, but not whether the runner or token that performed the install has since been abused. The practical signal for programmes is whether build identities are isolated enough that one compromised dependency cannot become a publish-capable foothold.

Pipeline trust now needs the same scrutiny as production access. A dependency that executes during install is effectively operating inside a privileged runtime. That means identity-bound controls, secret exposure monitoring, and publish-token governance should be treated as core supply chain controls, not adjacent hygiene.

For practitioners

• Inventory all build and publish identities Map every GitHub Actions runner, npm token, and CI/CD service account that could read secrets or publish packages. Include transitive automation that runs after dependency install, because those identities often have more reach than the humans who own them. Use that inventory to identify where a stolen token could still publish or deploy.
• Rotate secrets exposed to affected installs Assume any environment that executed a compromised package during the campaign window has exposed credentials. Rotate cloud keys, npm publish tokens, GitHub PATs, and any other secret reachable by the runner or local development machine. Prioritise identities that can publish, sign, or deploy artifacts.
• Disable install-time code paths where practical Restrict npm lifecycle scripts and other install hooks in build contexts that do not require them. Where scripts are necessary, isolate them in hardened runners with no broad secret access and no outbound publishing rights. This reduces the chance that a dependency install becomes a secret-extraction event.
• Continuously watch for unexpected package publication Monitor npm publish activity across your organisation for releases that do not match normal release cadence or approved pipeline identities. A new package published from a compromised token is one of the clearest signs that the worm has moved from secret theft into propagation.
• Cross-check SBOM findings against container and repo exposure Search both source repositories and container images for impacted versions, then correlate results with pipeline execution history. A clean SBOM does not rule out credential theft if a compromised package executed during install, so pair inventory checks with credential review and incident containment.

Key takeaways

• The Mini Shai-Hulud worm shows that package installation can become a secret-theft event when CI/CD identities are too broadly trusted.
• The campaign’s scale demonstrates that one compromised publish identity can spread poisoned packages across hundreds of versions and many repositories.
• The limiting control is not SBOM search alone, but strict runtime containment, token scoping, and immediate credential rotation after suspected exposure.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• 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.
• Token-Driven Propagation: A spread pattern where stolen automation credentials are reused to publish, sign, or deploy malicious software from trusted accounts. This turns a single compromise into repeated downstream exposure and is one of the clearest signs that a supply chain attack has crossed from theft into expansion.
• SBOM Correlation: The process of matching a software bill of materials against vulnerability, compromise, or malicious-package intelligence to determine where risky dependencies exist. In practice, it is most useful when paired with runtime and identity review, because the presence of a package does not tell you whether secrets were already exposed during installation.

What's in the full article

Arnica's full blog post covers the operational detail this analysis intentionally leaves at summary level:

• Step-by-step instructions for searching the SBOM for affected AntV and related npm packages
• The exact package families and versions identified as malicious in the campaign
• Guidance on how Arnica correlates source repositories and container images with impacted dependencies
• Why the vendor recommends checking for internal packages published after compromised npm installs

👉 The full Arnica post covers the affected package list, SBOM search steps, and response guidance in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It gives identity and security practitioners a shared framework for controlling automation credentials across modern platforms.