Notifications
Clear all
Topic starter
02/08/2026 11:29 am
TL;DR: A new npm worm affecting @redhat-cloud-services packages used compromised GitHub Actions OIDC tokens, preinstall hooks, and multi-stage secret harvesting to target cloud and development credentials across CI/CD environments, according to Semgrep and StepSecurity. The incident shows how package publishing and build-time trust assumptions can turn dependency installs into credential collection events.
NHIMG editorial — based on content published by Semgrep covering the Red Hat npm worm and compromised GitHub Actions OIDC tokens
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.
Questions worth separating out
Q: How should teams reduce risk from malicious npm package installs?
A: Treat package installation as a controlled operation, not an implicit trust event.
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.
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.
Practitioner guidance
- 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.
- Separate publishing identities from build identities Use distinct, tightly scoped identities for package build, test, and release.
- 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.
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.
👉 Read Semgrep's analysis of the Red Hat npm worm and compromised OIDC tokens →
npm worm and OIDC token abuse in CI/CD: what teams missed?
Explore further
02/08/2026 12:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: npm worm abuse of GitHub Actions OIDC tokens hits Red Hat
