Home / Knowledge hub / Typosquatting
Knowledge hub
Typosquatting
Publishing a package with a near-identical name, hoping a developer installs it by mistake.
What it means
Typosquatting is registering a name that is one slip away from a popular one and waiting for people to mistype it. In software, the name is a package on a registry such as npm or PyPI. A developer types one wrong letter, or a misremembered hyphen, and installs the attacker's package.
The malicious package often does what the real one does, so nothing looks broken, while it also steals secrets or opens a way in. MITRE catalogues the technique as CAPEC-630. The same idea is used with web domains to catch visitors.
Why it matters
Installing a package normally runs code with the developer's rights, on a laptop or build server that holds source code, tokens and keys. One mistyped command can hand those to an attacker. The mistake is human and small, which is why it keeps working.
Registries remove such packages once reported, but some stay live for days. It is a route into the wider supply chain attack family, and related to malicious packages generally. The cost of a single install can far exceed the cost of a careful review.
How it shows up
You meet it when a developer runs an install command from memory or a copied snippet. Repeated causes are copying commands from forums or generated answers without checking the name, no review of new dependencies, and installs on machines holding long-lived credentials.
Check the exact spelling, publisher and download history before adding a package. Keep an approved list or an internal mirror, require a review for new dependencies, use a lockfile, and keep secrets away from install steps. Registry tools and scanners flag some look-alikes, though not all.
Questions people ask
Typosquatting, answered
What is the difference between typosquatting and dependency confusion?
Typosquatting needs a human mistake, a name typed slightly wrong. Dependency confusion needs none: a build picks a public package that has the same name as a private one. The defences overlap.
Do registries block typosquatting?
Registries remove reported malicious packages and some add checks for look-alike names. Those measures reduce the problem but do not eliminate it, so your own review of new dependencies still matters.
How can developers avoid it?
Copy the package name from the project's official page, check the publisher, age and download history, and be cautious with commands from unknown sources. An approved internal list removes the choice altogether.
Can a scanner detect it?
Some tools flag packages with names close to popular ones, or with suspicious install scripts. They help but do not catch everything. A review step for new dependencies catches what automation misses.
Does it also apply to domains?
Yes. Look-alike domains catch people who mistype a web address or follow a misleading link, often to steal logins. Registering obvious variants of your own domain is a common protective step.
Sources
Where this comes from
Related
Terms that sit next to this one
Dependency confusion
Tricking a build into fetching a public package that shares a private package's name.
Malicious package
A published library built to steal data or run code on whoever installs it.
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
Install script risk
Code a package runs automatically the moment you install it.
Package pinning
Fixing a dependency to one exact version rather than accepting any newer release.
Who checks the new dependency?
This one lives in your build, not your running app. What we can evidence is proof-backed findings in the app, and a gate in CI/CD that can stop a build when one appears. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.