Dependency confusion is an attack where a build installs a public package instead of an internal one with the same name. The attacker publishes a package to a public registry using the name of your private package, often with a higher version number, and a misconfigured install picks it.
How it happens
Many companies keep private packages on an internal registry and use public ones for everything else. The package manager is configured to look in both places. If it prefers the highest version across both, and an attacker has published your internal name publicly with a bigger number, the public one wins.
The attacker needs your internal package names. They sometimes leak through manifests in public repositories, build logs, error messages or front-end bundles.
Why it works
- Internal names are often short and guessable.
- Public registries let anyone claim an unused name.
- Default resolution rules can treat sources equally.
- Install scripts run code on the machine that installs the package, which may be a build server with access to secrets.
How to prevent it
- Reserve your internal names. Publish placeholder packages on the public registry, or use a scoped namespace that you own.
- Configure resolution so internal names only come from the internal registry. Most package managers have a way to bind a name or scope to a source.
- Use a proxy registry that hosts internal packages and blocks public packages that shadow them.
- Commit lockfiles with integrity hashes, and install from them in CI.
- Avoid leaking names in public bundles and logs.
- Alert when a name you own appears on a public registry.
How it differs from typosquatting
Dependency confusion relies on an exact name match and a resolver mistake. Typosquatting relies on a human or tool making a small spelling mistake. The defenses overlap but are not identical.
For a worked example, read the anatomy of an npm dependency confusion attack.
Check your own setup
Pick one internal package and search the public registry for its name. If you find a package there that you did not publish, treat it as a finding and check your resolver settings that day.
Safeguard's dependency scanning and policies can flag packages that do not match expected sources. A free scan is at gold.safeguard.sh/scan.
Quick check
Does a lockfile fully prevent dependency confusion?
It helps for existing entries, because it fixes source and integrity. It does not protect the moment you add or update a package, so resolver configuration still matters.
Do scoped package names help?
Yes, if you own the scope on the public registry, since nobody else can publish under it.
Last reviewed: 19 October 2026.
