Dependency confusion in NPM supply chains is now an identity problem

At a glance

What this is: Panther's analysis shows a 38-package NPM campaign abusing dependency confusion and postinstall hooks to steal credentials from CI/CD environments through malicious internal-looking package names.

Why it matters: It matters because build pipelines now sit inside the identity perimeter, where package trust, secret handling, and publisher control directly affect NHI and IAM governance.

By the numbers:

• A 38-package NPM campaign was identified as part of the supply chain attack, according to Panther.
• Panther found 38 malicious packages published between 2026-04-24 and 2026-04-30.

Context

Dependency confusion is a package-resolution failure where build tools pull a public package name before the intended private package. In CI/CD, that matters because the installer runs with access to secrets, tokens, and build credentials, so a package name becomes an access path rather than just a dependency label.

This campaign shows why identity governance now reaches into software delivery. When publisher accounts rotate, postinstall hooks execute automatically, and secrets sit in the build environment, the control problem shifts from code review to trusted execution, secret scoping, and publisher lifecycle management.

The article's starting position is typical of modern supply-chain abuse: it uses ordinary build mechanics rather than exotic exploitation. That makes the governance gap more common, not less serious.

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 malicious packages that steal secrets create identity risk beyond the developer workstation?

A: Because secrets are often the keys to downstream systems, not just local tools. A browser credential, API token, or .env secret can expose cloud services, CI systems, or machine accounts after the initial host compromise. Identity teams should treat leaked secrets as access lifecycle failures with cross-environment impact.

Q: What signals show that package trust controls are failing?

A: Repeated version bursts, lookalike names, inflated release numbers, and internal namespace collisions are all signs that the build pipeline is still treating naming as proof of trust. If those packages can be published and reach builds before review catches them, the organisation does not have effective source provenance or registry governance.

Q: How should teams respond when a package publisher account is rotated or replaced?

A: Treat it as an identity event, not just a registry event. Revalidate package ownership, inspect lineage across related accounts, revoke any credentials that were exposed to the old publisher path, and review whether the package namespace should remain allowed in the build process.

Technical breakdown

How dependency confusion turns package names into execution paths

Dependency confusion exploits the way package managers resolve names across private and public registries. If an internal package name is mirrored publicly, the installer can fetch the attacker-controlled version first, especially when naming conventions imply legitimacy. In CI/CD this is amplified because install steps often run automatically, with network access and environment variables already present. The issue is not just the code inside the package. The real problem is that the package manager is being asked to make a trust decision based on name collision rather than provenance, publisher identity, or an allowlisted source.

Practical implication: Treat package resolution as an identity decision and restrict which registries can satisfy internal package names.

Why postinstall hooks are high-risk in build pipelines

Postinstall hooks execute after installation and are attractive to attackers because they run with the same privileges and environment context as the build. That gives malicious packages a chance to inspect the host, read injected secrets, or stage exfiltration before defenders see the artifact. In supply-chain attacks, the hook is often the bridge between delivery and data theft. Once a pipeline allows automatic execution during dependency installation, the package no longer needs a separate exploit. It only needs to behave as a plausible build-time helper while collecting credentials and system data in the background.

Practical implication: Disable or tightly control postinstall execution in build jobs that handle secrets or publish artifacts.

How rotating publisher accounts sustain a supply-chain campaign

Account rotation gives a campaign resilience against takedown and reputation-based blocking. If one publisher identity is suspended, the attacker can continue publishing under a different account while preserving the same naming patterns, tooling, or exfiltration flow. In this case, the rotating accounts also helped fragment detection across clusters that still fed into a shared exfiltration backbone. For defenders, that means publisher identity cannot be treated as a one-time verification step. Registry trust has to include ongoing monitoring of account reuse, naming drift, and package lineage across multiple identities and namespaces.

Practical implication: Monitor publisher churn and package lineage so takedowns do not miss the broader campaign infrastructure.

Threat narrative

Attacker objective: The objective was to harvest high-value developer, cloud, and publishing credentials that could extend access into trusted software supply chains and downstream infrastructure.

1. Entry occurred when malicious NPM packages with internal-looking names were published to a public registry and resolved by CI/CD pipelines through dependency confusion.
2. Credential access followed postinstall execution, which let the packages inspect the environment and collect tokens, cloud credentials, SSH material, and database secrets.
3. Impact was credential theft and exfiltration across developer and build environments, with the campaign designed to reach trusted publish and cloud paths.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build pipelines are now identity enforcement points, not passive delivery systems. When dependency resolution can execute code and expose secrets, the package manager is effectively acting as an access broker. That means IAM and NHI governance have to extend into build trust, registry provenance, and publisher lifecycle control. Practitioners should stop treating CI/CD as outside the identity plane.

Dependency confusion is really a governance failure in source trust. The attack works because naming conventions, registry priority, and install defaults are trusted more than publisher assurance. In practice, that makes internal package namespaces a security boundary that needs explicit ownership, allowlisting, and monitoring. The practitioner conclusion is simple: package naming alone is not a control.

Build-time secret exposure gap: the breach pattern shows how temporary installation context can still leak durable credentials. If secrets are injected into build jobs, a malicious package only needs one execution window to collect them, so the control failure is secret scope and placement, not just code quality. Teams should govern where secrets ever appear during dependency installation.

Rotating publisher identities make registry trust a continuing control problem. The campaign's account churn shows that one-off verification does not address publisher persistence, especially when the same naming logic can be re-used across fresh accounts. That creates a need for publisher lineage, anomaly detection, and offboarding logic that treats package authorship as a governed identity lifecycle. The practitioner implication is that registry trust must be continuously revalidated.

Supply-chain compromise now reaches the identity boundary of engineering toolchains. Once a malicious package can steal NPM tokens, cloud keys, or database credentials, the boundary between software supply chain and identity security disappears. That is why this kind of attack belongs in the same governance conversation as secrets management and machine identity control. The field needs to treat package execution as privileged runtime behavior, not ordinary installation.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Build-time identity control is now part of supply-chain security. When a dependency installer can execute code, the security question is no longer only whether the package is legitimate. It is whether the build environment can be trusted to receive that package without exposing credentials, and that pushes identity governance into the delivery pipeline.

Dependency confusion creates a verification trust gap. Reserved internal names are meaningless if registry resolution still prefers public packages or if postinstall execution can reach secrets before policy enforcement. The practical signal for readers is that source trust, secret scope, and publisher lifecycle now need to be governed together.

Namespaced package trust is becoming a control surface. The same naming patterns that help developers organize code can also let attackers impersonate internal tooling. Teams should expect more attacks that combine registry abuse, build automation, and credential theft, and they should adapt their identity controls accordingly.

For practitioners

• Lock internal package resolution to approved registries Prevent dependency confusion by ensuring internal package names can only resolve from trusted private sources, and reject public lookups for reserved namespaces.
• Disable automatic install-time execution where secrets are present Review postinstall and similar hooks in build jobs, especially where environment variables, cloud credentials, or publish tokens are injected.
• Reduce secret exposure inside build environments Move high-value credentials out of routine dependency-install contexts so a malicious package cannot read publish tokens, cloud keys, or database secrets during normal installation.
• Track publisher identity churn and package lineage Alert on new or rotating publisher accounts, reused naming patterns, and clusters of related packages that appear across multiple registries or namespaces.
• Treat publish credentials as high-risk NHI assets Scope NPM tokens and similar secrets to the minimum necessary actions, and revoke them when an account, pipeline, or package set no longer needs them.

Key takeaways

• Dependency confusion in build systems is now an identity and secrets issue, because package resolution can become an execution and credential-access path.
• The campaign shows how rotating publisher accounts and postinstall execution can turn ordinary npm installs into credential theft across CI/CD environments.
• Defending against this pattern requires governing registry trust, build-time secret exposure, and publisher identity as one control problem.

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.
• Publisher identity: The account, token, or signing authority that allows software to be uploaded to a marketplace or package registry. In supply chain attacks, publisher identity is a privileged non-human identity, because compromise of that credential can turn a legitimate distribution channel into an attack path.
• Build-Time Secret Exposure: Build-time secret exposure is the accidental or unauthorized inclusion of sensitive credentials during software compilation, packaging, or image creation. It occurs when API keys, tokens, certificates, passwords, or private keys are embedded in source code, environment files, build logs, or artifacts, creating persistent compromise risk across development and deployment pipelines.

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 designed for practitioners who need to connect identity controls to the delivery pipelines and cloud systems their programmes depend on.