Dependency confusion: when a public package shadows a private one

What it is

An installer turns an abstract name (spam) into a concrete file from some repository. pip's documentation states that when several package locations are configured there is no priority among them: all are checked and the best version match is selected. PEP 708 describes the consequence: each repository is its own namespace, installers flatten them into one, and when the same name exists in two repositories from different authors a dependency confusion attack becomes possible. Its motivating example is PyTorch's torchtriton, meant to come only from the project's own index, whose name was unclaimed on PyPI and was published there by an attacker. pip's documentation warns that using --extra-index-url for packages that are not in the main repository is unsafe and names the attack. The same shape exists in other ecosystems wherever an internal name can be registered publicly.

Why it matters

The attack needs no access to your systems: a build agent, a developer laptop or a CI job with a permissive index configuration installs the attacker's package, whose install hooks run with the build's credentials. Internal names leak through manifests, error messages and public repositories, so obscurity is not a defence.

How to apply

• Bind namespaces to registries. In npm, associate a scope with a registry (npm config set @myco:registry=https://...); the documentation states that a scope points to exactly one registry and that installs and publishes for that scope go there. Publish internal packages only under such a scope.
• In Python, avoid --extra-index-url for private packages. Use a single --index-url pointing at a private index that proxies the public one and decides per name which upstream is allowed, so the installer sees one namespace.
• Claim your internal names on the public index with placeholder packages where the ecosystem permits it.
• Pin with hashes (pip install --require-hashes, lockfiles with integrity fields) so that a substituted artifact fails verification.
• Run builds with minimal credentials and restricted outbound network, so a malicious install hook has little to take.
• Audit installer configuration in CI images and developer setup scripts; the dangerous line is usually one someone added to make a private package install.

Pitfalls

PEP 708 proposed repository metadata ("tracks" and "alternate locations") so that installers could detect unsafe mixes automatically; it was rejected after three years in provisional acceptance because the required conditions were never met, so Python users must configure protection themselves. Version ordering is not a defence: the attacker picks the higher version. Mirrors that merge namespaces reintroduce the problem.