Namesquatting

Namesquatting is the practice of publishing a package with a name designed to look like a legitimate one so a developer installs the wrong software. It includes typosquatting, combosquatting, and brandsquatting. The goal is to exploit trust, typing mistakes, or name recognition during package selection.

Expanded Definition

Namesquatting is a software supply chain attack pattern in which an attacker publishes a package, module, or dependency with a name intended to be mistaken for a legitimate one. The technique includes typosquatting, combosquatting, and brandsquatting, but the security issue is broader than misspelling alone: it exploits how developers search, copy, and install software dependencies under time pressure.

In practice, namesquatting sits between social engineering and package ecosystem abuse. A malicious package can imitate a trusted library, copy its metadata style, or use naming patterns that feel credible during dependency discovery. That makes the risk especially acute in repositories where package naming is loosely governed and where install commands are copied from issue threads, documentation snippets, or CI scripts. Guidance across ecosystems varies, so there is no single standard definition that covers every naming abuse case; some communities use namesquatting narrowly, while others group it with broader dependency confusion. For a governance view, the NIST Cybersecurity Framework 2.0 is useful for framing the protection of software acquisition and integrity.

The most common misapplication is treating namesquatting as a simple typo problem, which occurs when teams ignore malicious lookalike packages that are deliberately named to resemble trusted software.

Examples and Use Cases

Implementing defensive package controls rigorously often introduces friction in developer workflows, requiring organisations to weigh faster dependency installation against stronger verification and review.

• A developer intends to install a popular internal utility but selects a public package with a nearly identical name, allowing the wrong code to enter the build.
• An attacker publishes a package whose name combines a well-known brand with a common developer term, increasing the chance it will be chosen during search.
• A typosquatted package is uploaded to a public registry and later pulled into CI because an automated script references the mistyped dependency name.
• A repository maintainer registers a lookalike module shortly after a new open-source project gains attention, hoping users will confuse the two during installation.
• Security teams monitor dependency intake by comparing package names, publishers, and provenance data to detect suspicious lookalike artefacts before release.

Namesquatting is especially damaging when software is consumed from multiple registries or when build pipelines trust package names more than package origin. That is why software teams should pair naming checks with provenance review, pinning, and allowlisting rather than assuming a familiar name means trusted code. For broader supply chain context, the NIST Cybersecurity Framework 2.0 helps teams connect package selection risks to integrity and protective controls.

Why It Matters for Security Teams

Namesquatting matters because the failure mode is silent trust erosion: a developer believes they are installing approved software, but the package has only a deceptive name in common with the intended dependency. Once that code reaches a workstation, build server, or application runtime, the impact can include credential theft, malicious updates, data exposure, or downstream compromise across dependent systems.

Security teams need to understand namesquatting as a governance problem as much as a detection problem. Controls such as dependency review, artifact provenance, publisher verification, and registry policy all reduce exposure, but none are effective if teams assume package names are inherently reliable identifiers. The term also intersects with identity security in a practical way: the publisher identity behind a package can matter as much as the package name itself, especially when non-human workflows automatically trust software artifacts without human validation.

Organisations typically encounter the consequences only after a suspicious dependency is found in a build, at which point namesquatting becomes operationally unavoidable to address.