Dependency confusion in CI pipelines exposed crypto secrets at scale

At a glance

What this is: This is an analysis of a dependency confusion cluster in npm where 11 fake crypto-tooling packages used install-time execution to steal secrets from CI/CD runners.

Why it matters: It matters because CI/CD identities, tokens, and environment secrets are high-value non-human credentials, and this pattern shows how package trust decisions can turn build automation into an exfiltration path.

By the numbers:

• 29-second window
• The attack used 11 npm packages, all published at version 99.99.99.

👉 Read Xygeni's analysis of the dependency confusion cluster targeting CI secrets

Context

Dependency confusion is a package resolution problem, but its impact is an identity and secrets problem. When build systems are allowed to resolve internal names from public registries, the package manager becomes a trust broker for non-human identities such as CI tokens, cloud keys, and deployment credentials. In this case, the primary failure was not a sophisticated exploit chain but a packaging and trust boundary collapse in the software supply chain.

The Xygeni analysis shows how quickly that boundary can be crossed when install scripts are permitted to run in CI/CD. The payload did not need interactive access, user approval, or post-compromise persistence. It only needed a pipeline that trusted a public package name and ran its postinstall hook, which is a common starting position in many build environments rather than an unusual one.

Key questions

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. The failure is not only malware execution. It is the loss of control over where code comes from and what identity-bearing material the runner exposes during install.

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. They also install dependencies non-interactively, so a postinstall script can run before anyone notices. When those two conditions combine, package abuse becomes a direct secrets collection problem.

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. Teams should verify that CI tokens, cloud access keys, registry secrets, and any signing or wallet material tied to the affected runner have been rotated and that no remaining pipeline can still use them.

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.

Technical breakdown

How dependency confusion turns package resolution into an access problem

Dependency confusion works when a build tool accepts the same package name from more than one registry and prefers the highest version it can find. A hostile public package can therefore override an intended private package if the resolver is not pinned to the private source or scoped correctly. In this case, the attacker used an artificially high version number to win the selection logic without needing to know the target's internal versioning scheme. The result is not just a supply chain compromise but an identity compromise, because the package runs inside the pipeline context that already holds secrets and privileges.

Practical implication: pin internal namespaces to private registries and block fallback to public npm for owned package names.

Why postinstall hooks are a high-risk execution path

npm lifecycle scripts such as postinstall execute automatically during dependency installation. That means code can run before a human ever imports or inspects the package, which makes the install step itself a privileged execution moment. In CI, this is especially dangerous because the environment commonly contains tokens, repository credentials, and cloud access needed for deployment. The attack here relied on that design: the package did not need a runtime exploit because install-time execution was already enough to reach the secrets.

Practical implication: disable install scripts in CI wherever possible and allowlist only the dependencies that genuinely require them.

How secret harvesting from runners expands blast radius

Build runners often accumulate environment variables, .env files, and mounted credentials from multiple systems. A malicious package can sweep all three in one pass, then exfiltrate the results before the job finishes. The Xygeni sample also disabled TLS certificate verification on outbound requests, which reduces the chance of interception controls flagging the traffic and makes the transfer look like ordinary egress. In other words, the runner becomes both the source of the secrets and the transport for the theft.

Practical implication: treat runner environments as secret-rich assets and monitor install-time egress as a control point.

Threat narrative

Attacker objective: The objective was to harvest CI, cloud, and wallet credentials from build infrastructure by abusing trusted package installation behaviour.

1. Entry occurred when the attacker published lookalike packages with internal-style names and an inflated version number to win dependency resolution.
2. Credential access followed when the postinstall script executed inside the CI/CD runner and read environment variables and .env files containing tokens and keys.
3. Impact came when the collected secrets were sent to attacker-controlled collectors and copied into local temporary files and build logs.

NHI Mgmt Group analysis

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.

CI/CD runners are privileged secret repositories that behave like production systems. The article makes clear that runners commonly hold cloud keys, registry tokens, deployment credentials, and local secret files. That means a compromised install hook can reach multiple layers of access in one execution path. NHI governance must therefore extend to build infrastructure, where machine identities often have broader effective power than user accounts.

Install-time execution is a standing privilege window for software packages. Postinstall scripts create a moment where code can act before provenance checks, runtime monitoring, or human review meaningfully intervene. That pattern aligns with the broader problem of Zero Standing Privilege for machines: code should not retain default authority to execute with hidden side effects. Practitioners should minimize lifecycle scripts as a trust boundary, especially in pipelines that manage secrets.

Secret sprawl in CI systems is the named concept this incident exposes. Here, secret sprawl is the uncontrolled spread of credentials across environment variables, .env files, runner directories, and tool-specific tokens. The more places secrets are present, the more a single malicious dependency can harvest. The practical conclusion is that identity teams and platform teams must converge on runner hardening, scoped credentials, and aggressive secret minimization.

Build-time exfiltration shows why secret revocation has to outpace detection. Even when the initial leak is detected quickly, any credential that remains valid can still be abused after the fact. That makes automated revocation, short-lived credentials, and narrow runner scope the important controls, not retrospective log review alone. Teams should assume a successful package-based theft can move faster than manual cleanup.

What this signals

Secret sprawl is the control problem underneath this incident. When credentials live in environment variables, .env files, runner directories, and pipeline metadata, one malicious dependency can harvest far more than a single token. The operational response is to reduce secret residency, shorten credential lifetimes, and align pipeline design with OWASP Non-Human Identity Top 10 guidance for secret and privilege governance.

The most important shift for practitioners is to treat build systems as identity-bearing infrastructure. That means registry trust, runner access, and token lifecycles should be managed together rather than as separate engineering concerns. The same discipline that protects workload identity also has to apply to the software supply chain that provisions it.

Dependency confusion creates a verification gap between name and source. The package name looks internal, but the trust decision is external unless registry policy prevents it. Teams should pair source pinning with strong control mapping in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, authenticator management, and system integrity.

For practitioners

• 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.
• Alert on package-install egress Treat outbound HTTPS from dependency installation as suspicious, especially when the destination resembles request-capture services or TLS verification is disabled.
• Rotate exposed credentials immediately If a runner shows signs of secret harvesting, revoke CI tokens, cloud keys, registry tokens, and any wallet seeds or private keys present in that job context.

Key takeaways

• This incident shows that package resolution can become a credential attack path when private names are allowed to resolve from public registries.
• The scale is not theoretical because the payload targeted dozens of secret sources and was designed for CI/CD environments that already hold high-value non-human credentials.
• The practical fix is to combine registry pinning, script restriction, and rapid credential revocation, because detection alone does not stop reuse.

Key terms

• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

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

👉 The full Xygeni post covers the package list, runner artefacts, and exfiltration indicators in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suited to practitioners who need to align identity controls with pipeline, platform, and access governance.