npm Dependency Confusion

How npm dependency confusion works

npm dependency confusion exploits package-name collision. An attacker publishes a public package that matches a private internal name, then waits for build tools or installers to resolve the malicious version instead of the intended internal package.

The attack is dangerous because package resolution often happens automatically inside CI/CD, build agents, and developer tooling. If those environments trust the wrong registry or do not pin sources tightly, the first successful install can silently turn a benign dependency lookup into code execution.

Why it is so effective in software supply chains

Dependency confusion works best where internal naming is predictable and package source controls are inconsistent. The attacker does not need to break into the private registry first, only to create a public package that looks more available to the resolver than the internal one.

That makes the technique attractive in modern delivery pipelines, where dependencies may be fetched during build, test, packaging, or even postinstall stages. Once the malicious package runs, it can tamper with artifacts, steal tokens, or expose secrets that were meant to stay inside the build boundary.

Real-world npm compromises show the same pattern in different forms, including stolen publishing access, poisoned dependencies, and secret theft from developer and CI environments, as seen in Shai Hulud npm malware campaign and Nx s1ngularity attack 2025.

How organisations should assess exposure

Exposure starts with knowing which internal package names exist, which registries each build path can reach, and whether any workflow can fall back to the public npm registry without a hard allowlist. Without that inventory, organisations often discover confusion risk only after a malicious publish has already been pulled into a build.

Reviewing package manager settings, lockfiles, proxy rules, and CI runner network egress is essential. Organisations should also inspect whether build systems, scripting hooks, or developer laptops hold credentials that a poisoned package could read, because the impact often extends beyond the package itself to the identity material used in the pipeline.

For a deeper view of how package compromise turns into credential theft and pipeline exposure, see eslint-scope npm compromise 2018 and Lottie Player npm compromise 2024.

Mitigation, detection, and recovery after exploitation

The strongest defence is to remove ambiguity in dependency resolution: keep private namespaces hard to guess, prefer explicit registry routing, and prevent fallback to public sources for internal packages. Where patching the package ecosystem is not enough, build-time compensating controls should assume malicious code can run during install.

Detection should focus on unusual outbound connections, unexpected postinstall activity, new package publish events, credential use that appears shortly after a dependency change, and secret access from build contexts that should not need it. After a suspected event, teams should review logs for package installs, rotation events, and any signs that tokens, keys, or repository access were exposed.

When package compromise is confirmed, rotate affected credentials and sessions, invalidate publishing tokens, and review downstream artifacts built from the poisoned dependency. The incident is not over when the package is removed, because harvested secrets or cached build outputs can remain exploitable.

Further examples of poisoned npm packages stealing secrets and abusing build trust are documented in Mastra npm Supply Chain Attack, Sapphire Sleet and Bitwarden CLI npm compromise 2026.

Risk and Threat Considerations

Dependency confusion is dangerous because it weaponises normal package retrieval. The attacker’s goal is not just to get code downloaded, but to place malicious code inside trusted build and delivery paths where it can steal secrets, alter outputs, or create a foothold for later compromise.

Failure mechanism: A resolver accepts a public package name collision, the malicious package executes during install or build, and the attacker gains access to secrets, signing material, or pipeline credentials.

Impact: The result can be source tampering, artifact poisoning, credential theft, and downstream compromise of other systems that trust the build pipeline or its outputs.

Practitioner Guidance

Why practitioners should care: Dependency confusion is not only a package hygiene problem, it is a trust-boundary problem. Treat internal package names, registry selection, and build-time execution as part of the same security control surface.

Common misunderstanding: Many teams assume that using a private package name is enough. In practice, the package name must be paired with source enforcement, install-time hardening, and secret containment, or the public registry can still become the attack path.

Practitioner takeaway: If a build can fetch packages without a strict registry policy, it can also be tricked into trusting an attacker-controlled one.

Related resources from NHI Mgmt Group

• What breaks when a malicious npm dependency is removed but the host still shows signs of persistence?
• What breaks when dependency confusion is allowed in CI/CD pipelines?
• How do security teams know if npm dependency controls are actually working?
• Why do package hallucinations and dependency confusion increase supply chain risk?