Shai-hulud worm in SAP npm packages exposes secrets at scale

At a glance

What this is: A new Shai-Hulud worm variant in SAP npm packages is exfiltrating developer and cloud secrets into attacker-controlled GitHub repositories.

Why it matters: IAM, PAM, and NHI teams need to treat developer tooling, CI/CD runners, and package install paths as identity attack surfaces, not just software delivery channels.

By the numbers:

• OX Security identified over 1,200 repositories created by the attacker containing stolen developer credentials.
• @cap-js/sqlite has monthly downloads of about 1M, with weekly downloads around 260k.

👉 Read OXSecurity's analysis of the Shai-Hulud worm in SAP npm packages

Context

This is a secrets-exfiltration incident in the software supply chain, not just a malware story. The worm targets developer environments, CI/CD runners, and cloud control planes by harvesting tokens, environment variables, and API keys, then moving them into public GitHub repositories controlled by the attacker.

For identity practitioners, the key issue is that package installation has become an NHI trust event. A single malicious dependency can surface credentials that were never meant to leave build systems, and those credentials can then be reused across GitHub, cloud services, and downstream automation with very little friction.

Key questions

Q: How should security teams handle exposed developer secrets after a supply chain attack?

A: They should assume the secrets are reusable until proven otherwise, revoke them immediately, and trace where they were accepted before the compromise was contained. Developer tokens and keys often bridge source control, build systems, and cloud accounts, so response has to cover all three layers, not just the endpoint.

Q: Why do npm supply chain attacks create such a large blast radius?

A: Because install-time code can inherit access from developer laptops and CI runners, which often already hold cloud tokens, GitHub credentials, and automation secrets. One malicious dependency can therefore expose many non-human identities at once, and each identity may unlock more accounts, repositories, or secret stores.

Q: What do teams get wrong about key rotation after credential theft?

A: They treat rotation as a cleanup task instead of a control that limits the attacker’s window of use. If rotation is slow or incomplete, stolen secrets remain valid long enough for persistence, data theft, or further repository poisoning.

Q: Who is accountable when a compromised package exposes cloud or developer secrets?

A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.

Technical breakdown

How the worm uses package installation as an entry point

The malicious code lives inside npm packages and executes when developers or build systems install or update them. In this case, the payload is designed to run quietly, collect local secrets, and then move laterally into adjacent identity surfaces such as GitHub repositories and cloud provider control planes. That makes the package manager itself part of the attack path. The real exposure is not limited to the developer workstation. It extends to any environment where build-time trust is broad enough to let package code inherit credentials, tokens, or runner context.

Practical implication: Treat package install events as identity-bearing actions and restrict what credentials are available during build and deploy.

Why GitHub becomes the exfiltration and control plane

The worm packages stolen material into encrypted JSON blobs and uploads them to attacker-created GitHub repositories using normal repository APIs. That design gives the attacker both storage and a retrieval path without relying on a separate command server. Because the payload is written as ordinary repo content, it blends into legitimate developer workflows and is harder to distinguish from standard project activity. This is a useful reminder that source control systems can be used as both collaboration platforms and adversary infrastructure when tokens and repository permissions are overextended.

Practical implication: Monitor repository creation, unusual commit patterns, and secret-like filenames as identity abuse indicators, not just code changes.

How CI/CD secret harvesting turns one compromise into many

When the malware detects GitHub Actions on Linux, it looks for secret-shaped runtime data and then expands outward to AWS, Azure, and GCP secret stores. That is why runner identity and default cloud credentials matter so much. A build job often inherits privileges that were never intended for arbitrary code execution, especially when secret retrieval is automatic and ambient authentication is accepted by default. The attack succeeds by turning temporary build execution into a credential sweep across multiple systems.

Practical implication: Separate runner identity from cloud admin access and tighten which secrets are reachable inside automation contexts.

Threat narrative

Attacker objective: The attacker wants durable access to developer, CI/CD, and cloud credentials that can be reused for theft, persistence, and follow-on compromise.

1. Entry occurs through compromised npm packages that execute during normal install activity and drop malicious code into developer and build environments.
2. Credential access follows as the worm harvests tokens, environment variables, GitHub Actions secrets, and cloud secret-store credentials from the host and runner context.
3. Impact is achieved by uploading encrypted exfiltrated data to attacker-controlled GitHub repositories and by planting malicious files that can spread through future checkouts and builds.

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

Secret sprawl in developer tooling is now an identity problem, not a software hygiene problem. This worm works because package installs, build runners, and cloud SDK defaults can all inherit usable credentials at the point of execution. Once those credentials exist in the workflow, the attacker does not need a fresh login path, only a way to collect and export what is already trusted. The practitioner conclusion is that developer environments must be governed as NHI attack surfaces.

GitHub is functioning as both a collaboration layer and an exfiltration layer. The article shows how attacker-controlled repositories can absorb stolen secrets while looking like ordinary project activity. That collapses the old assumption that source control is only where code lives. The practitioner conclusion is that identity monitoring must extend into repository creation, commit patterns, and unusual file paths as evidence of credential abuse.

Continuous trust in CI/CD runners is the wrong model for modern supply-chain attacks. Runners frequently inherit cloud and repository permissions that outlast the task being performed. In practice, that means one malicious dependency can harvest secrets across GitHub, AWS, Azure, and GCP in a single execution path. The practitioner conclusion is that build-time privilege must be scoped as tightly as production access.

Key rotation is not an incident response afterthought, it is the boundary condition for limiting NHI blast radius. The article’s remediation guidance is correct because stolen tokens and API keys are already the attacker’s objective. If rotation is slow, manual, or inconsistent, the compromised identity keeps its value long after the malware is removed. The practitioner conclusion is to treat every exposed secret as a live account until proven otherwise.

Identity blast radius is now defined by where secrets can move, not just where malware first lands. The named concept here is the gap between initial package compromise and the number of systems a stolen token can reach. When one credential can touch GitHub, build systems, and cloud secret stores, the real control question is containment across trust domains. The practitioner conclusion is that entitlement scope must be measured by downstream reach, not just by origin system.

What this signals

Identity blast radius is now the right lens for supply-chain defense, because one compromised package can expose multiple credential stores before any traditional endpoint alert fires. Teams should measure how far a build identity can move, not just whether it exists.

The operational priority is to harden the intersection of source control, CI/CD, and cloud secret stores. When those three layers share trust, adversaries can reuse a single stolen credential across GitHub, runner infrastructure, and the target cloud control plane.

If you are still treating developer secrets as peripheral to IAM, this incident shows the opposite. Package-driven compromise is a governance event, and the control answer is tighter credential scope, faster revocation, and better separation between build execution and secret access.

For practitioners

• Inventory package install trust paths Map where npm installs can execute with access to GitHub tokens, cloud credentials, or build metadata. Remove ambient secrets from build contexts that do not explicitly need them, and prefer isolated installation stages for untrusted dependencies.
• Shorten the lifetime of developer and runner credentials Rotate GitHub, npm, and cloud tokens on a fixed cadence and immediately after any suspected exposure. Prioritise credentials used by CI/CD runners, because the article shows they are high-value targets for stealthy exfiltration.
• Watch for attacker-controlled repository creation patterns Search for public repositories containing the string A Mini Shai-Hulud has Appeared, then hunt for suspicious results directories and timestamped JSON blobs. Also alert on sudden repository creation from developer accounts that normally do not publish code.
• Restrict runner access to cloud secret stores Limit AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and STS access from automation identities unless the workflow genuinely requires it. Separate deploy permissions from secret retrieval permissions so compromise in one lane does not expose the full control plane.
• Add time-based dependency controls Delay installation of newly published packages where practical, especially in high-trust build chains. The article recommends only pulling packages older than 24 hours, which reduces exposure to freshly poisoned releases and fast-moving worm activity.

Key takeaways

• This worm turns package installation into an identity compromise path, because it can harvest and reuse developer, runner, and cloud credentials in one chain.
• The scale is material, with more than 2.2M monthly package downloads and over 1,200 attacker-created repositories used to move stolen secrets.
• The limiting control is not just malware detection, but faster rotation, narrower runner access, and less ambient trust in build-time identities.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runner Identity: The credentialed identity used by a CI/CD runner or build agent to execute automation tasks. It is often broader than teams realise because it can inherit repository, cloud, and deployment permissions that make a single compromised job highly valuable to an attacker.
• Ambient Trust: Access granted implicitly by environment, defaults, or shared execution context rather than by explicit task-scoped approval. For non-human identities, ambient trust is dangerous because code execution and credential access can occur in the same session without a clear governance boundary.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.

What's in the full analysis

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

• Package names and fixed versions for the affected SAP npm modules.
• The repository naming pattern and the "results" directory structure used for exfiltration.
• The malware's credential collection flow across GitHub Actions and cloud secret stores.
• The article's immediate response guidance for developers and security teams.

👉 The full OXSecurity post covers the affected package list, exfiltration pattern, and immediate response steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.