Dependency Confusion

The attack capitalizes on how package managers resolve dependencies. When a project references a private/internal package (e.g., @mycompany/tool), the attacker publishes a malicious package with the same name on a public registry (e.g., npm, PyPI). If the build system is configured to check public sources first, it will download and execute the attacker's code instead of the intended private package.

This attack is most effective against organizations that do not use scoped packages or registry namespaces (e.g., @org/package). Using unscoped package names (e.g., internal-utils) makes them globally available for squatting on public registries. Proper configuration of scoped registries and .npmrc or pip.conf files to prioritize private sources is a critical defense.

Attackers often use automated tools to scan for internal package names. They might:

• Parse public source code repositories for package.json or requirements.txt files.
• Examine leaked build logs or CI/CD configuration files.
• Use common naming conventions for private packages (e.g., companyname-*). This automation allows for large-scale, opportunistic attacks.

The malicious payload is executed during the install or build phase of the victim's development pipeline. Common payloads include:

• Post-install scripts that run automatically upon package installation.
• Malicious code bundled into the module itself, designed to exfiltrate secrets, source code, or environment variables.
• Persistence mechanisms that create backdoors within the build environment or deployed application.

The primary targets are automated systems, not end-users. Continuous Integration/Continuous Deployment (CI/CD) pipelines are ideal because they run fresh installs in a trusted environment, often with elevated permissions and access to sensitive credentials. Individual developers running npm install or pip install on their machines are also vulnerable if their environment is misconfigured.

Mitigation is entirely configuration-based. Essential practices include:

• Always using scoped package names for private dependencies.
• Configuring package managers to exclusively use the private registry for those scopes.
• Employing .npmrc, .yarnrc, or pip.conf files to enforce source priority.
• Implementing registry firewalls or upstream proxies that block public requests for internal package names.

The attack exploits how package managers (npm, PyPI, NuGet) resolve dependencies. When a project's configuration file (like package.json or requirements.txt) references a private package, the manager checks public registries first. An attacker publishes a higher-versioned, malicious package with the same name. The build system inadvertently downloads and executes the attacker's code, leading to remote code execution (RCE) or data exfiltration.

This attack succeeds under specific, common conditions:

• Mixed registry usage: Projects that pull some dependencies from public (npmjs.com) and some from private registries.
• Missing scope or namespace: Private packages not published under an organization scope (e.g., @company/package).
• Overly permissive resolution: Package managers configured without strict registry priority or allow-list rules.
• Internal package names that are not globally unique (e.g., utils, api-client).

In 2021, security researcher Alex Birsan demonstrated this attack against major tech firms (Apple, Microsoft, Tesla, Uber). By uploading benign but detectable packages to public registries, he proved the vulnerability was widespread. The impact is severe:

• Full build pipeline compromise: Attackers gain access to CI/CD secrets and source code.
• Downstream propagation: The malicious code is bundled into production applications.
• Pivoting to internal networks: The payload can establish a foothold behind corporate firewalls.

Defense requires locking down the dependency resolution process:

• Use scoped packages: Always publish private packages under an organization scope (e.g., @acme/core).
• Configure registry priority: Force package managers to check the private registry first (e.g., using .npmrc with @acme:registry).
• Employ allow-listing: Use tools like Sonatype Nexus or GitHub Packages to proxy public registries and block unwanted packages.
• Implement dependency pinning: Use lockfiles (package-lock.json, pipenv) and hash verification.
• Run internal registry mirrors for all dependencies.

• Typosquatting: Publishing malicious packages with names similar to popular ones (e.g., lodash vs lodashh).
• Brandjacking: Uploading packages that appear to be official SDKs or tools for a company.
• Software Bill of Materials (SBOM): A formal inventory of components used to track dependencies and identify vulnerabilities.
• CI/CD Security: Securing the continuous integration and deployment pipelines that are the primary target of these attacks.

Several tools help identify and prevent dependency confusion:

• OSS Index / Snyk: Scans project dependencies for known vulnerabilities and malicious packages.
• GitHub Dependabot / CodeQL: Monitors dependency manifests and alerts on suspicious changes or publicly known malicious packages.
• Renovate: Automated dependency updates that can be configured with strict registry rules.
• JFrog Xray: Scans artifacts and dependencies for security violations across development pipelines.
• Manual auditing tools: Like npm audit or pip-audit for post-installation checks.

The attack exploits the package manager's resolution order. Most tools (npm, pip, Maven) check public repositories before private ones. An attacker registers a package with the same name as a company's internal library. When a developer or CI/CD pipeline runs npm install or pip install, the system pulls the higher-versioned malicious package from the public registry instead of the trusted private one, introducing backdoors, data exfiltrators, or ransomware into the build.

This is not a theoretical risk. In 2021, security researcher Alex Birsan demonstrated the attack against Apple, Microsoft, Tesla, and Uber, successfully executing code on their internal systems by publishing benign test packages. The impact ranges from:

• Credential Theft: Stealing AWS keys or internal API tokens.
• Persistence: Establishing a foothold in development and production environments.
• Reputation Damage: Compromised software shipped to customers. These proofs-of-concept led to widespread security reassessments.

Organizations are vulnerable if they:

• Use internal private packages with generic names (e.g., @company/ui-components).
• Lack scope configuration in package managers (e.g., not using npm scopes @company/ correctly).
• Have insecure CI/CD pipelines that pull dependencies without explicit source locking.
• Rely on public registry fallbacks without authentication requirements for private dependencies. The risk is highest in organizations with large, complex codebases and automated build processes.

Effective defenses involve configuring package managers to prioritize internal sources:

• Use Scoped Packages: Adopt namespaced names (e.g., @yourcompany/pkg-name) which are globally unique.
• Configure Registry Precedence: Always set the private registry as the primary source in .npmrc, pip.conf, or pom.xml.
• Employ Authentication: Require credentials for private registry access; public registries should not have credentials.
• Implement Lockfiles: Use package-lock.json, pipenv, or yarn.lock to pin exact dependency versions and sources.
• Run Dependency Audits: Regularly scan for packages with names conflicting with internal ones.

Dependency confusion is a subset of broader software supply chain threats:

• Typosquatting: Malicious packages with names similar to popular ones (e.g., lodash vs lodash).
• Brandjacking: Publishing malicious packages under a reputable organization's name.
• Chain of Trust: The integrity model for verifying software from source to deployment, often enforced via code signing and SBOMs (Software Bill of Materials).
• CI/CD Compromise: Attacks targeting the build pipeline itself, which dependency confusion can facilitate.

The attack exploits the default behavior of package managers like npm, PyPI, and RubyGems. When a developer's build script references a private package (e.g., @mycompany/internal-tool), the package manager checks public repositories first. An attacker can publish a malicious package with the same name to the public registry, which is then downloaded and executed instead of the intended private package.

• Key Trigger: A build on a machine without prior installation of the private dependency.
• Objective: Achieve remote code execution (RCE) in the build environment or production deployment.

This is a closely related attack that targets developer error rather than build order.

• Typosquatting: Attackers publish packages with names similar to popular ones (e.g., lodash vs. lodashh).
• Namespace Confusion: In ecosystems like npm, attackers target unscoped packages that share a name with a scoped private package (e.g., public internal-tool vs. private @acme/internal-tool).

While dependency confusion exploits the resolution order, these attacks exploit human error in typing or referencing package names.

An SBOM is a formal, machine-readable inventory of all components and dependencies in a software artifact. It is a primary defense against dependency confusion and supply chain attacks.

• Provides Transparency: Lists all direct and transitive dependencies, including their origins (public or private).
• Enables Auditing: Allows automated tools to scan for known vulnerabilities, license violations, or unexpected packages from public sources.
• Critical for Compliance: Required by frameworks like the U.S. Executive Order on Improving the Nation's Cybersecurity.

Proper configuration of package managers is the first line of defense.

• Use Scoped Packages: Always publish private packages under an organization scope (e.g., @acme/).
• Configure Registry Priority: Explicitly set the private registry URL as the primary source and downgrade the public registry (e.g., using .npmrc with @acme:registry).
• Implement .npmrc or pip.conf: Ensure build servers and CI/CD pipelines have configuration files that point to the correct private registry first.

Secure the CI/CD pipeline to prevent malicious package execution.

• Pre-install Dependencies: Use a locked package-lock.json, yarn.lock, or Pipfile.lock and install from this lockfile in CI, never from a live registry.
• Use Private Proxy Registries: Deploy an artifact repository manager (e.g., JFrog Artifactory, Sonatype Nexus) as a proxy. It caches public packages and serves private ones, acting as a single, controlled source.
• Network Restrictions: Configure build environments to only have network access to the private registry, blocking direct access to public PyPI/npm.

The attack was famously demonstrated by security researcher Alex Birsan in 2021 against companies like Apple, Microsoft, and Tesla.

• Method: Birsan identified internal package names from public sources (like JavaScript files on company websites) and published benign test packages to public registries.
• Result: The packages were automatically downloaded by the companies' internal build systems, proving the vulnerability's prevalence.
• Aftermath: This research led to widespread adoption of mitigation strategies and increased scrutiny of software supply chain security.