Dependency confusion and typosquatting

Dependency confusion: highest version wins, across a shared namespace

When a package manager resolves a name, it asks a registry for the versions available and, by default, prefers the highest one that satisfies the range. The trap is that “the registry” is often plural: many setups treat the public registry (npm, PyPI) as a fallback in the same namespace as your private one. So if your internal package acme-internal-utils exists privately at 1.4.0, and an attacker publishes a public package with the identical name at 99.0.0, the resolver compares them in one namespace and picks the higher version — the attacker’s.

The attacker’s only prerequisite is your internal name. Those names leak constantly: a package.json committed to a public repo, a dependency tree printed in a CI log, a path in a stack trace pasted into an issue. None of that is secret, and none of it feels like a vulnerability — until it becomes the seed of an attack.

# What the resolver effectively does for an UNSCOPED internal name:
#   query private registry  -> acme-internal-utils@1.4.0   (yours)
#   query public  registry  -> acme-internal-utils@99.0.0  (attacker's, higher)
#   "highest version wins"  -> installs 99.0.0 from public
# The install/postinstall script then runs with the CI job's secrets and network.

The payload runs because package managers execute lifecycle scripts (postinstall, preinstall) during installation by design — that is how native modules build themselves. On a CI runner that means the attacker’s code executes with whatever the job holds: registry tokens, cloud credentials, the ability to reach internal hosts. The root cause is structural, not a bug: a single resolution namespace where the public registry is a silent fallback and highest version wins, while your internal names are not reserved publicly.

The fix that actually closes it: scope + registry pinning

The decisive defense is to make your internal names unresolvable from the public registry, so the comparison above never happens. You do that by putting internal packages under a scope (@acme/...) and pinning that scope to your private registry in .npmrc:

# .npmrc — the scope @acme NEVER falls through to the public registry
@acme:registry=https://registry.internal.acme.com
//registry.internal.acme.com/:_authToken=${INTERNAL_NPM_TOKEN}

Now a request for @acme/utils is routed only to the internal registry. The resolver does not even query the public registry for that scope, so there is no public @acme/utils@99.0.0 to win — the version-comparison trap is structurally removed. For legacy unscoped internal names, the equivalent is to ensure the resolver never falls through to public for them (a proxy that fails closed, or migrating them under a scope). Privacy of the registry is not the same as isolation of the namespace; only the pin gives you isolation.

Lockfiles, integrity, and install scripts: the layers under the pin

The pin closes the namespace; three more layers limit blast radius if anything slips through.

Commit the lockfile and install with npm ci, not npm install. npm install is allowed to resolve — it can pull a new higher version and rewrite the lockfile, which is exactly the behavior dependency confusion exploits. npm ci installs only what the lockfile pins, and verifies each artifact against the integrity hash (a subresource-integrity SHA recorded at lock time). If a registry serves a swapped artifact for the same version, the hash check fails and the install aborts.

# npm install: may resolve a higher version and REWRITE the lockfile (the attack window)
npm install

# npm ci: installs EXACTLY the locked versions, verifies each integrity hash, fails on mismatch
npm ci --ignore-scripts   # also refuse lifecycle scripts where the build allows it

Disable install scripts where you can (--ignore-scripts). A malicious package’s leverage is almost always its postinstall; if scripts don’t run, a swapped or confused package is inert code on disk rather than executing code. You re-enable scripts deliberately for the few dependencies that genuinely need to compile.

Typosquatting: the sibling attack on the same install step

Dependency confusion targets your names; typosquatting targets popular names. The attacker publishes packages a fat finger away from something well-known — expresss, lodahs, crossenv — and waits for a developer to mistype an install command or copy a typo from a blog. The squatted package then runs the same kind of malicious install script. The defense layers differently because there is no scope to pin: verify the exact name before installing, run installs through a private proxy registry (Artifactory, Verdaccio) that serves only vetted, allow-listed packages, scan dependencies with tooling (Socket, npm audit), and pin everything via the lockfile so a typo can’t silently enter a reproducible build.