Dependency confusion attacks exploit a fundamental design assumption in package managers: when a package name exists in both a private registry and a public registry, the package manager may prefer the public version if it has a higher version number. This research documents a real-world campaign we investigated that targeted multiple enterprise organizations through the npm ecosystem.
The Attack Vector
The attackers harvested internal package names through multiple reconnaissance techniques: analyzing JavaScript source maps exposed on production websites, scraping error messages that leaked internal module paths, and monitoring npm audit logs for namespace patterns. Armed with a list of internal package names, they published public npm packages with identical names but inflated version numbers.
When developer machines or CI/CD systems ran npm install, the package manager resolved the dependency to the malicious public package instead of the legitimate internal one. The malicious packages contained install scripts that exfiltrated environment variables, SSH keys, and cloud credentials to attacker-controlled infrastructure.
Scope Assessment Framework
We developed a four-step framework for assessing organizational exposure to dependency confusion: (1) Inventory all private package names across internal registries, (2) Scan public registries for name collisions, (3) Audit package manager configurations across all repositories and CI/CD pipelines, and (4) Monitor for new public packages matching internal naming patterns.
Remediation Playbook
Prevention requires configuring npm to use scoped packages (@company/package-name) for all internal packages, setting explicit registry mappings in .npmrc files, and implementing package provenance verification. We also recommend deploying a dependency firewall that blocks unexpected packages from entering the build pipeline. Strobes integrates with popular SCA tools to provide continuous monitoring for dependency confusion vulnerabilities across your software supply chain.