Dependency Confusion (2021): How Public Package Registries Enabled Internal-Name Hijacking

Summary

In February 2021, security researcher Alex Birsan published research describing "dependency confusion," a technique that successfully executed code inside the networks of more than 35 major companies, including Apple, Microsoft, PayPal, Shopify, Netflix, Uber, and Yelp, through a novel supply chain technique, earning over $130,000 in bug bounties.

Technical Root Cause

Many organizations use internally-named packages (e.g. an internal npm or Python package called companyname-internal-utils) resolved through a private package registry. Birsan found that if an identically-named package was published to the public npm or PyPI registry with a higher version number, many build tools and package managers would fetch the public package instead of the intended internal one, because the tooling was configured (or defaulted) to prefer the higher version regardless of registry source. This maps to CWE-427 (Uncontrolled Search Path Element) in spirit, an ambiguous resolution path that an attacker can win by publishing to a namespace the victim doesn't control.

Why It Worked

Package names for internal tools were discoverable through leaked internal package.json/requirements.txt files (accidentally committed to public repositories), job postings, or public error messages, giving the researcher enough internal package names to squat on the public registries and wait.

OWASP / CWE Mapping

• CWE-427: Uncontrolled Search Path Element
• OWASP A08:2021: Software and Data Integrity Failures (build process trusting an unverified source)
• OWASP A06:2021: Vulnerable and Outdated Components (dependency resolution risk more broadly)

Lasting Impact

This research directly changed default behavior and best practice guidance across npm, pip, and other package managers: scoped packages, registry pinning, and explicit internal-registry-only configuration became standard recommended mitigations. It remains one of the clearest illustrations that a supply chain risk doesn't require any vulnerability in the dependency's code at all, only ambiguity in how it's resolved.

How Safeguard Helps

Safeguard's SBOM and dependency analysis can flag packages resolving from unexpected or public sources when an internal equivalent is expected, and supply chain risk monitoring extends to registry configuration risk, not just known-CVE matching.

References

• Alex Birsan's original writeup: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
• CWE-427: https://cwe.mitre.org/data/definitions/427.html