Dependency Confusion

Dependency confusion (also called namespace confusion or a substitution attack) is a software supply chain attack in which the attacker publishes a package on a public registry under the same name as a company's private, internal package. When a build tool or developer machine is configured to check both internal and public sources, many resolvers prefer the public version — especially if it carries a higher version number — and quietly install the attacker's code instead of the company's own.

How it works

Internal package names leak constantly: in public repositories, in JavaScript bundles shipped to browsers, in job postings, in error messages, in CI logs. The attacker harvests those names, then publishes packages under them on npm, PyPI, RubyGems, or NuGet with inflated version numbers like 99.0.0. The next time a pipeline resolves dependencies without a strict source policy, "newest wins" logic pulls the public impostor. The researcher who demonstrated the technique in 2021 used it to run code inside dozens of major technology companies using nothing but harmless proof-of-concept packages — no phishing, no exploit, just a registry upload and patience.

Unlike typosquatting, which needs a human to make a mistake, dependency confusion exploits the build system's own rules. The developer typed the right name; the tooling fetched the wrong source. That is what makes it dangerous — and what makes it preventable with configuration rather than vigilance alone.

How to defend against it

• Pin the source, not just the version. Configure package managers to resolve internal names only from the internal registry — scoped packages (@yourcompany/...), repository-level source mappings, or a proxy that refuses public lookups for reserved namespaces.
• Reserve your names publicly. Register your internal package names (or your scope/prefix) on public registries so nobody else can.
• Use lockfiles and verify in CI. Lockfiles make resolution deterministic; alert on any dependency whose source registry changes between builds.
• Teach the pattern. Developers who know the trick spot the symptoms — an internal library suddenly at version 99, or a public package shadowing an internal name. Our guide to security awareness for developers covers where this fits in the wider attack surface aimed at engineering teams.