What Is Typosquatting? The Package Ecosystem's Silent Trap

Typosquatting is the practice of publishing a package, domain, or library under a name deliberately close to a popular one — close enough that a small typo, a misremembered spelling, or a moment of inattention leads someone to install the wrong thing. In package registries like npm and PyPI, it’s one of the most common ways malicious code ends up inside a legitimate project: not through a sophisticated exploit, but through a developer typing reqeusts instead of requests, or expresss instead of express.

How it plays out in package registries

A typosquatter identifies a widely-used package and publishes something under a name that’s one character off — a swapped letter, a missing hyphen, a doubled character, a common misspelling. The malicious package usually does one of two things: it mimics the real package’s functionality closely enough to avoid immediate suspicion while quietly exfiltrating environment variables, credentials, or source code in the background, or it simply runs malicious code once during install (via an install script) and never bothers pretending to be useful at all.

Because package installs commonly run arbitrary scripts during setup, a single mistyped npm install or pip install can be enough to execute attacker-controlled code on a developer’s machine or, worse, inside a CI pipeline with access to deployment credentials.

Common naming tricks

• Character substitution or omission — colour for color, lodahs for lodash, dropping or doubling a letter.
• Hyphen and underscore swaps — cross-env vs crossenv, since registries often treat these as entirely different package names even though they read almost identically.
• Scope confusion — publishing an unscoped package with the same name as a popular scoped one (or vice versa), so @org/utils and utils look related but aren’t.
• Combosquatting — appending a plausible-sounding word, like express-server mimicking express, hoping a developer assumes it’s an official companion package.

Typosquatting vs dependency confusion

Typosquatting relies on a human typo or a moment of inattention. A closely related but distinct attack, dependency confusion, exploits how package managers resolve names across public and private registries: if an organization has an internal package named internal-auth and a public registry also has a package by that exact name (no typo involved), some misconfigured tooling will pull the public — and potentially malicious — version instead of the internal one, simply because of how registry precedence was set up. Both attacks target the same trust assumption — that a package name reliably identifies its publisher — but typosquatting exploits human error while dependency confusion exploits tooling configuration.

Why it’s effective

Developers install dependencies constantly, often dozens of times a day across projects, and package names are just strings — there’s no visual cue distinguishing a legitimate, widely-audited package from a two-day-old typosquat with an almost-identical name. Registries generally don’t require identity verification tied to a specific well-known name, and popular package ecosystems have low friction for publishing, which is a feature for legitimate open-source contribution and a liability that typosquatting exploits directly.

How to reduce the risk

• Use a lockfile and commit it. A lockfile pins exact resolved versions and hashes, so a typo in a package.json dependency line doesn’t silently swap in a different package on every fresh install — see how npm, pnpm, and Yarn each handle lockfiles.
• Double-check package names before adding a new dependency, especially for less common ones — search the registry directly rather than trusting a name that appeared in a tutorial, a forum post, or an AI-generated code snippet, all of which can hallucinate plausible-but-wrong package names.
• Prefer scoped or verified publishers where the ecosystem supports them, and check download counts and publish history for anything unfamiliar — a package with a handful of downloads and a single recent release is worth a second look before it goes into a production dependency tree.
• Restrict install script execution in CI environments where possible, since that’s the most common vector for a typosquatted package to actually run attacker code rather than sit inert.
• Use automated dependency scanning as part of your broader software supply chain security practice — many scanners maintain databases of known-malicious and typosquatted package names and flag them before install.

This applies across ecosystems: Python projects managed with tools like uv benefit from the same lockfile-and-verification discipline as JavaScript projects, since typosquatting isn’t specific to any one language’s registry.

Why this is hard to fully automate away

Automated scanners are good at catching known-bad package names that have already been reported, but a brand-new typosquat targeting an obscure or newly popular package can slip past a database of past incidents simply by not having been flagged yet. That lag is exactly why process controls — lockfiles, name verification, restricted install scripts — matter as much as tooling: they reduce the blast radius of a typosquat that scanning hasn’t caught up to yet, rather than relying on detection alone to catch every case before it reaches a developer’s machine or a CI pipeline.

The takeaway

Typosquatting exploits the gap between what a developer meant to type and what a package registry actually resolves, turning an ordinary typo into a code-execution vector. There’s no way to eliminate human error entirely, so the real defense is structural: commit lockfiles so a mistyped dependency doesn’t get silently re-resolved on a teammate’s machine, verify unfamiliar package names before adding them, and treat install-time script execution — especially in CI — as a privileged operation worth restricting rather than a routine part of the build.