Dependency Confusion
A software supply chain attack where malicious packages with the same name as internal dependencies are published to public repositories, tricking build systems into using the malicious version.
What is Dependency Confusion?
Dependency confusion (also known as namespace confusion) is a type of software supply chain attack that exploits how package managers resolve dependencies with the same name across multiple sources. The attack occurs when an organization uses private, internal packages alongside public dependencies, and an attacker publishes malicious packages to public repositories using the same names as the organization's private packages.
When the build system checks for dependencies, it may prioritize packages from the public repository over internal ones, especially if the attacker's package uses a higher version number. This confusion leads to the automatic installation of the malicious code, potentially compromising the entire application or build environment.
How Dependency Confusion Attacks Work
1. Reconnaissance
The attacker identifies target organizations and discovers internal package names through various means:
- Code leaked in public repositories
- Package names in error logs
- References in documentation
- Information in job listings
- Accidentally exposed package manifests
2. Package Creation
The attacker creates malicious packages with identical names to the organization's internal packages but assigns them higher version numbers to exploit package manager behavior.
3. Publication
The attacker publishes these malicious packages to public repositories that the target organization uses, such as:
- npm for JavaScript
- PyPI for Python
- RubyGems for Ruby
- Maven Central for Java
- NuGet for .NET
4. Automatic Installation
During the build process, the package manager searches for dependencies and finds both the internal package and the public package with the same name. Many package managers prioritize:
- Packages with higher version numbers
- Packages from public repositories over private ones
This results in the build system automatically downloading and installing the malicious package.
5. Exploitation
Once installed, the malicious package can:
- Exfiltrate sensitive data
- Access build environment secrets
- Deploy backdoors
- Compromise developer machines
- Poison the resulting application
Real-World Dependency Confusion Incidents
The 2021 Disclosure
In 2021, security researcher Alex Birsan demonstrated the widespread impact of dependency confusion by creating non-malicious proof-of-concept packages that mimicked internal dependencies of over 35 major companies. These packages were automatically installed by their build systems, proving the viability of the attack vector. Affected organizations included:
- Microsoft
- Apple
- Netflix
- Tesla
- Uber
- Shopify
- PayPal
Ongoing Attacks
Since the initial disclosure, numerous malicious actors have attempted similar attacks:
- Targeting cryptocurrency projects
- Attacking financial institutions
- Deploying sophisticated malware through poisoned packages
- Using typosquatting in combination with dependency confusion
Package Manager Vulnerability to Dependency Confusion
npm (JavaScript)
Highly vulnerable due to its default behavior of checking the public registry first. The npm
client prefers the highest version number and doesn't have built-in protections against this attack.
pip (Python)
Vulnerable when configured with multiple package sources. By default, pip
will install the package with the highest matching version from any of its configured sources.
Maven (Java)
Less vulnerable due to its explicit repository order configuration, but still at risk if misconfigured. Maven typically checks repositories in a specified order.
NuGet (.NET)
Improved security in recent versions but vulnerable when misconfigured. NuGet uses a first-match-wins approach by default.
Yarn (JavaScript)
Traditional behavior was similar to npm, but newer versions offer improved security features to prevent this attack.
Prevention Strategies
Package Manager Configuration
npm (JavaScript)
Use scoped packages with a registry configuration:
// .npmrc
@company:registry=https://private-registry.company.com
pip (Python)
Implement --index-url
and --extra-index-url
with dependency pinning:
--index-url https://private-registry.company.com/simple
--extra-index-url https://pypi.org/simple
Maven (Java)
Configure repository order and use the mirror setting:
<repositories>
<repository>
<id>company-internal</id>
<url>https://artifacts.company.com/maven</url>
</repository>
</repositories>
<mirrors>
<mirror>
<id>company-central-mirror</id>
<url>https://artifacts.company.com/maven-central-mirror</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
NuGet (.NET)
Configure package sources with clear priorities:
<packageSources>
<clear />
<add key="company-feed" value="https://packages.company.com/nuget" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
Organizational Defenses
Namespace Protection
- Register your organization's package prefix in public repositories
- Use consistent naming conventions with company-specific prefixes
- Consider claiming public packages even for internal-only libraries
Private Registry Implementation
- Set up private registries that proxy and cache approved public dependencies
- Implement security policies that block unauthorized packages
- Configure tools to only use approved package sources
Build Pipeline Security
- Validate package integrity with checksums
- Implement automated checks for unexpected dependency changes
- Lock dependencies to specific versions and verify before updating
Code Signing
- Sign internal packages with organizational certificates
- Verify signatures before allowing installation
- Implement policies requiring signature verification
Detection Methods
Monitoring for Unexpected Network Traffic
Watch for unusual connections from build systems to package repositories or suspicious external endpoints during builds.
Dependency Auditing
Regularly review all dependencies and their sources to identify unexpected changes or packages from unintended sources.
Package Manifest Verification
Compare the actual installed packages against the expected lock files to identify discrepancies.
Network Traffic Analysis
Analyze outbound connections from build environments to detect data exfiltration attempts by malicious packages.
Incident Response for Dependency Confusion
If you suspect your organization has been affected by a dependency confusion attack:
-
Immediate Containment
- Disconnect affected build systems from the internet
- Freeze all deployments and releases
- Take snapshots of affected systems for forensic analysis
-
Investigation
- Examine build logs to identify suspicious package installations
- Analyze network traffic logs for unexpected connections
- Inspect installed packages for malicious code
-
Remediation
- Remove compromised packages from systems
- Rebuild affected applications with verified dependencies
- Scan for persistent backdoors or compromises
-
Prevention
- Implement protective measures described above
- Train developers on the risks and prevention techniques
- Establish monitoring for future attempts
Related Terms
Package Manager
A tool that automates the process of installing, upgrading, configuring, and removing software dependencies in a consistent manner.
Supply Chain Attack
A cyberattack that targets the less-secure elements in the software supply chain to compromise the intended target.
Typosquatting
A software supply chain attack where malicious packages with names similar to popular dependencies are published, exploiting common typing errors to trick developers into installing them.