> For the complete documentation index, see [llms.txt](https://riteshs4hu.gitbook.io/infosec-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riteshs4hu.gitbook.io/infosec-notes/web-appsec/dependency-confusion.md).

# Dependency Confusion

Dependency Confusion is a software supply chain vulnerability that occurs when a build system, package manager, or development environment downloads a package from a public repository instead of the intended private repository.

Many organizations use private packages internally. If the package manager is configured to search both private and public repositories, an attacker may publish a package with the same name to a public repository. The package manager may then install the attacker's package instead of the legitimate internal package.

This vulnerability affects package ecosystems such as:

* NPM (Node.js)
* PyPI (Python)
* Composer (PHP)
* NuGet (.NET)
* RubyGems (Ruby)

***

### Vulnerable Code

Consider a Composer configuration that depends on an internal package:

```json
{
    "require": {
        "company/internal-auth": "^1.0"
    }
}
```

The development team expects `company/internal-auth` to be retrieved from a private repository.

If repository priorities are not properly configured and a package with the same name exists in a public repository, Composer may resolve the dependency incorrectly.

***

### Code Explanation

The application depends on an internal package:

```json
{
    "require": {
        "company/internal-auth": "^1.0"
    }
}
```

During dependency installation, Composer searches configured repositories for the requested package.

If the package manager cannot clearly distinguish between trusted private packages and public packages, it may install an unintended package.

The vulnerability is not caused by PHP code itself but by insecure dependency management and repository configuration.

***

### How to Exploit

1. Identify package names used internally by an organisation.
2. Determine whether those package names are available in public package repositories.
3. Publish a package using the same name in a public repository.
4. Wait for a developer, CI/CD pipeline, or build system to resolve dependencies.
5. If repository prioritisation is misconfigured, the package manager may download the public package instead of the intended private package.
6. The malicious package is incorporated into the application's build process.
7. Any code contained within the package may execute during installation, testing, deployment, or runtime depending on the package ecosystem and configuration.

The success of the attack depends on repository configuration, package naming practices, and dependency resolution behaviour.