---
title: "Dependency Confusion"
description: "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."
canonical_url: "https://fossa.com/glossary/dependency-confusion/"
markdown_url: "https://fossa.com/glossary/dependency-confusion.md"
content_type: "glossary"
language: "en"
date_published: "2023-06-25"
date_modified: "2023-06-25"
organization: "FOSSA"
---

# 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:
```json
// .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:
```xml
<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:
```xml
<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:

1. **Immediate Containment**
   - Disconnect affected build systems from the internet
   - Freeze all deployments and releases
   - Take snapshots of affected systems for forensic analysis

2. **Investigation**
   - Examine build logs to identify suspicious package installations
   - Analyze network traffic logs for unexpected connections
   - Inspect installed packages for malicious code

3. **Remediation**
   - Remove compromised packages from systems
   - Rebuild affected applications with verified dependencies
   - Scan for persistent backdoors or compromises

4. **Prevention**
   - Implement protective measures described above
   - Train developers on the risks and prevention techniques
   - Establish monitoring for future attempts

## Source

Canonical page: https://fossa.com/glossary/dependency-confusion/