flawopen.com/Reference/Dependency Confusion

Dependency Confusion & Namespace Hijacking

High Severity CWE-1395 Supply Chain & Runtime

ELI5 — The Fake Brand in the Public Supermarket

Imagine your family bakery has an internal secret recipe called 'GrandmaSpecialFlour'. You usually buy it from your own basement storage. But one day, someone registers 'GrandmaSpecialFlour' at the local supermarket with version number 99.0. When your delivery boy goes shopping and asks for the highest version, the supermarket sells him the poisoned bag from the public store instead of looking in your basement. In Dependency Confusion, package managers (npm, pip) download higher-versioned malicious packages from public registries instead of your private company repository.

Target: npm, PyPI, RubyGems, internal enterprise package builds

Vector: Registering internal package names on public registries with high semantic versions

Impact: Arbitrary command execution during package installation via preinstall hooks

Remediation: Scoped namespaces (@company/package), reservation of internal names on public registries

The Mechanism & Root Cause

Package managers like npm and pip check both public registries (npmjs.com, PyPI) and private enterprise registries (Artifactory, Nexus). If an organization uses an unscoped internal package name (e.g. corp-auth-utils), an attacker registers the identical name on the public index with a version like 99.0.0. The build tool chooses the higher public version, executing malicious install lifecycle scripts.

package.json (Vulnerable Unscoped)Vulnerable

// VULNERABLE: Unscoped package name defaults to public npm search
{
  "name": "enterprise-web-app",
  "dependencies": {
    "react": "^18.2.0",
    "corp-billing-engine": "^1.2.0" 
    // Attacker registers 'corp-billing-engine' @ 99.0.0 on public npmjs.org!
    // npm install will pull the attacker's public package over the internal one.
  }
}

package.json & .npmrc (Hardened Scoped)Hardened

// HARDENED: Enforce organization scope tied strictly to private registry
// package.json:
{
  "name": "enterprise-web-app",
  "dependencies": {
    "react": "^18.2.0",
    "@corp/billing-engine": "^1.2.0" // Scoped package
  }
}

// .npmrc:
// @corp:registry=https://nexus.corp.internal/repository/npm-private/
// //nexus.corp.internal/:_authToken=${NPM_TOKEN}

The Attack & Exploit Sequence

1Attacker analyzes public client-side bundle source maps and identifies private internal package names like analytics-logger-internal.:
2Attacker registers analytics-logger-internal on npmjs.com with version 99.9.9.:
3The attacker adds a preinstall script to package.json that reads /etc/environment and sends secrets to a webhook.:
4Next time the target's CI/CD pipeline runs npm install, npm downloads the public package, executing the exfiltration script as root in the build agent.:

Defensive Engineering & Prevention Rules

✓Enforce Organization Scopes Everywhere: Always prefix internal packages with your enterprise scope (e.g. @company/) and route that scope exclusively to your internal registry.
✓Preemptively Register Internal Names on Public Registries: Claim placeholder stub packages on public registries (npm, PyPI) for all existing internal package names to block squatting.
✓Commit and Verify Exact Lockfiles: Always run npm ci rather than npm install to enforce strict SHA-512 integrity hashes from package-lock.json.
✓Disable Post-Install Execution Hooks: Run dependency installs with --ignore-scripts in untrusted or production build environments.

Explore related security topics and post-mortems: Complete Security Directory →