Dependency confusion

A build installs an attacker's public package because it has the same name as your intended private dependency and wins resolution.

“npm installed the public package instead of ours”“someone copied our private package name”“wrong package came from the public registry”“internal dependency got replaced”“malicious package with our company package name”“private package registry mix-up”“the build pulled a package we never published”“dependancy confusion”“package namespace collision”

See it

Live demo coming soon

What it is

Dependency confusion happens when a build asks for an internal package name but the resolver is also allowed to search a public registry. An attacker publishes that name publicly, often with a version the resolver prefers, and the build installs hostile code instead of the private package. Alex Birsan's 2021 research made the attack widely known: publishing packages named after internal ones got his code running inside Apple, Microsoft, PayPal, Shopify, Netflix, Tesla and dozens more, and earned over $130,000 in bounties.

Check for it when private and public dependencies share npm, PyPI, NuGet, or similar tooling. Use a reserved namespace such as an npm scope, map that namespace to one authenticated internal registry, keep the lockfile, and make CI fail closed when the private registry is unavailable.

The gotcha is assuming a private registry URL in one developer's config protects every build. Dockerfiles, CI runners, and publishing jobs may carry different registry settings, and fallback behavior is the hole. Test from a clean runner, inspect the resolved source as well as the version, and never send private package names to a public registry as a discovery check.

Ask AI for it

Audit this repository for dependency confusion across npm, PyPI, and NuGet configuration. Inventory every private package name and every registry declared in lockfiles, .npmrc, pip.conf, nuget.config, Dockerfiles, and CI. For npm, move internal packages under the '@company' scope and map '@company:registry' to the authenticated internal registry in project and CI config. Enforce npm ci with the committed lockfile, disable public fallback for the private scope, and make authentication or registry failure stop the build. Add a clean-runner test that asserts each internal package's resolved URL belongs to the approved registry, and report collisions without querying public registries for confidential package names.

You might have meant

supply chain attacktyposquattingdependency vulnerability scanningsbomsecrets management