Red Hat npm package compromise shows CI secrets remain exposed

At a glance

What this is: Aikido reports a credential-stealing worm in official Red Hat npm packages that abused a compromised CI/CD path and harvested multiple secret types.

Why it matters: It matters to IAM and PAM teams because pipeline identity, workload secrets, and publish privileges now sit in the same attack path, so CI trust assumptions must be governed like high-risk access.

By the numbers:

• 96 versions across 32 packages have been compromised, cumulatively downloaded 116,991 times per week.

👉 Read Aikido's analysis of the Red Hat npm package compromise and credential-stealing worm

Context

Npm supply chain compromise becomes an identity problem when build pipelines, publish permissions, and machine credentials are treated as trusted by default. In this case, the primary risk is not just malware in packages, but the way CI/CD identity was used to publish them and then exfiltrate secrets from downstream environments.

For IAM and NHI practitioners, the important question is whether pipeline identities, service tokens, and developer secrets are governed as separate control domains or collapsed into one trust boundary. That distinction determines how quickly a compromised workflow can become a package-distribution and credential-theft event.

The attack pattern is no longer unusual. Similar compromises in package ecosystems have shown that once a CI path is abused, the blast radius extends well beyond the repository where the initial foothold appeared.

Key questions

Q: What breaks when a CI pipeline can publish packages with the same trust as a maintainer account?

A: The organisation loses the separation between source code approval and release authority. A compromised workflow can publish malicious artifacts while appearing legitimate, which means provenance checks alone are not enough. Teams need distinct identities, approval gates, and least-privilege publish rights for release automation.

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 package install scripts?

A: They treat install scripts as minor convenience features instead of execution points. A malicious preinstall hook can run before application code and before most defenders expect malicious behaviour. In CI and developer environments, that makes package lifecycle scripts a direct control surface.

Q: How should teams respond when CI or developer secrets are exposed?

A: Teams should identify the affected identities, revoke or rotate exposed credentials, review ownership and scope, and verify whether the compromised material reached any production-adjacent systems. The operational challenge is to close exposure quickly without breaking dependent services.

Technical breakdown

Trusted publishing becomes a compromised identity path

Trusted publishing replaces long-lived npm publish tokens with short-lived OIDC tokens issued through GitHub Actions. That reduces one secret class, but it does not remove the underlying dependency on pipeline integrity. If an attacker compromises the workflow, manipulates a repository, or gains access to the GitHub account behind the job, the publish action is still authenticated as a trusted automation path. The security model shifts from protecting a static token to protecting the identity and integrity of the CI runtime itself.

Practical implication: treat CI publish identities as privileged workload identities and protect them with the same lifecycle and access controls as any other high-risk credential.

Preinstall scripts turn package installs into execution points

A package preinstall script runs automatically during npm install, before application code executes. That makes the install phase an execution surface, not just a distribution step. In this incident, the malicious script ran without requiring user interaction beyond a normal dependency install, which is why package integrity checks, provenance validation, and dependency review matter before the code lands in a build or developer workstation. This is a classic supply chain pattern: the package arrives through a trusted channel and the malicious logic activates immediately.

Practical implication: block unsigned or unvetted packages from running install-time scripts in build and developer environments.

Credential sweep logic targets both human and non-human identities

The payload is built to harvest CI secrets, cloud access keys, service account credentials, SSH private keys, registry tokens, and environment files. That breadth matters because modern environments often store machine credentials alongside developer tooling and deployment credentials. Once collected, those secrets can be reused across cloud, source control, and package ecosystems. This is where NHI governance becomes central: service accounts, tokens, and publish permissions are not disposable artefacts, they are reusable identities with downstream access scope.

Practical implication: inventory where machine credentials are stored and restrict filesystem and environment access to the minimum required for each build job.

Threat narrative

Attacker objective: The attacker aims to steal reusable credentials at scale and turn trusted package distribution into a broader supply chain compromise.

1. Entry occurred through a compromised GitHub account and poisoned CI workflow that was used to publish malicious package versions.
2. Credential access followed when the payload harvested CI secrets, cloud credentials, SSH keys, and npm tokens from install and runtime environments.
3. Impact came from republished packages executing automatically on install, extending compromise into downstream developer and build 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

Pipeline identity is now part of NHI governance. The compromise shows that publish automation, repository access, and package release permissions function as non-human identities with real blast radius. When those identities are not lifecycle-managed, the organisation inherits a hidden control plane for software distribution. Practitioners should stop treating CI/CD permissions as engineering convenience and govern them as privileged machine access.

Standing trust in trusted publishing is the wrong assumption. OIDC removes one long-lived secret, but it does not guarantee that the workflow behind the token is healthy. This breach worked because the control plane still trusted the pipeline context after the account or repository was compromised. The governance failure is not token format, it is assuming that short-lived authentication alone prevents malicious publication.

Secret sprawl is the force multiplier. The malware succeeded because CI secrets, cloud credentials, and developer tokens were all reachable from the same execution path. That is a classic NHI segmentation failure: one compromised workload identity opened access to multiple environments. The named concept here is credential cascade risk, meaning one stolen machine identity becomes a path to many others unless access scope is tightly isolated.

Package ecosystems need identity-aware controls, not just integrity checks. Dependency scanners can flag known malware, but they do not address account takeover, workflow abuse, or malicious publication from a legitimate maintainer context. This incident reinforces OWASP NHI concerns around secret handling and over-privileged automation. The practical conclusion is that provenance, access boundaries, and secret placement must be governed together.

Open-source malware publication changes the threat model for every downstream team. Once tooling is public, copycat attacks can scale beyond the original actor, which compresses the time between first compromise and mass reuse. That is why machine identity protections in build systems now belong alongside code provenance and supply chain controls. Practitioners should assume attack methods will propagate faster than patch cycles.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 23.5% of security professionals are unsure about the biggest threat to their non-human identities, indicating a significant awareness gap, according to The 2024 Non-Human Identity Security Report.
• Ultimate Guide to NHIs , Static vs Dynamic Secrets helps teams pivot from standing secret assumptions to ephemeral credential patterns.

What this signals

Credential cascade risk: pipeline identities, publish permissions, and secret stores are converging into a single operational blast radius. That means the control problem is no longer just secret rotation, but how many downstream identities can be reached from one compromised build path. Teams should align this with least-privilege design and the identity governance patterns discussed in the Ultimate Guide to NHIs , Key Challenges and Risks.

Build and release systems now need the same identity segmentation thinking that security teams apply to privileged human access. If a compromised workflow can touch cloud tokens, npm publish rights, and SSH keys, then the programme has a single point of failure across multiple identity classes. The relevant policy anchor is OWASP Non-Human Identity Top 10.

The operational signal to watch is whether secret placement and publish authority are still colocated in the same runner, repo, or automation account. Where they are, a single compromise can become an ecosystem-wide incident. That is a strong candidate for immediate control redesign, not incremental tuning.

For practitioners

• Separate publish identity from build identity Use distinct credentials, repositories, and approval gates for code build, package signing, and package publication so a compromised workflow cannot directly publish to registries.
• Block install-time execution in trusted build paths Disable or tightly review package lifecycle scripts such as preinstall in CI and golden image pipelines, especially for packages that have not been explicitly approved.
• Inventory machine credentials reachable from CI jobs Map every secret exposed to build runners, including cloud keys, registry tokens, SSH keys, and service account tokens, then reduce each job to the minimum set required.
• Rotate all secrets touched by affected environments Treat any CI secret, cloud credential, SSH key, or npm token accessible from an affected workflow as compromised and rotate it through a controlled response process.

Key takeaways

• This incident shows that package publishing is an identity problem as much as a software integrity problem.
• The scale matters because dozens of package versions and more than one hundred thousand weekly downloads created a wide downstream exposure surface.
• The control that would have limited this event is strict separation of pipeline identity, secret scope, and package publication authority.

Key terms

• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• Credential Cascade: Credential cascade is the pattern where one exposed secret reveals access to another system, which then exposes the next secret in sequence. It is a common supply chain failure mode because reusable credentials let attackers move from one trusted environment to the next without needing a new exploit.
• Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.

What's in the full analysis

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

• The full list of compromised package names and affected versions for incident response and inventory work.
• The malware execution path inside the workflow and package payload for teams validating detections.
• The indicators of compromise and rotation guidance for CI secrets, cloud credentials, SSH keys, and npm tokens.
• The Aikido detection workflow and rescan process for teams using its package monitoring feed.

👉 Aikido's full post covers affected versions, the CI compromise path, and the rotation guidance for exposed credentials.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational risks that build pipelines and automated release systems create.