Package name collision occurs when two different software packages share the same identifier across registries or indexes. That creates ambiguity in automated installs and can let a malicious package outrank the legitimate one. Security teams reduce the risk by controlling indexes, pinning versions, and reserving critical names.
How package name collisions happen
Package name collision is a registry and packaging integrity problem, not just a naming quirk. It arises when two distinct packages present the same identifier, so tooling cannot reliably distinguish the legitimate package from a lookalike or replacement.
The collision may occur across one index, across multiple registries, or through dependency resolution that consults more than one source. The practical consequence is ambiguity, because automated install workflows usually trust the identifier first and inspect the package content later.
Why package name collisions matter for software supply chain security
A collision can turn ordinary package lookup into a trust decision. If an installer, dependency bot, or build pipeline resolves the wrong package name, the result can be malicious code execution, dependency poisoning, or a broken release process.
This is why supply chain security guidance consistently emphasizes controlling package sources and validating what gets installed. Open source governance efforts such as OpenSSF focus on reducing the attack surface around package discovery, provenance, and dependency integrity.
In practice, the risk is amplified when organizations allow broad upstream access, mix internal and public indexes without policy, or rely on implicit resolution rules. A collision does not have to be rare to be dangerous, because a single successful substitution can affect many downstream builds.
Common ways collisions are abused or introduced
Attackers often look for naming gaps, abandoned identifiers, or inconsistencies between repositories. When a legitimate package name is expected but not strongly reserved or pinned, a malicious actor can publish a confusingly named package and exploit automation that prioritizes availability over verification.
Collisions also emerge accidentally through mirrored ecosystems, namespace differences, and migrations between package registries. Even when no attacker is present, inconsistent naming policies can still create operational failures if different teams resolve the “same” package to different content.
For a concrete example of this class of problem, the LiteLLM PyPI package breach shows how package-name abuse can intersect with supply chain compromise and user credential theft, turning a naming issue into a broader security incident.
Controls that reduce package name collision risk
The strongest defenses are preventive and policy-driven. Organizations should control which indexes are trusted, reserve critical package names where possible, pin versions for reproducible builds, and require review before a new package name is accepted into production paths.
Controls that improve provenance and build discipline also help because they make it harder for a collision to silently alter what gets deployed. Dependency allowlists, private registries, and release validation are especially effective when the same package names exist in more than one ecosystem or source.
Where package resolution feeds automated deployment, the security goal is not merely to “use the right package”, but to make the resolution path deterministic and defensible.
Risk and Threat Considerations
Package name collisions create a realistic supply chain threat because attackers can exploit naming ambiguity to steer automated installs toward malicious code. The main exposure is not the duplicate name itself, but the trust that build tools place in that name during dependency resolution.
Failure mechanism: A malicious package outranks or intercepts the intended package through registry precedence, typo-like similarity, weak reservation, or uncontrolled source selection.
Impact: The result can be dependency poisoning, unauthorized code execution in build or runtime environments, credential theft, or downstream compromise of every system that consumes the package.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | Package source trust depends on third-party registry and ecosystem risk. |
| Recommendation — Restrict approved package sources and review third-party package providers before allowing them in builds. | ||
| NIST CSF 2.0 | PR.DS-8 — Integrity, Authenticity and Provenance | Package collisions undermine software provenance and integrity of installed artifacts. |
| Recommendation — Verify package provenance and integrity before deployment. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Package-name collisions are a software supply chain integrity problem addressed by artifact provenance controls. |
| Recommendation — Adopt stronger provenance and build integrity requirements for all released artifacts. | ||
Practitioner Guidance
Why practitioners should care: Package-name controls are part of software trust, not just developer convenience. Teams that treat package discovery as a benign lookup step often miss the point where supply chain compromise begins.
What to watch for: Review any workflow that installs from multiple registries, accepts unpinned dependencies, or auto-upgrades packages without a provenance check. Those are the environments where collisions are most likely to become security events.
Practitioner takeaway: Make package resolution deterministic, restrict trusted sources, and treat critical names as security-sensitive assets.
Related resources from NHI Mgmt Group
- Should organisations allow package execution based on name similarity alone?
- Who is accountable when a public package hijacks an internal dependency name?
- What should organisations do when they find a hallucinated package name in an agent skill or automation script?
- Why do package name traversal bugs in pnpm create risk even when teams use –ignore-scripts?
