A developer runs `pip install reqeusts` (missing a letter) instead of `pip install requests`, and the install succeeds without any warning. What class of supply-chain attack does this expose, and what actually stops it from working in practice?

## What the attack is Typosquatting in the package-registry context is the same idea as URL typosquatting applied to `pip install`, `npm install`, or `go get`: an attacker registers a package name that is visually or typographically close to a popular, trusted package, betting that some fraction of developers will mistype the real name, copy a name wrong from a blog post or Stack Overflow answer, or misremember it. Because public registries like npm, PyPI, and RubyGems are open — anyone can claim any unclaimed name — there's no structural barrier to registering `reqeusts`, or a hyphen variant like `crossenv` (a typo of the legitimate `cross-env`), or `electorn` (`electron`) and publishing a package under it. The names are chosen specifically to be plausible: - **transposed letters** - **a missing or doubled character** - **hyphen-vs-no-hyphen variants** - **or a different but confusable scope** Once installed, the malicious package behaves like any other supply-chain compromise: it runs code at install time via lifecycle hooks — npm's `postinstall`, Python's `setup.py/pyproject.toml` build backends — which execute with the full privileges of whoever ran the install command, before the developer's actual application code ever runs. That means a single mistyped command on a laptop or, worse, in a CI job or Dockerfile, can immediately exfiltrate environment variables, cloud credentials, SSH keys, or npm/PyPI publish tokens, or install a cryptominer or backdoor. ## Why the ecosystem leaves the door open This attack exists for the same structural reason dependency confusion does: package ecosystems prioritize low-friction, ungated publishing to maximize growth, and that openness is inseparable from the risk that anyone — including an attacker — can claim any name that isn't already taken. The trade-off is stark: locking down who can publish or requiring name-similarity review would slow down the exact openness that makes these ecosystems useful, so the industry has instead layered on detection and process controls rather than closing the open-publishing model itself. ## Where the mistake happens The failure mode shows up differently depending on where the mistake happens. | Where the typo lands | What follows | |---|---| | A developer typo on a personal laptop while experimenting | It is bad but usually contained. | | A typo baked into a `requirements.txt`, `package.json`, or Dockerfile that gets committed and then installed by every CI run and every teammate's `npm install` | It turns one mistake into an organization-wide compromise, executed repeatedly and automatically with no human in the loop to notice something looks off — the mistyped name just sits there resolving 'successfully' every time. | This is what makes typosquatting dangerous in CI/CD specifically: automation doesn't second-guess a name the way a human occasionally might. ## Concrete, real incidents Concrete, real incidents illustrate the range of damage. - In 2017, an npm package called `crossenv` (typosquatting the legitimate `cross-env`) was found stealing environment variables — including npm publish credentials — from anyone who installed it by mistake. - On both npm and PyPI, packages near-missing extremely popular names like `electron`, `babel`, `urllib`, or `numpy` have repeatedly been caught doing the same pattern: harvest secrets or drop a cryptominer via `postinstall`, then get pulled down once reported. - Researchers have also documented large batches of typosquat packages uploaded in bulk by the same actor across dozens of near-miss names at once, indicating this is often done at scale with automation rather than one-off social engineering. ## Layered mitigations Mitigations are layered and mostly address the human-error entry point rather than the registry's openness itself. 1. **The most reliable technical control is routing installs through a private registry proxy** configured with an explicit allowlist of approved package names — if a name isn't on the list, the install simply fails closed rather than silently resolving to whatever public package happens to exist with that name, typo or not. 2. **Where an allowlist is impractical, copying exact package names from a trusted source** (the project's own lockfile, the official docs, or an internal package catalog) rather than hand-typing them removes the human-error vector. 3. **Registries themselves now run automated typosquat detection** — npm and PyPI both use similarity scoring (e.g., edit distance and download-count heuristics) against the most popular packages to flag and often remove suspicious near-miss names proactively, which acts as an ecosystem-wide backstop but isn't something an individual team controls or should rely on exclusively. 4. **Finally, code review on dependency changes** — treating a diff that adds a new dependency name as something a second person actually reads, not just approves reflexively — catches typos that automation misses, though it doesn't scale to every transitive addition. ## The boundary of this topic It's worth being explicit that once a malicious typosquat package is confirmed to have run in your environment, what to do about the compromised credentials, affected systems, and remediation is an application-security incident-response concern, not a dependency-resolution one — this topic is about the naming/resolution-time exposure and how to prevent the wrong package from being pulled in the first place.