Dependency Confusion Attack
What is Dependency Confusion Attack?
Dependency Confusion AttackA supply-chain attack in which an adversary publishes a malicious package on a public registry with the same name as an organization's internal dependency, tricking build tools into pulling the public version.
Dependency confusion exploits the default resolution behaviour of package managers (npm, pip, Maven, NuGet, RubyGems, and others) that combine public and private registries. An attacker discovers the name of an internal package (via leaked manifests, public repositories, or DNS), publishes a higher-version package with the same name on the public registry, and waits for build agents to install it. Alex Birsan's 2021 research showed dozens of major companies were vulnerable. Mitigations include explicit registry scoping (npm scoped packages, NuGet upstream feeds, pip --index-url), publishing internal placeholders on public registries, blocking outbound resolution, signing packages with Sigstore or PGP, and consuming through a curated artifact repository that pins both name and source. SLSA, SBOMs, and continuous monitoring of new public packages also help detect attempts.
● Examples
- 01
Internal package internal-utils replaced by a malicious internal-utils@99.0.0 on npm.
- 02
Build pipeline pulling pip dependency from PyPI instead of the private index.
● Frequently asked questions
What is Dependency Confusion Attack?
A supply-chain attack in which an adversary publishes a malicious package on a public registry with the same name as an organization's internal dependency, tricking build tools into pulling the public version. It belongs to the Application Security category of cybersecurity.
What does Dependency Confusion Attack mean?
A supply-chain attack in which an adversary publishes a malicious package on a public registry with the same name as an organization's internal dependency, tricking build tools into pulling the public version.
How does Dependency Confusion Attack work?
Dependency confusion exploits the default resolution behaviour of package managers (npm, pip, Maven, NuGet, RubyGems, and others) that combine public and private registries. An attacker discovers the name of an internal package (via leaked manifests, public repositories, or DNS), publishes a higher-version package with the same name on the public registry, and waits for build agents to install it. Alex Birsan's 2021 research showed dozens of major companies were vulnerable. Mitigations include explicit registry scoping (npm scoped packages, NuGet upstream feeds, pip --index-url), publishing internal placeholders on public registries, blocking outbound resolution, signing packages with Sigstore or PGP, and consuming through a curated artifact repository that pins both name and source. SLSA, SBOMs, and continuous monitoring of new public packages also help detect attempts.
How do you defend against Dependency Confusion Attack?
Defences for Dependency Confusion Attack typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Dependency Confusion Attack?
Common alternative names include: Substitution attack, Namespace confusion.
● Related terms
- appsec№ 1069
Software Supply Chain Security
The discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss.
- attacks№ 1116
Supply Chain Attack
An attack that compromises a trusted third-party software, hardware, or service provider in order to reach its downstream customers.
- attacks№ 1184
Typosquatting
Registering domain names or package names that are misspellings or visual look-alikes of legitimate ones, to catch users or developers who make typing or recognition errors.
- appsec№ 305
Dependency Pinning
The practice of declaring software dependencies at exact versions, often combined with cryptographic hashes, so that builds always consume the same artifacts and resist supply-chain tampering.
- appsec№ 971
SCA (Software Composition Analysis)
Automated analysis of an application's open-source and third-party components to identify known vulnerabilities, license issues and outdated or risky dependencies.
- appsec№ 784
Package Signing
Applying a cryptographic signature to a software package so that consumers can verify the publisher's identity and that the artifact has not been altered after release.
● See also
- № 1097Starjacking
- № 647Malicious npm Package
- № 1183Typosquatted Package