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

At a glance

What this is: This is an analysis of an ongoing npm supply chain worm that steals CI/CD secrets, persists in developer toolchains, and uses stolen tokens to create public GitHub infrastructure for continued abuse.

Why it matters: It matters because CI/CD credentials, runner memory, and developer environment secrets are part of the same identity attack surface, and conventional secrets management often stops at detection rather than revocation and containment.

By the numbers:

• 27 days
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read StepSecurity's analysis of the Mini Shai-Hulud npm supply chain attack

Context

npm supply chain attacks exploit trust in package publishing, build pipelines, and developer tooling, then convert that trust into credential theft and downstream compromise. In this case, the primary weakness is not the package manager alone but the combination of exposed secrets, permissive CI/CD runners, and long-lived tokens that survive after the initial compromise. The primary keyword here is npm supply chain attack, and the article shows how quickly it can become an identity and access problem once secrets are harvested.

The identity angle is direct: GitHub Actions runners, cloud tokens, Kubernetes credentials, Vault secrets, and package-manager tokens all function as non-human identities or supporting credentials. When those identities are readable from process memory or embedded in build paths, an attacker can move from package compromise to infrastructure creation in the same execution chain. That is a typical failure mode for modern CI/CD environments, especially where secret scoping and egress controls are weak.

Key questions

Q: What breaks when a malicious npm package can read CI/CD runner memory?

A: When a malicious package can read runner memory, secret masking no longer protects credentials because plaintext tokens are already present in process space. That breaks the assumption that build-time secrets are safe if they are not written to disk. The immediate result is cloud, GitHub, and Vault credential exposure inside the same execution context.

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 device revocation is actually working?

A: They should test the full authorisation path, not just the revoke request. A working control must remove effective access from the next access check, including legacy records and fallback branches. If a token can be revoked but the device still returns roles, revocation is only partial and the lifecycle model is broken.

Q: Who is accountable when a supply chain worm uses stolen tokens to create infrastructure?

A: Accountability sits with the teams that own software supply chain controls, CI/CD identity governance, and secrets lifecycle management. If a compromised token can create repositories or modify workflows, the issue is not only malware response. It is a governance failure across token scope, revocation speed, and build-system trust.

Technical breakdown

How malicious npm packages harvest CI/CD runner memory

The malicious payload runs during package installation and targets the GitHub Actions runner process directly. Instead of waiting for developers to leak credentials manually, it reads process memory, extracts masked secrets in plaintext, and enumerates file paths that commonly store cloud, container, and vault credentials. This is a powerful pattern because the attacker is not limited to source code secrets. Any credential reachable from the build environment becomes fair game once the install hook executes inside the runner context.

Practical implication: treat package-install execution as a privilege boundary and block memory-reading behaviour on CI runners.

Why token abuse turns theft into persistent infrastructure

The payload does not stop at exfiltration. It uses stolen GitHub tokens to create public repositories that act as dead-drops and campaign markers, which turns compromised identity material into attacker-controlled infrastructure. That matters because a stolen token is not only a credential, it is an identity with publishing rights, repository creation permissions, and the ability to automate follow-on activity. In practice, this collapses the line between data theft and operational persistence.

Practical implication: scope CI/CD tokens to the minimum publishing action and revoke any token that can create repositories or modify workflows.

Why obfuscated exfiltration channels evade simple secrets detection

The campaign uses two exfiltration paths, a GitHub API dead-drop and a fallback command-and-control endpoint disguised as an OpenTelemetry collector. That design defeats simplistic detection rules that only look for obvious outbound traffic or direct credential uploads. It also shows why secrets monitoring alone is insufficient. Attackers can blend exfiltration into legitimate developer and observability traffic unless egress is constrained and process ancestry is inspected.

Practical implication: combine egress allowlisting, process lineage alerts, and repository audit logs to catch exfiltration paths that look legitimate.

Threat narrative

Attacker objective: The attacker wants to turn package-install trust into reusable credentials, persistent access, and infrastructure that supports further supply chain operations.

1. Entry occurs when a maintainer account publishes a malicious npm package that triggers code execution during install.
2. Credential access follows when the payload reads GitHub Actions runner memory and harvests cloud, vault, and developer secrets from the environment.
3. Escalation and persistence happen when stolen tokens are used to create public repositories and plant backdoors in Claude Code and VS Code configurations.
4. Impact is sustained supply chain compromise, secret exfiltration, and attacker-controlled infrastructure for continued operations and lateral abuse.

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

Shai-Hulud is not just malware distribution, it is identity abuse inside the software supply chain. The interesting part of this campaign is not the package name or the obfuscation, but the way compromised build identities are turned into reusable control-plane access. When a CI runner can expose cloud, Vault, and GitHub credentials in memory, the attacker inherits the organisation's non-human identity estate rather than simply stealing data. Practitioners should treat package-install execution as a credential boundary, not a routine software event.

Standing secrets persistence is the real governance failure this campaign exposes. The article shows that stolen credentials remain operational long enough for attackers to create repositories and plant backdoors, which means revocation is not happening fast enough to matter. This is exactly where NHI governance breaks down: secret discovery exists, but lifecycle control, rotation enforcement, and invalidation lag behind actual abuse. Teams should measure exposure in minutes and hours, not in quarterly review cycles.

Package compromise now behaves like a supply chain identity incident, not a classic malware incident. The malicious payload uses GitHub tokens, workflow runners, and developer tooling as identity substrates. That means controls such as OWASP Non-Human Identity Top 10, NIST CSF access governance, and MITRE ATT&CK credential access mapping are all relevant, because the attacker is operating through identities that automation systems trust. Security teams should align supply chain defense with identity lifecycle control, or the same attack path will keep recurring.

Runtime exfiltration and persistence require a named control concept: secret-to-infrastructure drift. In this pattern, secrets stop being mere credentials and become the means to create new attacker-owned systems, repositories, and backdoors. That drift is what makes the blast radius expand after the initial leak, because each harvested token can create more persistence than the original compromise exposed. Practitioners should focus on preventing secrets from becoming operational infrastructure.

Agentic developer tooling increases the attack surface when it shares the same credential plane as CI/CD. The payload's persistence in Claude Code and VS Code configurations shows how developer-assist tooling can outlive a single job run and reintroduce compromised identity material across sessions. That is a governance gap across software delivery, endpoint security, and identity management. Teams should treat developer tooling state as part of the controlled NHI environment, not as an informal workspace.

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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Forward pivot: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.

What this signals

The operational signal is clear. Build systems are no longer just code delivery mechanisms, they are high-value identity zones where a single compromised package can expose cloud, GitHub, and vault credentials before defenders have a chance to react. That makes CI/CD runner hardening, token scoping, and egress control part of identity governance, not just DevSecOps hygiene.

Secret-to-infrastructure drift: once stolen credentials are used to create repositories, modify workflows, or plant persistence in developer tools, the original leak has become a living control-plane problem. Teams should watch for new public repositories, unusual workflow edits, and package-install ancestry linked to token use, then connect those signals to [OWASP Non-Human Identity Top 10](https://owasp.org/www-project-non-human-identities-top-10/) guidance and [MITRE ATT&CK Enterprise Matrix](https://attack.mitre.org) tactics for credential access and lateral movement.

The next step for practitioners is to collapse detection and revocation into one operating motion. If a malicious package is confirmed, the response needs to invalidate every credential reachable from the affected runner, then prove that the invalidated identity cannot still publish, create, or exfiltrate. That is the difference between containment and a continued supply chain incident.

For practitioners

• Block package-install execution on CI runners Prevent untrusted npm install hooks from running in build environments where runner memory contains cloud, GitHub, or vault credentials. Pair this with process-level restrictions that stop reads from /proc memory paths and alert on unexpected child processes during installation.
• Scope publishing tokens to the narrowest possible action Remove repository-creation and workflow-modification rights from CI/CD tokens unless they are explicitly required. Separate publish credentials from build credentials so a stolen token cannot both ship code and create attacker infrastructure.
• Revoke and rotate on first compromise signal Treat a confirmed malicious package install as an identity event, not just an endpoint event. Revoke GitHub, npm, cloud, and Vault tokens immediately, then validate that all secrets reachable from the affected runner have been reissued.
• Audit for dead-drop activity and unauthorized repository creation Search GitHub organisation logs for newly created public repositories, workflow edits, and unusual API activity tied to CI identities. Correlate those actions with package-install times to identify whether stolen tokens were already operationalised.
• Constrain egress from build and developer environments Allow only the outbound destinations required for package retrieval and approved developer services. Block disguised collector endpoints, then inspect any traffic to unknown domains that coincides with install-time script execution.

Key takeaways

• This campaign shows that npm supply chain compromise is also a non-human identity compromise, because stolen CI/CD secrets become the attacker’s control plane.
• The evidence points to a control gap in secret lifecycle management, where exposed credentials remain valid long enough to create infrastructure and persistence.
• The right response is faster revocation, tighter token scope, and build-environment containment, because detection alone does not stop secret-to-infrastructure abuse.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secret-to-Infrastructure Drift: Secret-to-infrastructure drift is the point at which stolen credentials stop being simple access tokens and become the means to create, modify, or persist attacker-controlled systems. The risk grows when a secret can publish code, create repositories, or alter automation after the initial leak.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Credential-Based Access: Any access path that depends on a secret such as a password, token, API key, or certificate rather than a federated identity assertion. It remains governable only when the organisation can discover where the credential is used, who owns it, and how it can be revoked.

What's in the full analysis

StepSecurity's full blog covers the operational detail this post intentionally leaves for the source:

• Process-by-process attack timeline showing how the malicious npm payload read runner memory and harvested secrets
• Package-by-package exposure list and version mapping for the affected AntV ecosystem releases
• Defensive product details for Harden-Runner, Secure Registry, and Dev Machine Guard in real-world workflows
• Indicators of compromise and response steps for teams validating whether their environments were touched

👉 The full StepSecurity post covers the affected packages, attack timeline, and response steps in more 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 for practitioners building resilient identity controls. It helps security teams connect lifecycle governance to real-world automation and supply chain risk.