Typosquatting in Package Registries

Typosquatting in package registries is the practice of publishing malicious packages under names that are typographic variations of legitimate, popular packages , exploiting the tendency of developers to mistype package names, autocomplete to an incorrect suggestion, or copy and paste from documentation that contains an error. The typosquatted package is typically designed to look legitimate on its registry page , matching the description, readme, and even the code interface of the genuine package , while silently executing malicious functionality: exfiltrating environment variables, installing backdoors, or establishing persistent access to the developer's environment.

The transitive exposure mechanism is the specific risk that makes typosquatting particularly dangerous. A developer who carefully reviews the packages they install directly may still be running typosquatted packages without knowing it , because a legitimate package they installed had a dependency on a typosquatted package, which itself was included in a trusted package's dependency tree. Transitive dependencies , the dependencies of your dependencies , are not reviewed with the same scrutiny as direct dependencies. A typosquatted package that inserts itself into a popular package's dependency tree reaches all of that package's consumers without any of them having directly chosen it.

The CVE absence problem compounds the risk. Security scanning tools that detect known vulnerabilities by CVE identifier will not flag a typosquatted package , typosquatted packages are not known vulnerabilities in the traditional sense. They are malicious code with no assigned CVE, no NVD entry, and no signature in traditional vulnerability databases. The SCA scan that provides comprehensive coverage of known vulnerabilities in legitimate packages provides zero coverage of malicious packages masquerading as legitimate ones.

Why this matters

Typosquatting matters for TPRM because your vendors' software products are built on dependency trees that may include typosquatted packages without the vendor's knowledge , because the typosquatted package was a transitive dependency, because it had no CVE, and because their SCA scans do not detect malicious packages by definition. The SBOM that lists all components does not distinguish legitimate packages from typosquatted ones , a typosquatted 'lodash-utils' appears in the SBOM alongside the legitimate packages.

• Typosquatted packages have no CVE , SCA vulnerability scans do not detect them
• Transitive dependencies not reviewed with same scrutiny as direct
• SBOM includes typosquatted packages , inventory does not distinguish malicious from legitimate
• Package legitimacy assessment absent from dependency review
• Registry monitoring for package name variations not implemented

What good looks like

Mature typosquatting defence programmes implement package legitimacy checks alongside vulnerability scanning , verifying package age, download history, maintainer reputation, and code review for newly added dependencies , and monitor for new packages with names similar to commonly used internal and external dependencies.

• Package legitimacy checks , age, download count, maintainer reputation for new packages
• New dependency review process , human review for newly added packages
• Registry monitoring for typosquatted variants of commonly used packages
• Dependency pinning , exact version specification preventing unexpected package substitution
• Build-time package verification , hash verification for all resolved packages

Tooling

Package Security , Socket.dev for real-time malicious package detection; Snyk for supply chain risk scoring

Socket.dev provides deep package inspection that goes beyond CVE scanning , analysing package code for malicious behaviour, detecting typosquatting patterns, and evaluating package legitimacy signals like maintainer reputation and code evolution. For TPRM practitioners, asking whether vendors use Socket or equivalent tools that detect malicious packages beyond CVE scanning provides a specific typosquatting defence question.

Governance challenges

The governance challenge with typosquatting is the scale of the dependency ecosystem. A modern software project may have hundreds of direct dependencies and thousands of transitive dependencies , manual review of all of them is not feasible. The governance resolution is automated tools that score packages by legitimacy signals and flag anomalies for human review, combined with dependency pinning that prevents unexpected package changes between builds.

• Deploy socket.dev or equivalent for malicious package detection beyond CVE
• Implement dependency pinning , lock file enforcement preventing version drift
• Review new direct dependencies before adding to production
• Monitor for typosquatted variants of commonly used packages
• Include malicious package detection in vendor build security assessment

If you are a small team

Enable Socket.dev or GitHub's dependency review action for your production repositories. These tools analyse package legitimacy signals , code changes, maintainer behaviour, install scripts , and flag packages with suspicious characteristics. Run it against your current dependency tree and review the flagged packages. The packages that Socket flags as suspicious are the ones that a CVE-based scan would never surface.

• Enable Socket.dev or GitHub dependency review for production repositories
• Review flagged packages from legitimacy analysis
• Implement lock file enforcement , dependency pinning
• Add legitimacy checks to vendor build security assessment

What to require

Ask directly:

"Beyond CVE scanning, how do you detect malicious packages that have no assigned CVE , specifically typosquatted or otherwise malicious packages in your dependency tree? And do you use tools that analyse package legitimacy signals beyond vulnerability databases?"

Expect as evidence

• Malicious package detection beyond CVE scanning
• Package legitimacy evaluation process
• Dependency pinning and lock file enforcement
• Transitive dependency review approach

A vendor who confirms SCA vulnerability scanning should be asked about malicious package detection. SCA scans known vulnerabilities. Typosquatted packages are not known vulnerabilities , they are malicious code with no CVE. Different tools, different threat model.

How to evidence it

• Package legitimacy tooling implementation
• Dependency pinning implementation
• New package review process records
• Malicious package detection capability

Key Takeaway

lodash: legitimate, 47 million weekly downloads. lodash-utils: typosquatted, 43,000 downloads, seven months on npm, 312 production deployments across enterprises that never directly installed it. No CVE. No SCA alert. Just code that ran. Typosquatted packages are not vulnerability database entries , they are malicious code that looks like legitimate packages. CVE scanning detects known vulnerabilities in legitimate packages. It provides zero coverage for malicious packages. Legitimacy analysis tools , Socket.dev, package behaviour analysis , provide the complementary coverage for the threat model that CVE scanning doesn't address.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security