What Is Typosquatting? Attacks, Examples, and AI Risks

Typosquatting is a software supply chain attack in which someone publishes a malicious package under a name that resembles a legitimate dependency. A developer intending to install cross-env, for example, might install crossenv instead. The difference is only a hyphen, but the packages can have entirely different publishers and code.

The risk is not limited to typing mistakes. Dependencies can enter a project through copied commands, documentation, pull requests, automated updates, transitive dependencies, or AI-generated code. Some package managers support lifecycle scripts, which can execute automatically during installation. A malicious package can abuse these scripts to run code before a developer ever imports the library. If the installation environment exposes registry tokens, cloud credentials, or CI/CD secrets, that code may be able to access them and use the compromised environment as an entry point into the wider software supply chain.

The key question is not only whether a dependency has known vulnerabilities. It is whether the package is the one the developer intended to use, and whether its origin and behavior are acceptable.

Why AI Coding Assistants Add Risk

AI coding assistants can recommend libraries and write dependency declarations as part of generating an implementation. This speeds up development, but it can also make package selection less deliberate. A plausible-looking name in generated code may be accepted without the checks a developer would make when researching a library manually.

There is a related attack known as slopsquatting. An AI model may hallucinate a package name that does not correspond to an existing project. An attacker can register that name in the relevant package registry and publish a malicious package, hoping a developer will install it after receiving the AI's recommendation.

The distinction is useful: typosquatting takes advantage of a mistaken or deceptive package name; slopsquatting targets package names hallucinated by AI systems. Both exploit the assumption that a plausible package name is enough to establish legitimacy.

OWASP recommends verifying AI-suggested dependencies rather than accepting them at face value. Developers should check whether a package exists and review its history and maintainer information. AI-generated dependency changes should be subject to the same security controls as dependencies selected by a developer. 

Common Typosquatting Techniques

Attackers use several naming tricks to make a package look familiar:

• Character changes: Substitution (requasta instead of requests ), omission (requsts requsts), insertion (requestss), or transposition (requsets).
• Separator changes: Removing or changing a hyphen, underscore, or dot, as in crossenv and cross-env .
• Visual similarity: Using characters that resemble those in a legitimate package name.
• Cross-ecosystem impersonation: Using a familiar package name from another programming language or registry.

These techniques work because package names are often scanned quickly, especially in long dependency manifests or generated code. A familiar name is not proof that a package belongs to the project the developer knows.

Real-World Examples

The 2017 crossenv incident

In 2017, a malicious npm package named crossenv imitated the legitimate cross-env package. The malware targeted environment variables, which can contain credentials and other sensitive configuration. npm removed crossenv and dozens of related malicious packages.

The incident illustrates how a small naming difference can be used to reach developers and the secrets available in their environments.

Source: npm: crossenv malware on the npm registry

Cross-ecosystem impersonation in 2025

In May 2025, Socket reported more than 45 malicious npm packages mimicking libraries familiar to developers in Python, Java, .NET, C++, and other ecosystems. Examples included names such as beautifulsoup4, apache-httpclient, opentk, and seaborn.

These names did not need to be minor misspellings of npm packages. They borrowed recognition from other ecosystems, where developers might already know the corresponding libraries.

Source: Socket: npm targeted by malware campaign mimicking familiar library names

June 2026: A Malicious Dependency Hidden in the Supply Chain

In June 2026, attackers targeted Mastra npm packages by introducing easy-day-js, a malicious dependency masquerading as the legitimate dayjs date library. The attacker first published easy-day-js@1.11.21 without the malicious payload, then released 1.11.22 with an obfuscated postinstall loader that executed automatically during installation.

Because affected Mastra packages specified a compatible version range, fresh installations could resolve to the payload-bearing release.

The incident demonstrates why reviewing an application's source code is not enough. A malicious dependency can introduce executable behavior further down the dependency tree, making package identity, version resolution, and installation behavior important parts of dependency verification.

Sources: From package to postinstall payload

November 2024: Typosquatting Targets Cryptographic Libraries

Researchers identified malicious npm packages named crypto-keccak, crypto-jsonwebtoken, and crypto-bignumber, which impersonated familiar cryptographic libraries. The packages were designed to deliver spyware capable of collecting sensitive developer information and cryptocurrency-related data.

The risk is particularly serious when a developer selects a package based on a familiar name. In security-sensitive applications, an incorrect dependency can introduce malicious code into a project even when the intended library is legitimate.

Source: Typosquatting Cryptographic Libraries

Why Standard Security Controls May Miss Typosquatting

Typosquatting exposes a gap between knowing what is in a software project and verifying whether each dependency is the one the developer intended to select.

Different security controls answer different questions:

• Vulnerability scanning identifies known vulnerabilities in package versions. A malicious lookalike may have no reported CVEs because it is a separate package, rather than a vulnerable version of the legitimate library. A clean vulnerability scan therefore does not establish that a package is legitimate or benign.
• Software bills of materials (SBOMs) record the components identified in a software artifact. An SBOM can help establish which package was included, but its presence alone does not establish that the package was the intended dependency or that it is safe.
• Provenance and attestations provide evidence about a component's origin or how an artifact was produced. They can help verify that evidence, but they do not automatically establish that a package is benign or appropriate for the application.

These controls remain essential. The point is that they address different parts of the problem. Dependency selection also requires checking package identity, source, version, and relevant security signals before the package enters the build.

This distinction becomes more important when AI coding assistants recommend dependencies. A plausible package name is not proof that the package exists in the intended ecosystem, comes from the expected publisher, or is suitable for the project.

Practical Checks Before Adding a Dependency

Before adding a package, verify:

• Package identity: Confirm the exact name and ecosystem. Do not assume a familiar name identifies the intended library.
• Publisher and source: Check the package's repository, maintainers, publication history, and whether its purpose matches your requirements. Where possible, verify that the registry package corresponds to the expected upstream project rather than relying on a familiar name or a repository link alone.
• Version and resolution: Review the selected version and dependency range. Use lockfiles and controlled resolution to reduce unexpected changes between builds.
• Installation behavior: Inspect lifecycle scripts and other executable installation steps, especially when introducing an unfamiliar dependency.
• Approved sources: Prefer approved registries and repositories, and apply organizational rules for adding dependencies.

Manual checks alone cannot scale across every direct and transitive dependency. Organizations should automate dependency-risk checks and enforce policies in development and CI/CD workflows. Package installation should also take place in environments that limit access to credentials and secrets.

Verify Dependencies Before They Enter the Build

Dependency risk begins when a developer or coding assistant selects a component for an application, not only when the application is built or deployed.

Clean Libraries helps organizations evaluate open-source dependencies at the point of selection. This moves dependency governance earlier in the development process, where teams can assess whether a component is appropriate before incorporating it into an application.

This approach complements vulnerability scanning, SBOM generation, and provenance verification. Those controls remain important throughout the software lifecycle, while dependency selection requires its own checks for package identity, origin, and suitability.

As AI coding assistants accelerate development, organizations need a consistent way to govern the components developers and AI systems introduce into their projects.