Safeguard
Software Supply Chain Security

What is Typosquatting

Typosquatting tricks developers into installing malicious lookalike packages. Learn how it works, real npm/PyPI attacks, and how to detect it.

Priya Mehta
DevSecOps Engineer
7 min read

In November 2019, a researcher known as Bertus flagged four packages on PyPI — including python3-dateutil and jeIlyfish — that looked almost identical to two of the most-downloaded Python libraries in existence: python-dateutil and jellyfish. Once installed, the fake packages quietly harvested SSH keys, GPG keys, and environment variables and shipped them to a remote server. That's typosquatting: registering a package, domain, or repository name that is a near-identical misspelling, character swap, or visual lookalike of a legitimate one, then waiting for a developer to fat-finger pip install or npm install and pull in malicious code instead of the real thing. Unlike phishing, which targets a person's judgment, typosquatting targets typing speed and autocomplete habits — and inside a CI/CD pipeline, one mistyped package name can execute with the build server's credentials attached. It's now one of the most common initial-access techniques into the open source software supply chain.

What Is Typosquatting?

Typosquatting is the practice of registering a package, domain, or account name that closely resembles a trusted one, so that a small human or automated typing error routes a victim to attacker-controlled code instead of the legitimate resource. The term originated in the domain-name world in the late 1990s, when squatters registered misspelled versions of brands like gogle.com to catch mistyped URLs and serve ads or malware. In software supply chains, the target isn't a person clicking a link — it's a developer or build script running npm install, pip install, go get, or cargo add against a public registry. Because package managers execute install scripts automatically (npm's postinstall, Python's setup.py), a single successful typosquat install can run arbitrary code before anyone reviews a line of the package.

How Do Attackers Create a Typosquatted Package?

Attackers rely on five repeatable naming techniques: character omission, character transposition, homoglyph substitution, combosquatting, and scope or namespace confusion. Character omission drops a letter, turning requests into reqests. Transposition swaps adjacent letters, the way electorn swaps two characters from electron. Homoglyph substitution swaps a character for a visually identical one — a Cyrillic "а" (U+0430) in place of a Latin "a," which renders identically in most fonts but is a different package name entirely. Combosquatting appends or prepends a plausible word, such as colorama-fix or python3-dateutil (the latter being an actual 2019 PyPI attack that mimicked python-dateutil by inserting "3"). Scope confusion abuses namespacing conventions, such as publishing an unscoped types-lodash to imitate the scoped, legitimate @types/lodash on npm. All five techniques exploit the same weakness: registries index packages by exact string match, not by semantic similarity, so colorama and colourama are treated as two completely unrelated, equally valid names.

What Are Real-World Examples of Typosquatting Attacks?

Three incidents trace the technique's evolution from a minor nuisance to a credential- and crypto-stealing weapon: crossenv on npm in 2017, the python3-dateutil/jeIlyfish cluster on PyPI in 2019, and colourama on PyPI in 2022. In August 2017, someone uploaded crossenv to npm to mimic cross-env, a legitimate package with millions of weekly downloads used to set environment variables across platforms; the fake package captured npm configuration data, including auth tokens, and npm's security team pulled it within days of discovery. In November 2019, the four-package cluster discovered by Bertus and analyzed by ReversingLabs went further, exfiltrating SSH private keys, GPG keys, and shell environment variables from any machine that installed jeIlyfish or python3-dateutil instead of the real jellyfish and python-dateutil. In 2022, Check Point Research documented colourama, a PyPI package typosquatting the widely used colorama terminal-coloring library; it installed a clipboard hijacker that silently swapped any cryptocurrency wallet address a Windows user copied for an attacker-controlled address, redirecting transactions without any other visible symptom.

How Common Is Typosquatting in Open Source Registries?

Typosquatting has scaled from isolated incidents to a persistent, high-volume background threat across every major package ecosystem. Sonatype's 2023 State of the Software Supply Chain report logged 245,032 malicious open source packages discovered that year alone — more malicious packages than the company had catalogued across the entire 2019–2022 period combined — and typosquats are consistently one of the largest categories within that total, alongside dependency confusion and protestware. The scale is driven by registry throughput: npm alone receives well over a thousand new package versions every day, a volume no manual review process can keep pace with, which is why both npm and PyPI added automated similarity and reputation checks (npm's package-similarity warnings shipped in 2020) rather than relying on human moderators. Attackers also batch-register variants: a single campaign will typically publish a dozen or more misspellings of one popular package name — for example variants of requests, numpy, or discord.py — betting that at least one slips past a developer's attention.

Is Typosquatting the Same as Dependency Confusion?

No — typosquatting and dependency confusion are distinct techniques that are frequently confused with each other despite exploiting different weaknesses. Typosquatting relies on a human or script making a spelling mistake, so the attacker registers a name that looks like the real one, such as colourama instead of colorama. Dependency confusion, the technique Alex Birsan used in 2021 to get code executing inside Apple, Microsoft, PayPal, and dozens of other companies, relies on a naming collision between a private internal package and the public registry: if a company has an internal package named acme-utils that isn't also published publicly, an attacker can publish a public package with that exact name and a higher version number, and misconfigured build tooling will pull the attacker's public version instead of the internal one — no typo required at all. Brandjacking and combosquatting sit somewhere in between, using a plausible but not-quite-identical name (django-rest-framework-jwt2) rather than a pure misspelling. All three end in the same outcome — attacker code running inside a legitimate build — which is why supply chain security tooling needs to check for all of them rather than typos alone.

How Can Development Teams Detect and Prevent Typosquatting?

Teams cut typosquatting risk with five concrete controls: exact-version pinning with lockfiles, private registry proxies with allowlists, automated name-similarity checks in CI, provenance and signature verification, and enforced copy-paste of install commands from official docs. Lockfiles (package-lock.json, poetry.lock, go.sum) stop an automatic upgrade from silently swapping in a same-named-but-malicious version, though they don't stop a typo on first install. A private registry proxy — such as an Artifactory or Nexus mirror configured with an allowlist of approved package names — blocks any install request for a name that isn't already vetted, which is the single most effective control against a one-off typo. Automated similarity scanning (Levenshtein distance and homoglyph detection against your existing dependency tree) catches new dependencies that are suspiciously close to something already installed, before a PR merges. Provenance verification — npm's provenance attestations and Sigstore-signed packages — confirms a package was built from the source repository it claims, which a typosquat, lacking that repository, cannot forge. Finally, banning manually typed install commands in onboarding docs and CI scripts in favor of copy-pasted, reviewed dependency manifests removes the human fat-finger moment that every typosquat campaign is designed to exploit.

How Safeguard Helps

Safeguard reduces typosquatting exposure across the software supply chain rather than relying on developers to catch every misspelling by hand. Safeguard generates and ingests SBOMs for every build, giving security teams a continuously updated, exact inventory of package names and versions so a suspicious or unexpected dependency — including a one-character variant of a known package — surfaces immediately instead of during an incident review. Griffin AI, Safeguard's detection engine, cross-references newly added dependencies against known-good package name and maintainer patterns to flag likely typosquats and combosquats before they reach a production build. Reachability analysis then determines whether a flagged package's code paths are actually invoked at runtime, so teams can prioritize the typosquats that pose real risk over cosmetic matches with no execution path. When a typosquat or malicious version is confirmed, Safeguard opens an auto-fix pull request that swaps in the legitimate, pinned dependency, cutting remediation from a manual hunt-and-patch process down to a single review-and-merge.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.