Notifications
Clear all
Topic starter
19/08/2026 4:00 pm
TL;DR: A single npm account published 11 packages at version 99.99.99 that executed on postinstall, harvested CI, cloud, and wallet secrets from build runners, and exfiltrated them to two collectors, according to Xygeni. The incident shows that dependency confusion is still a practical path to secret theft when pipelines trust public registries and allow install scripts to run.
NHIMG editorial — based on content published by Xygeni: dependency confusion in npm packages targeting CI/CD secrets
By the numbers:
- Ten packages went out inside a 29-second window, roughly one every three seconds.
- The attack used 11 npm packages, all published at version 99.99.99.
Questions worth separating out
Q: What breaks when dependency confusion is allowed in CI/CD pipelines?
A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft.
Q: Why do CI/CD runners increase the risk of secret theft from malicious packages?
A: Runners often contain the exact credentials attackers want, including registry tokens, cloud access keys, and .env material.
Q: How do security teams know if build-time secret exposure is actually contained?
A: Containment is real only when the exposed identities are revoked, not merely detected.
Practitioner guidance
- Pin internal package sources Configure package managers so internal namespaces resolve only to private registries and never fall through to public npm for owned names.
- Block install scripts in CI Use ignore-scripts or an equivalent policy for pipeline installs, then allowlist only the small set of packages that truly require lifecycle hooks.
- Reduce runner secret exposure Remove unnecessary .env files, limit environment variables, and stop mounting long-lived cloud or registry credentials into build jobs.
What's in the full analysis
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- Byte-level package behaviour, including the exact postinstall sequence and collector destinations
- The full list of environment variables and .env paths the payload attempted to read
- Timeline evidence showing how the packages were published in a coordinated burst
- Indicators of compromise that can be used for runner hunting and log review
👉 Read Xygeni's analysis of the dependency confusion cluster targeting CI secrets →
Dependency confusion in CI pipelines: what teams need to fix now?
Explore further
19/08/2026 4:37 pm
Dependency confusion is now an identity control failure, not just a packaging mistake. The core issue is that package resolution decides which non-human identity gets execution authority inside the build. When public registries are allowed to satisfy private names, the control plane that should protect internal software identities is effectively delegated to the internet. Practitioners should treat package source selection as part of identity governance, not only software hygiene.
A question worth separating out:
Q: Who should own controls for package source trust and runner secrets?
A: Ownership should be shared between platform engineering, IAM, and security operations. Platform teams control registry resolution and build policies, IAM governs the lifecycle of the credentials, and security teams monitor the runner for install-time egress and suspicious lifecycle execution.
👉 Read our full editorial: Dependency confusion in CI pipelines exposed crypto secrets at scale
