← Concepts & Glossary
Signing & Supply Chain Trust

Typosquatting

Publishing malicious packages under names close to popular legitimate ones.

What is typosquatting?

Typosquatting in the software supply chain is the practice of publishing a malicious package under a name that is one or two characters away from a widely-used legitimate package, in the hope that a developer will misspell the name during installation and pull the attacker's code instead. It is a technique borrowed almost directly from DNS squatting — but package registries, unlike DNS, have historically had neither trademark enforcement nor proactive typo detection.

Canonical examples from npm include lodahs (target: lodash), color (target: colors), electorn (target: electron), and crossenv (target: cross-env). On PyPI, urllib and urllib3 have both had typosquatted siblings exposed multiple times.

How it works

The mechanics are almost dumb in their simplicity:

  1. Target selection. The attacker picks a high-traffic package — usually something with millions of weekly downloads — and generates candidate typo names using edit-distance, adjacent-key, or homoglyph variants.
  2. Malware preparation. A package is assembled that re-exports the legitimate library's API (so require('lodahs') still works) but adds a preinstall or import-time payload — credential exfiltration, cryptocurrency stealers, or persistence implants.
  3. Publication and wait. The package is published. A small fraction of a huge download volume will be typos — even a 0.01% typo rate on a million-downloads-a-week package is 100 infections a week.
  4. Operational payoff. Exfiltrated secrets get sold, or — more commonly in 2024–2026 incidents — used to pivot into cloud accounts and CI pipelines that matter far more than the developer who made the typo.

Why it matters

Typosquatting is cheap for attackers — a package publication is free — and expensive for defenders, because the space of plausible typos grows combinatorially with package name length. The only realistic defence is detection at the install boundary, using a combination of name-distance heuristics, download-velocity anomalies, and publisher-history signals.

Download statistics are the single strongest signal: a brand-new package whose name is within edit-distance 1 of a top-1000 package, published by an account with no history, is typosquatting until proven otherwise. A mature platform flags it at install, not six weeks later when a researcher finds it.

What value detection adds

  • Catch it at install time

    The cost of detection goes from "incident response" to "rejected install" when checks run in the package manager, not in post-hoc analysis.

  • Weighted edit-distance plus download history

    Levenshtein alone over-fires; combining distance with download-velocity and publisher-tenure signals makes false positives manageable.

  • Visibility across monorepos and services

    Any single developer's typo can ship to production — asset-wide scanning surfaces the squatted dependency wherever it landed.

  • Zero-day escalation

    A newly-published edit-distance-1 package that suddenly has a spike of pulls is a zero-day in progress — and treating it as one cuts dwell time dramatically.

  • Publisher attribution

    Typosquatting campaigns cluster — one detected squat often reveals a dozen more from the same publisher account, which can be blocked in one action.

How Safeguard uses it

Safeguard scores every newly-observed dependency against a typosquatting model that combines edit-distance against the top popular packages, publisher reputation, and download-velocity anomalies. Suspicious names are flagged as zero-day candidates and routed to Griffin AI for payload inspection.

See typosquat detection in your codebase.

Most teams are running at least one typosquatted package. Find yours before someone else does.