npm worm abuse of GitHub Actions OIDC tokens hits Red Hat

At a glance

What this is: This is an analysis of an npm worm that abused compromised GitHub Actions OIDC tokens to publish malicious packages and harvest secrets at install time.

Why it matters: It matters because CI/CD identities, package publishing rights, and ephemeral build tokens now sit on the same attack path as cloud credentials and must be governed as one exposure surface.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Semgrep's analysis of the Red Hat npm worm and compromised OIDC tokens

Context

npm supply-chain attacks against non-human identities are especially dangerous because they do not need a successful login to do damage. A malicious package can execute during installation, reach into CI/CD memory and environment variables, and steal the very secrets that govern cloud, registry, and deployment access.

In this incident, the identity problem is not just the compromised package. It is the combination of published-package trust, build-time script execution, and broad token reach across GitHub Actions, cloud providers, vaults, and registry credentials. That is a classic NHI governance failure: the actor is machine-run, but the blast radius is human-scale.

The presence of OIDC tokens in the publishing chain matters because short-lived federation does not help when token issuance, package publication, and install-time execution all sit inside one trusted automation path. The result is a credential supply chain that can be repurposed faster than most teams can detect it.

Key questions

Q: How should teams reduce risk from malicious npm package installs?

A: Treat package installation as a controlled operation, not an implicit trust event. Restrict secret exposure in build environments, separate publish rights from routine development access, and make secret rotation and revocation part of incident response, especially for systems that handle CI/CD credentials.

Q: Why do short-lived OIDC tokens still leave organisations exposed?

A: Short-lived tokens reduce static secret reuse, but they do not fix over-trusted workflows. If a GitHub Actions identity can publish packages or access broad resources, an attacker who compromises the workflow can still abuse that authority before the token expires. Ephemeral credentials are safer only when the trust boundary is narrow.

Q: What do security teams get wrong about developer and CI secrets?

A: They often treat these secrets as operational conveniences instead of high-value identities. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.

Q: Who is accountable when a package publishing identity is abused?

A: Accountability sits with the team that owns the publishing workflow, the repository trust model, and the secrets reachable from that workflow. Security, platform, and application owners all share responsibility where package release rights and CI/CD credentials overlap. A clean ownership model is part of non-human identity governance, not an optional extra.

Technical breakdown

Preinstall hooks turn npm install into execution

npm packages can run arbitrary scripts during install through lifecycle hooks such as preinstall. That means the package manager is not only fetching code, it is executing code before a developer or pipeline has a chance to review behaviour. In this case, the worm used a large obfuscated index.js payload and install-time execution to begin secret harvesting immediately. The risk is structural: dependency trust is inherited at install time, not earned at runtime.

Practical implication: restrict script execution in build and developer environments, and treat package installation as an execution boundary, not a file transfer.

Why GitHub Actions OIDC tokens become a publishing path

GitHub Actions OIDC tokens are designed to replace long-lived credentials with short-lived federated authentication. That reduces static secret exposure, but only if the workflow, repository permissions, and token scope are tightly constrained. Here, the attacker republished malicious packages using compromised GitHub Actions OIDC tokens from a repository in the publishing chain. Once the identity that can publish packages is compromised, the automation path itself becomes the distribution mechanism.

Practical implication: narrow repository trust, constrain publish workflows, and separate build identities from package release identities.

Secret harvesting across CI/CD, cloud, and registries

The worm targeted a wide range of material: GitHub Actions tokens, AWS keys, GCP and Azure credentials, Vault tokens, Kubernetes service account tokens, npm tokens, and developer workstation files. That breadth matters because CI/CD systems often aggregate identities from many platforms into one runtime. A single compromised install can therefore expose both runtime secrets and publish rights, allowing the attacker to move from one project to many through republishing and repo creation.

Practical implication: inventory where CI/CD jobs can read secrets, and reduce cross-platform credential reuse inside build runners.

Threat narrative

Attacker objective: The attacker wanted to convert trusted package distribution and CI/CD execution into a scalable secret-harvesting and republishing channel.

1. Entry occurred through compromised GitHub Actions OIDC tokens and malicious npm package publication in the RedHat cloud-services ecosystem.
2. Credential access followed when the preinstall payload executed automatically during npm install and harvested secrets from runners, environments, and developer files.
3. Impact came from republishing the worm, stealing cloud and toolchain credentials, and creating a spread path that could reach additional repositories and environments.

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

Package installation is now an execution boundary, not a retrieval step. The worm succeeds because npm install still carries implicit trust in lifecycle scripts. That assumption made sense when packages were relatively static and low risk, but it fails when packages can run credential harvesters the moment they are installed. The practitioner conclusion is simple: build and developer pipelines must treat dependency installation as active code execution.

GitHub Actions OIDC does not eliminate publishing risk when the publishing identity is over-trusted. Short-lived federation reduces static secret exposure, but it does not prevent abuse of the workflow that can mint or use the token. If the repository or workflow can republish packages, the identity path itself becomes the supply chain. Teams should stop equating ephemeral credentials with low risk when the identity can still publish at scale.

Credential sprawl across CI/CD creates identity blast radius. This worm targeted cloud credentials, vault tokens, registry tokens, and local developer secrets because modern build environments often collapse many identities into one runtime. The result is not just theft of one secret type, but lateral reuse across infrastructure, package managers, and deployment systems. Practitioners should model CI/CD as a high-density NHI concentration point, not a narrow build service.

Ephemeral credentials reduce dwell time, but they do not remove trust debt. The real issue is not merely secret lifetime. It is that automated systems frequently inherit broad authority, then execute code from untrusted upstream sources before any human can intervene. That is the trust debt hidden inside many NHI programmes: access is provisioned for convenience, but the execution context is far more privileged than the change being made. The conclusion is that governance must follow the execution path, not just the secret.

Multi-cloud secret harvesting shows why NHI governance must be cross-platform. The worm did not confine itself to one ecosystem, and neither do attackers. GitHub, AWS, GCP, Azure, Kubernetes, Vault, CircleCI, and npm were all within the target set. That means identity governance based on single-platform controls will miss the actual attack surface. Practitioners need one policy view across all machine identities that can publish, deploy, or read secrets.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• Another finding from the same research shows that 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which keeps secret sprawl in the attack path.
• For a broader breach lens, 52 NHI Breaches Analysis shows how identity exposure repeatedly becomes the first stage of compromise and propagation.

What this signals

Identity blast radius is the concept practitioners should take from this worm. When a CI/CD runner can see cloud keys, vault tokens, registry credentials, and package publish rights, one compromised workflow can become a cross-platform incident. Teams should map every build identity to the secrets it can touch and assume attackers will chain those privileges together.

With 23.5% of professionals unsure about the biggest threat to their non-human identities, the problem is no longer just technical hygiene. It is classification and visibility. If teams cannot quickly identify which workflows can publish packages or read secrets, they cannot contain supply-chain compromise before it spreads.

For practitioners, the practical shift is toward Ultimate Guide to NHIs , Static vs Dynamic Secrets as a governance model, not just a secrets tactic. Static credentials inside CI/CD are still too easy to repurpose, while dynamic controls only work if the identity boundary is narrow enough to enforce them.

For practitioners

• Disable lifecycle scripts where they are not required Block or strictly gate npm preinstall and similar package lifecycle hooks in CI/CD and developer endpoints. If scripts must run, execute them in isolated build stages with no access to cloud, registry, or vault secrets.
• Separate publishing identities from build identities Use distinct, tightly scoped identities for package build, test, and release. Do not let the same GitHub Actions workflow or OIDC trust path both build artifacts and publish them to package registries.
• Reduce secret access in runners to the minimum set Audit which secrets are readable by each CI/CD runner and remove environment variables, mounted files, and cached tokens that are not needed for the current job. Pay special attention to cloud credentials, Vault tokens, and npm publish rights.
• Scan for compromised package versions and immediate republishing risk Check dependency inventories for the affected package versions, then hunt for any downstream package owners who could republish malicious updates from trusted credentials. Treat package publish permissions as an escalation path, not a routine admin right.

Key takeaways

• This worm shows that npm install can function as an execution channel, turning dependency trust into immediate secret exposure.
• The strongest evidence here is the breadth of stolen material, which spans CI/CD, cloud, registry, vault, and workstation credentials.
• Containment depends on separating publishing rights from build rights and removing unnecessary secret access from runners.

Key terms

• Npm Worm: A malicious package or package chain that spreads by abusing dependency trust and automation. In practice, it can execute install-time code, steal credentials, and republish itself into other projects, making package management part of the attack surface rather than a safe delivery channel.
• 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.
• 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.
• 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.

What's in the full analysis

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

• Full package list and indicators of compromise for the RedHat cloud-services npm organisation.
• Malware behaviour details, including the preinstall hook sequence and memory scraping paths in GitHub Actions runners.
• Credential categories targeted across AWS, GCP, Azure, Vault, Kubernetes, npm, and CircleCI environments.
• Practical customer guidance for checking advisories and validating whether malicious versions were installed.

👉 Semgrep's full post covers the affected packages, exploit chain, and indicators of compromise.

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.