DEPENDENCY CONFUSION CHECK · RUNS IN YOUR BROWSER

Could a public package be substituted for your internal one?

In 2021, researcher Alex Birsan got code execution inside Apple, Microsoft, PayPal, Netflix, Uber, and Tesla by publishing decoy packages under their internal package names on the public npm and PyPI registries. Two configuration shapes made every one of those incidents possible: pip --extra-index-url, which lets a public index outbid your private one on version number, and an unscoped npm dependency name, which falls back to the public registry the moment your private .npmrc is not in effect. Paste your config below and find both, each with the exact fix.

Nothing is uploaded. What you paste is read in this browser and never leaves your device, and this tool makes no network calls of its own — it never queries npm or PyPI on your behalf.

1. Paste your config

Any of the four boxes can be left empty — the check only runs on what you provide.

Paste at least one file above and click Check.

Prefer a CLI, or want this in your own CI?

Same logic, zero dependencies, one file:

python3 check.py                  # scan a repository checkout
python3 check.py /path/to/repo    # scan a specific checkout
python3 check.py --format json    # machine-readable
python3 check.py --fail-on-risk   # exit 2 if any finding exists

Get check.py from the repo — stdlib only, nothing to install, no network calls. Wire --fail-on-risk into your own CI to block a newly-added finding before it merges.

Already running a registry-aware supply-chain platform like Socket? See how this checker differs — different layers, worth running both.

Been grepping your own requirements.txt and package.json for these patterns by hand? See what a manual check structurally can't catch.

Common questions

What is dependency confusion?

In 2021, researcher Alex Birsan demonstrated that many companies' internal build tooling would install a same-named public package instead of their own internal one, and got code execution inside Apple, Microsoft, PayPal, Netflix, Uber, Tesla and others by publishing decoy packages under their internal package names on the public npm and PyPI registries.

How does pip --extra-index-url cause this?

pip's own documentation names this as a risk: the additional repository named by --extra-index-url can specify a version of a package that gets installed instead of the one from --index-url, because pip compares versions across every configured index and installs whichever reports the higher number for a given name. A public package published under your internal package's name, at a higher version, wins.

How does an unscoped npm name cause this?

When a repository's .npmrc sets a bare registry= to a private host, that value is the default for every unscoped dependency, public or internal. A machine or CI runner without that .npmrc in effect resolves the same unscoped name against the public npm registry instead — and if nobody has claimed it there, an attacker can.

Does this tool check whether a name is actually claimed on the public registry?

No. It makes no network calls at all. It flags every unscoped dependency once a private registry is configured, including ones that are already legitimately public — a dependency on left-pad looks identical, from a read-only view of package.json, to an internal package of the same shape. Read each flagged name yourself and judge which ones you actually intend to keep private.

Does a clean scan mean I am not exposed to dependency confusion?

No. This checks two specific, well-documented configuration patterns. It is not a security audit and makes no claim about your overall supply-chain exposure. It does not parse Pipfile, poetry.lock, pnpm-lock.yaml, or yarn.lock, and it does not recurse into a monorepo's per-package manifests.

More: what is dependency confusion?