Cross-Registry Name Collision

What Cross-Registry Name Collision Means

Cross-registry name collision happens when the same package or artifact name exists in more than one software ecosystem, registry, or distribution channel. The overlap can make an imposter look familiar, even when it is unrelated to the trusted package a developer intended to use.

This is not just a naming oddity. The collision can distort human judgment, confuse automated dependency resolution, and steer bootstrap scripts or build systems toward the wrong source. In practice, the danger is often less about the name itself and more about misplaced trust in where that name came from.

Why It Creates Security Confusion

Package ecosystems are often treated as if names are globally meaningful, but they usually are not. A name that is legitimate in one registry may be reused, mirrored, forked, or impersonated in another, and the surrounding context may not make the difference obvious.

That confusion can lead developers to accept an artifact because it "looks right" at a glance. The problem is especially sharp when automation selects packages non-interactively, because the resolver, installer, or pipeline may not have the same contextual checks a careful human would use.

Where The Failure Usually Happens

Cross-registry collision is most dangerous at the point of acquisition: dependency installation, build-time fetches, container image assembly, and scripted bootstrap flows. A workflow that assumes a familiar name implies a familiar provenance is vulnerable to the wrong artifact being pulled into the software supply chain.

The failure can also appear in generated code and templated infrastructure, where a tool may emit a package reference based on a known name without validating the registry boundary. NIST SP 800-190 Container Security is a useful reference point because registry trust, image content, and acquisition path all matter once packages are assembled into containers.

How To Interpret It In Practice

The safest way to think about cross-registry name collision is as a provenance problem, not a syntax problem. The name may be valid, but the source, signing chain, ownership, and expected ecosystem all need to align before the artifact should be trusted.

That is why package ecosystem boundaries matter during review, not only during incident response. OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the broader principle that software trust depends on controlling what is allowed to authenticate, install, and execute. NIST SP 800-190 Container Security also provides a relevant lens for image and registry trust boundaries in build pipelines.

Risk and Threat Considerations

Cross-registry name collision creates a realistic supply-chain exposure because attackers can exploit naming familiarity to redirect downloads or seed lookalike artifacts into automated workflows. The risk is highest when teams rely on package names without enforcing registry allowlists, integrity checks, or source verification.

Failure mechanism: A developer, bot, or build script resolves a familiar package name from the wrong registry and imports an untrusted artifact that was never meant to represent the original software.

Impact: The wrong package can introduce malicious code, broken dependencies, credential theft, or subtle build compromise that persists into downstream releases and deployed systems.

Practitioner Guidance

Why practitioners should care: The main control question is whether your tooling treats package name as enough evidence of legitimacy. It should not. Registry source, namespace, checksum, signature, and expected publishing path all need to be part of the trust decision, especially in CI/CD and bootstrap automation.

Practitioner takeaway: Name collisions are inevitable across ecosystems, but accidental trust in a familiar name is not. Treat registry boundary validation as part of software intake, not as an optional hardening step.

Related resources from NHI Mgmt Group

• Service Principal Name Collision
• User Principal Name Collision
• Cross-Registry Worm
• WPAD Name Collision Vulnerability