Notifications
Clear all
Topic starter
20/08/2026 5:56 pm
TL;DR: Fourteen malicious npm packages impersonating OpenSearch and Elastic tooling executed during installation and targeted AWS, Vault, GitHub Actions, and npm publishing credentials, turning dependency installs on developer workstations and CI/CD runners into a credential-harvest path, according to Corgea.
NHIMG editorial — based on content published by Corgea: critical npm supply-chain campaign targeting cloud and CI/CD secrets
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context.
Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?
A: The main failure is assuming a compromised package only affects one project.
Q: What do security teams get wrong about typosquatted packages?
A: They focus on the package name and miss the second-stage objective.
Practitioner guidance
- Block lifecycle hooks where they are not required Set install policies so npm lifecycle scripts do not run by default in CI and on build hosts unless the package is explicitly approved for trusted execution.
- Separate build, publish, and cloud identities Use distinct credentials for development, CI build, package publishing, and cloud administration.
- Shorten the lifetime of all exposed secrets Replace durable credentials with short-lived tokens where possible, especially for AWS sessions, Vault authentication, and release automation.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact package names, version list, and install-time indicators that help teams confirm exposure in lockfiles, caches, and runner histories.
- The lifecycle-hook and stager sequence that shows how the malicious code executed before application tests began.
- The specific AWS, Vault, GitHub Actions, and npm token targets that matter when you are mapping blast radius across development and release systems.
- The remediation checklist for rotating exposed credentials, rebuilding trusted runners, and blocking the observed campaign infrastructure.
👉 Read Corgea's analysis of the npm supply-chain campaign targeting cloud and CI/CD secrets →
Typosquatted npm packages and secret theft: are your installs exposed?
Explore further
20/08/2026 6:36 pm
Install-time execution is now a governance problem, not just a build problem. The campaign shows that dependency installation can execute code before tests, runtime protections, or application controls are relevant. That shifts the control question to package-manager policy, runner hardening, and lifecycle-hook governance. In identity terms, the risk sits at the point where NHI secrets are present on a build host and an untrusted package can reach them. Practitioners should treat install-time execution as a formal trust boundary.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be critical than code-based leaks, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable when install-time malware exposes cloud or publishing secrets?
A: Accountability sits with the teams that own build trust, secrets lifecycle, and release access. If a runner can install untrusted code and reach high-value credentials, the governance gap is shared across platform engineering, IAM, and security operations. Frameworks such as NIST CSF and OWASP NHI both point to that overlap.
👉 Read our full editorial: Typosquatted npm packages exposed cloud and CI/CD secrets
