npm worm abuse of GitHub Actions OIDC tokens hits Red Hat

At a glance

What this is: Semgrep says an npm worm compromised multiple @redhat-cloud-services packages and used GitHub Actions OIDC tokens plus preinstall hooks to steal CI/CD and cloud credentials.

Why it matters: This matters because CI/CD pipelines often treat package install and federated token issuance as routine, yet both can become privilege-propagation paths for NHI abuse.

Context

The core problem is not just malware in a package registry, but the way build and release pipelines trust package install events and federated identity tokens as routine automation. In this case, an npm preinstall hook became an execution point, and a compromised GitHub Actions OIDC token became the publishing path for malicious packages.

For NHI governance, that combination matters because it collapses the boundary between source control identity, build identity, and package publishing identity. When those trust links are weakly governed, a single compromised token can move from repository access into package distribution and secret harvesting across CI/CD, cloud, and developer tooling.

Key questions

Q: What should teams do first when an npm package can run preinstall scripts in CI/CD?

A: First, decide whether install-time scripts are allowed in the environment at all. If they are necessary, separate trusted build paths from general package consumption and restrict them to controlled pipelines. The goal is to prevent arbitrary code execution during dependency install from becoming a normal identity pathway into secrets and release credentials.

Q: Why do compromised CI tokens and package secrets create broader risk than a single code issue?

A: Because those tokens act as machine identities that can publish code, run workflows, and reach cloud services. Once an attacker controls them, the compromise moves from code integrity to identity governance, which expands the blast radius across build systems, repositories, and infrastructure.

Q: What are the warning signs that a build environment has become a credential concentration zone?

A: Look for runners or developer workstations that hold cloud keys, package manager tokens, vault tokens, and federated workflow credentials at the same time. If the same environment can read secrets, publish artifacts, and access infrastructure, the attack surface is already concentrated. That is the point where compromise becomes system-wide, not local.

Q: What is the difference between short-lived OIDC tokens and static CI/CD secrets in supply chain risk?

A: Short-lived OIDC tokens reduce persistence, but they do not eliminate abuse if the workflow context is already compromised. Static secrets are easier to steal and reuse later, while federated tokens are harder to persist but can still authorize immediate malicious action. Governance should evaluate both the lifetime and the authority of the credential.

Technical breakdown

How preinstall hooks turn npm install into code execution

npm preinstall scripts run automatically during installation unless scripts are disabled, which means a package can execute arbitrary code before the consuming team has any meaningful inspection step. In this case, the malicious package used that feature to launch an obfuscated index.js payload. The important mechanism is not just obfuscation, but execution at install time, when developers and pipelines usually assume the package is still inert. That creates an identity security problem because the install process itself becomes a trusted execution path.

Practical implication: treat package-install execution as a policy boundary and decide when scripts are allowed to run at all.

Why GitHub Actions OIDC tokens can amplify package supply chain abuse

GitHub Actions OIDC tokens are federated credentials that let workflows exchange short-lived identity assertions for cloud or publishing access without storing static secrets. That model reduces secret persistence, but it also means a compromised workflow context can mint legitimate publishing or cloud-adjacent access. In this incident, the token was used to publish malicious packages, which shows how identity federation can be repurposed as a supply chain control plane if the workflow, repository, or trust policy is compromised. The risk is not OIDC itself, but over-broad trust in what the token can authorize.

Practical implication: scope federated token trust to the minimum repository, workflow, and package actions required for publishing.

Why credential harvesters target CI/CD and cloud environments together

The payload targeted GitHub Actions, AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm tokens, and CircleCI because build systems often contain the most reusable credentials in the environment. Once a package runs inside a developer workstation or runner, it can search local files, environment variables, and runner memory for secrets that unlock broader access. That pattern matters for NHI governance because the compromise is rarely limited to one secret type. It is the credential graph, not a single token, that defines blast radius.

Practical implication: classify CI/CD runners and developer workstations as credential-rich NHI environments and monitor them accordingly.

Threat narrative

Attacker objective: The objective was to steal reusable credentials and turn a trusted software distribution path into a propagation mechanism for further compromise.

1. Entry occurred through malicious npm package versions in the @redhat-cloud-services namespace that executed automatically during npm install via preinstall hooks.
2. Credential access followed when the payload harvested GitHub Actions, cloud, package manager, and vault secrets from environment variables, local files, and runner memory.
3. Escalation and propagation occurred when the attacker used compromised GitHub Actions OIDC tokens to publish additional malicious packages and expand distribution.
4. Impact was credential theft and worm-like spread across CI/CD and cloud-adjacent identities, increasing the likelihood of further repository and environment compromise.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build-time trust has become an identity boundary, not just a software-delivery concern. This incident shows that package installation can no longer be treated as a passive dependency event when scripts execute automatically and publishing credentials are available in the same workflow. The governance issue is the assumption that build systems only consume code, when in practice they also execute and redistribute it. Practitioners need to govern install-time execution as part of identity and access policy, not as a developer convenience setting.

GitHub Actions OIDC trust is only as narrow as the workflow policy behind it. Federated identity reduces static secret storage, but it does not reduce blast radius when the workflow itself can publish packages or reach cloud permissions. The failure mode here is not token longevity, but token authority that outpaces the trust context in which it was minted. Identity governance teams should treat OIDC trust policy as a publishing control surface, because compromise of that surface can rebind identity to malicious software distribution.

CI/CD environments now behave like credential concentration zones. The worm targeted secrets from clouds, package managers, vaults, and runner memory because those environments accumulate high-value non-human identities in one place. That concentration changes the risk model for service identities, ephemeral tokens, and build runners alike. The practical conclusion is that CI/CD must be governed as an NHI estate with separate ownership, inventory, and containment assumptions, not as a neutral automation layer.

Identity reuse across source control, build, and release systems creates a wormable trust graph. When the same workflow can read secrets, publish packages, and reach cloud APIs, a compromise in one node can become a distribution event in another. That is a structural governance problem, not just a malware family problem. Practitioners should map where federated identity, package publishing, and secret access overlap, because that overlap defines the attack path more accurately than any single IOC.

Ephemeral credentials do not eliminate trust debt when the actor can still act during the session. The issue is not that tokens last too long, but that they authorize too much within the time they are valid. Once a malicious package or compromised workflow can use those permissions before expiry, the governance model has already failed. Teams should re-evaluate whether their credential lifecycle matches the speed of install-time execution and secret harvesting.

What this signals

Install-time execution is now part of identity governance. Security teams should treat package lifecycle hooks as privileged execution paths because they can invoke code before conventional review or sandbox steps occur. That changes how CI/CD policy, developer workstation controls, and package allowlisting should be designed for NHI-heavy environments.

Credential harvesting succeeds when build systems are treated as low-risk automation. The article shows that a single malicious dependency can search for cloud keys, vault tokens, package manager credentials, and runner memory in one pass. That makes runner hardening, secret scoping, and federated trust policy central to blast-radius reduction.

GitHub Actions OIDC trust needs the same scrutiny as any other publishing permission. If a workflow can mint tokens that reach package repositories or cloud services, then it is part of the organisation's identity perimeter. The practical response is to re-map which workflows can publish, which can deploy, and which should never hold reusable authority.

For practitioners

• Restrict package script execution Disable automatic execution of lifecycle scripts where possible, and require explicit approval for packages that need install-time code execution in build or developer environments.
• Scope GitHub Actions OIDC trust tightly Limit which repositories, workflows, and audiences can mint publishing or cloud-facing tokens, and remove broad trust relationships that let one workflow publish on behalf of many projects.
• Separate publishing identity from build identity Use distinct credentials for package publishing, CI execution, and cloud access so a compromised runner cannot automatically inherit the permissions needed to republish or pivot.
• Hunt for credential-rich runner exposure Review runner memory, environment variables, .npmrc, .aws/credentials, and vault token locations for evidence of leakage in systems that installed the affected packages.
• Rotate secrets tied to CI/CD and developer tooling Prioritise npm tokens, GitHub Actions secrets, cloud keys, vault tokens, and any credentials stored in .env files or local developer profiles if they may have been exposed.

Key takeaways

• The incident shows how a malicious dependency can convert package installation into an execution and credential-harvesting event.
• The payload targeted multiple identity stores at once, including CI/CD secrets, cloud credentials, package tokens, and vault access.
• Limiting install-time script execution and narrowing federated publishing trust are the controls most directly tied to reducing the blast radius.

Key terms

• Prepare Lifecycle Hook: An install-time script that runs automatically when an NPM package is prepared or installed from a Git source. It is powerful because it executes before many defenders expect code to run, turning dependency resolution into an execution surface if the source is malicious or compromised.
• GitHub Actions OIDC Token: A short-lived federated credential issued to a workflow so it can authenticate without storing long-lived secrets. In security programmes, the token is only as safe as the workflow permissions, repository trust, and downstream services that accept it.
• Credential Concentration Zone: A credential concentration zone is an environment where many high-value secrets, tokens, and keys are available in one place, such as a build runner or developer workstation. These zones increase blast radius because one compromise can expose multiple identity domains at once, including cloud, package, and vault access.
• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.

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.