Dependency Confusion

Dependency confusion (also called namespace confusion) exploits how package managers resolve packages when both public and private registries are configured.

The attack scenario:

1. Company uses an internal npm package: @company/utils (private, version 1.0.0)
2. Attacker discovers the internal package name (from job listings, error messages, leaked configs)
3. Attacker publishes @company/utils to the public npm registry at version 9.0.0
4. When developers run npm install, npm checks the public registry first
5. Version 9.0.0 > 1.0.0, so npm installs the ATTACKER'S version!

This vulnerability was demonstrated by Alex Birsan in 2021, who successfully compromised internal packages at Apple, Microsoft, PayPal, Tesla, and 30+ other companies.

Discovery methods:

• package.json files in public repos or CDN bundles
• Error messages revealing internal package names
• Job postings mentioning internal tool names

Prevent dependency confusion with explicit registry configuration and namespace isolation.

Pin internal packages to private registry (.npmrc):

# .npmrc — committed to repository
@company:registry=https://npm.company.internal/
# Only @company-scoped packages use internal registry
# Unscoped packages still resolve from public npm

# Or scope all packages to internal registry:
registry=https://npm.company.internal/
# (only if all packages are on internal registry)

Reserve package names on public registries:

# Publish a stub package to npm to reserve the namespace
npm publish --access public @company/utils
# Package has no code — just prevents takeover
# Set version to 9999.0.0 to always win version comparison

Subresource Integrity for direct script imports:

// package.json — use exact version pinning for internal packages
{
  "dependencies": {
    "@company/utils": "1.0.0"  // Exact version, not ^1.0.0
  }
}

Defense checklist:

• Configure .npmrc to use private registry for all internal scopes
• Reserve internal package names on public registries
• Use scoped packages (@company/...) for all internal packages
• Pin exact versions for internal packages
• Monitor public registries for packages matching internal names