Domain Squatting and Package Registry Attacks

Type npm install loadsh instead of npm install lodash and you might install malware. That single character difference is all it takes. Package registry typosquatting is one of the simplest and most effective supply chain attacks, and it happens thousands of times a year across every major registry.

The Anatomy of Package Typosquatting

Package typosquatting exploits a simple truth: developers make typos. Attackers register package names that are common misspellings, variations, or confusingly similar names to popular packages.

The attack works because:

1. Package registries generally allow anyone to register any available name.
2. Developers install packages by typing names manually or copying from untrusted sources.
3. Installation tools don't warn about potential typosquats.
4. Malicious packages can execute code during installation (e.g., npm postinstall scripts).

Variations Beyond Typos

Typosquatting is just one technique. Related attacks include:

Combosquatting: Adding words to popular package names. If colors is popular, register colors-utils, safe-colors, or colors-js.

Brandjacking: Using the name of a well-known organization. Packages named google-analytics, facebook-sdk, or microsoft-utils that aren't actually from those companies.

Dependency confusion: Registering internal package names on public registries. If a company uses a private package called company-utils, registering that name on npm with a higher version number can trick build systems into downloading the public (malicious) version.

Namespace confusion: Exploiting differences between scoped and unscoped packages. @company/utils vs company-utils can cause confusion.

Scale of the Problem

Research consistently shows that typosquatting is widespread:

• A 2020 study found over 700 malicious typosquat packages on npm in a single week.
• PyPI removes hundreds of typosquat packages monthly.
• RubyGems has documented numerous typosquatting campaigns targeting popular gems.
• NuGet, Cargo, and Go package registries all face the same issue.

The attack is cheap to execute. An attacker can register hundreds of typosquat names across multiple registries in a single afternoon. Even if only a small percentage of developers fall for it, the payoff is significant.

What Malicious Packages Do

Once installed, typosquat packages typically:

Credential theft: Read environment variables for API keys, cloud credentials, and registry tokens. CI/CD environments are especially lucrative targets because they're rich with secrets.

Reverse shells: Establish a connection back to the attacker's server, giving them interactive access to the build environment.

Cryptocurrency mining: Use the host's compute resources to mine cryptocurrency.

Data exfiltration: Steal source code, configuration files, or other sensitive data.

Persistence: Install backdoors that survive package removal.

Dependency chain attacks: The typosquat package might include the legitimate package as a dependency, making it functional while adding malicious behavior. The developer doesn't notice anything wrong because the package appears to work.

Notable Incidents

ua-parser-js Compromise (2021)

While not a typosquat (it was a direct account takeover), this incident showed the blast radius of a popular package being compromised. The package had 8 million weekly downloads, and the malicious version installed cryptocurrency miners and password stealers.

crossenv (2017)

A typosquat of the popular cross-env npm package, crossenv was downloaded hundreds of times and stole npm tokens from developers' environments. The stolen tokens could have been used to compromise other packages.

PyPI Typosquatting Campaigns (2022-2023)

Multiple campaigns registered hundreds of typosquat packages on PyPI targeting popular libraries like requests, beautifulsoup4, and tensorflow. Some packages used homoglyphs (characters that look identical but have different Unicode code points) to make detection harder.

colors and faker (2022)

The maintainer of the popular colors and faker npm packages deliberately introduced destructive code in protest. While not a typosquat attack, it demonstrated how a single maintainer action can affect thousands of downstream projects. This event spurred a wave of opportunistic typosquatting as attackers registered variations of these package names.

Why Registries Struggle to Fix This

Package registries face structural challenges in preventing typosquatting:

Scale: With millions of packages, manual review is impossible.

False positives: Automated detection flags legitimate packages with similar names. Not every similarly-named package is malicious.

Name space freedom: Restricting naming could frustrate legitimate developers.

Global scope: Multiple registries exist across different languages, and there's no coordination between them.

Reactive model: Most registries remove malicious packages after they're reported, not before they're published.

Defenses

Lock Files and Exact Versions

Always use lock files (package-lock.json, Pipfile.lock, Gemfile.lock). Lock files pin exact versions and include content hashes. Even if a typosquat package is installed once accidentally, the lock file prevents it from being re-installed on other machines or in CI/CD.

Package Name Verification

Before installing a new package:

• Double-check the package name against the official documentation.
• Verify the package's author, download count, and repository link.
• Search for the package on the registry website rather than typing the name from memory.

Scoped Packages and Namespaces

Use scoped packages when available (@types/node instead of types-node). Scoped packages are tied to an organization, making impersonation harder.

Private Registries and Allowlists

For organizations, use a private registry that proxies public registries with an allowlist. Only approved packages can be downloaded through the proxy. This prevents both typosquatting and dependency confusion attacks.

Install Script Auditing

Disable install scripts by default and audit them before allowing execution:

npm install --ignore-scripts

Review what scripts a package runs during installation before enabling them.

Automated Detection Tools

Tools like socket.dev, npm audit, and pip-audit can detect known malicious packages and suspicious patterns. Integrate these into your CI/CD pipeline.

Internal Naming Conventions

For dependency confusion prevention, register your internal package names on public registries as placeholders, even if you don't publish anything there.

Monitoring New Dependencies

Require code review for any change that adds a new dependency. The review should verify:

• The package name is correct.
• The package is actively maintained.
• The package has a reasonable number of downloads and stars.
• The package source code is available and reviewed.

How Safeguard.sh Helps

Safeguard.sh directly combats typosquatting and domain squatting through comprehensive dependency analysis and SBOM management. When new dependencies are introduced, Safeguard.sh's scanning identifies suspicious packages, flagging those with names similar to popular libraries or with characteristics common to typosquats. The platform's policy gates can require approval before new dependencies enter your pipeline, ensuring that every package is verified before it becomes part of your software. Continuous monitoring tracks your full dependency graph, alerting your team when known-malicious packages or suspicious name patterns appear, providing an automated defense layer that catches what manual review might miss.