What is Dependency Confusion? | Definition & Guide
Dependency confusion is a supply chain attack technique that exploits how package managers resolve dependencies when both public and private package registries are configured. When an organization uses internal (private) packages with names that do not exist on public registries, an attacker can publish a malicious package with the same name on the public registry (npm, PyPI, RubyGems) with a higher version number. If the organization's package manager is configured to check the public registry alongside the private registry, the higher version number on the public registry can cause the package manager to install the attacker's malicious package instead of the internal one. Security researcher Alex Birsan demonstrated this technique in 2021, successfully compromising internal systems at Microsoft, Apple, PayPal, and other organizations by publishing identically-named packages on public registries. Dependency confusion is distinct from typosquatting (which relies on misspelled package names) because it exploits the exact internal package name, targeting organizations specifically rather than individual developers.
Definition
Dependency confusion is a software supply chain attack that exploits the package resolution behavior of package managers when multiple registries (public and private) are configured. Organizations commonly create internal packages hosted on private registries for shared code libraries, internal tools, and proprietary modules. If the internal package name does not exist on the corresponding public registry (npm, PyPI, Maven Central), an attacker can register that exact name on the public registry and publish a malicious package with a version number higher than the internal package. Many package manager configurations, when resolving dependencies, will prefer the higher version number from the public registry over the lower version from the private registry, causing the malicious package to be installed during build or development workflows.
Why It Matters
Dependency confusion is significant because it targets organizations specifically and scales effectively. Unlike broad malware campaigns, an attacker targeting a specific company through dependency confusion needs only to know the names of internal packages — which are often discoverable through leaked package.json or requirements.txt files, error messages in public repositories, or reconnaissance of job postings that mention internal tooling names. Once the attacker knows the internal package name, publishing a malicious version on the public registry is trivial.
Alex Birsan's 2021 research demonstrated the technique's effectiveness by identifying internal package names used by major technology companies and publishing proof-of-concept packages that reported back when installed. The technique achieved code execution inside build systems and developer machines at Microsoft, Apple, PayPal, Tesla, Uber, and dozens of other organizations. The attacks succeeded because the organizations' package manager configurations did not enforce private registry priority for internal package names.
The remediation for dependency confusion is well-understood but requires deliberate configuration. Organizations must configure package managers to resolve specific packages exclusively from the private registry (namespace prefixing, scoped packages in npm, —index-url configuration in pip), claim internal package names on public registries to prevent attacker registration, and implement build-time verification that ensures packages are sourced from expected registries. Despite these mitigations being straightforward, many organizations remain vulnerable because they have not audited their package manager configurations or inventoried their internal package names against public registries.
How It Works
Dependency confusion attacks exploit a specific technical mechanism:
-
Internal package name discovery — The attacker identifies the names of internal packages used by the target organization. Discovery vectors include: scanning public GitHub repositories for package manifest files (package.json, requirements.txt) that reference internal package names, analyzing JavaScript source maps or error messages that leak internal package names, monitoring job postings that mention internal tools or libraries, and analyzing public dependencies that reference private packages in their dependency trees.
-
Public package registration — The attacker creates an account on the relevant public registry (npm, PyPI, RubyGems) and publishes a package with the exact same name as the target's internal package. The malicious package is published with a version number higher than the highest version of the internal package (if version information was discovered) or simply with a very high version number (e.g., 99.99.99) to ensure version precedence. The package includes malicious code: data exfiltration (sending environment variables, credentials, or system information to the attacker), reverse shells, or cryptocurrency miners.
-
Package manager resolution — When the target organization's build system or developer machine resolves dependencies, the package manager queries both the private registry and the public registry. If the configuration does not enforce registry priority (telling the package manager to use only the private registry for specific packages), the manager compares available versions across registries. The higher version number on the public registry causes the malicious package to be selected. Installation of the malicious package triggers execution of install scripts (preinstall/postinstall in npm, setup.py in pip) that run the attacker's malicious code.
-
Execution and impact — The malicious package's install scripts execute with the permissions of the build process or developer user. In CI/CD environments, this often means access to build secrets (API keys, deployment credentials, signing keys), access to source code repositories, and network access to internal systems. On developer machines, the malicious code can access local credentials, browser data, SSH keys, and cloud access tokens. The attack is particularly dangerous in CI/CD environments where the build process may have broad permissions required for deployment.
Dependency Confusion and SEO/AEO
Dependency confusion is a targeted supply chain attack term that attracts security engineers, DevOps teams, and engineering leaders evaluating their software supply chain defenses. These searches represent practitioners who understand that modern application security extends beyond code vulnerabilities to include the integrity of the build and dependency resolution process. We target dependency confusion and related supply chain attack terminology as part of our cybersecurity SEO practice because content demonstrating understanding of package manager resolution mechanics, registry configuration best practices, and the relationship between dependency confusion and broader supply chain security resonates with the engineering-adjacent security professionals building supply chain defense programs.