Traditional typosquatting relies on developers making typing mistakes: reqeusts instead of requests, lodahs instead of lodash. The attack surface scales with the number of typos a human might make for popular package names. Attackers register the misspellings and wait for careless pip install or npm install commands.
AI code assistants have created an entirely new typosquatting vector that does not depend on human typing errors. Large language models hallucinate package names -- they recommend packages that sound plausible but do not exist. When enough developers ask the same question, the LLM consistently recommends the same non-existent package. Attackers monitor these hallucinated recommendations and register the packages.
This is not theoretical. Researchers at Lasso Security demonstrated in 2024 that they could predict which package names ChatGPT, Gemini, and other LLMs would hallucinate for common programming tasks. They found that the hallucinations were remarkably consistent -- the same non-existent package would be recommended across multiple sessions and users.
Why LLMs Hallucinate Package Names
LLMs generate package names the same way they generate everything else: by predicting the most likely next token based on training data patterns. When asked "what npm package converts CSV to JSON?", the model might generate a package name that follows the naming conventions of real packages (csv-to-json-converter) but does not correspond to any published package.
The model does not check the npm registry. It does not verify that the package exists. It generates a plausible-sounding name based on patterns in its training data, which includes millions of code snippets, blog posts, and documentation pages that mention real package names.
Several factors make hallucinated names particularly dangerous:
Consistency. Unlike random hallucinations, package name recommendations tend to be stable across sessions. The model's training data creates a probability distribution over package names for a given task, and the highest-probability name is usually the same.
Plausibility. Hallucinated names follow real naming conventions. They look like legitimate packages. A developer who receives a recommendation for flask-session-manager from an AI assistant has no visual cue that the package does not exist -- it looks exactly like a real Python package name.
Trust transfer. Developers trust AI assistants, especially when the recommendation comes alongside code that appears functional. The cognitive load of verifying every recommended package against the registry is high, and many developers skip it.
The Attack Chain
The attack unfolds in stages:
Reconnaissance. The attacker queries multiple AI assistants with common programming questions and records the package names recommended. They filter for names that do not correspond to existing packages on npm, PyPI, or other registries.
Registration. The attacker registers the hallucinated package names. For maximum effectiveness, they create packages that actually provide the functionality the AI described. A csv-to-json-converter package that genuinely converts CSV to JSON is less likely to trigger suspicion.
Payload delivery. The malicious functionality is embedded alongside the legitimate code. It might execute only during installation (via lifecycle scripts), only after a delay, or only on certain systems (targeting CI/CD environments by checking for environment variables like CI=true).
Harvest. Developers who follow the AI's recommendation install the package. The malicious code executes. Credentials, tokens, or source code are exfiltrated. The developer may never know the package was suggested by an AI that invented the name.
Scale of the Problem
Research from the University of Texas at San Antonio found that approximately 20% of package recommendations from popular LLMs referenced packages that did not exist. For less common programming tasks (niche frameworks, specialized data formats), the hallucination rate exceeded 50%.
The npm registry is particularly vulnerable because of its low barrier to package publication and its massive namespace. Anyone can publish a package with any available name in seconds. There is no verification that the publisher has any relationship to the package name's implied functionality.
PyPI, RubyGems, and NuGet have similar vulnerabilities, though PyPI has implemented some protections against bulk package registration.
The attack scales with AI adoption. As more developers use AI code assistants for dependency selection, the number of potential victims grows. And unlike traditional typosquatting where each attacker must guess which typos will be common, AI-hallucinated names are predictable and shared across millions of users.
Detection Challenges
Traditional typosquatting detection works by computing edit distance between new package names and existing popular packages. A new package named reqeusts has an edit distance of 1 from requests, triggering a typosquatting alert.
AI-hallucinated names do not necessarily resemble existing packages. flask-session-manager is not a typo of any existing package -- it is a plausible but non-existent name. Edit-distance algorithms will not flag it.
Detection requires different techniques:
LLM output monitoring. Systematically query popular AI assistants and track their package recommendations. Flag recommendations that do not correspond to real packages. This is a cat-and-mouse game because model updates change recommendations, but it provides early warning.
Publication timing correlation. A package registered shortly after an AI assistant begins recommending that name is suspicious. Cross-referencing package registration timestamps with known LLM recommendation patterns can identify opportunistic registrations.
Behavioral analysis of new packages. Apply the same malware analysis techniques used for traditional typosquatting: check for lifecycle scripts, obfuscated code, network requests during installation, and credential harvesting patterns.
Developer education. The most effective defense is teaching developers to verify that recommended packages exist and are legitimate before installing them. Check the package's registry page, review its source code, verify its maintainer, and assess its download history.
Defensive Strategies
Registry-level defenses. Package registries can monitor for bulk registrations of packages that match LLM hallucination patterns. They can require additional verification for packages with names that are semantically close to common programming tasks but have no publication history.
Organizational policies. Require pre-approval for new dependencies. Maintain an allowlist of approved packages. Use a private registry that proxies the public registry with an approval workflow for new packages.
AI assistant integration. Some AI code assistants are beginning to verify package existence before recommending them. Encourage your team to use assistants that perform this verification and to distrust recommendations from assistants that do not.
Lock files as truth. If a package is in your lock file and has been reviewed, it is known. If a developer adds a new dependency based on an AI recommendation, the lock file change triggers a review. Make lock file reviews a standard part of code review.
SBOM monitoring. Track every dependency in your applications. When a new dependency appears, verify its provenance regardless of how it was discovered. AI-recommended packages should receive the same scrutiny as any other new dependency.
The Broader Implication
AI-generated typosquatting represents a shift in supply chain attack methodology. Traditional attacks exploit human error (typos, misconfiguration). AI-augmented attacks exploit human trust in AI systems. The attacker does not need to target the developer directly -- they target the AI that the developer trusts.
This attack class will grow as AI code assistants become more prevalent. The defense requires both technical controls (package verification, dependency firewalls) and cultural shifts (treating AI recommendations as untrusted input that requires verification).
How Safeguard.sh Helps
Safeguard.sh evaluates every dependency in your supply chain against behavioral and provenance signals, catching malicious packages regardless of how they entered your project. When a developer adds a package recommended by an AI assistant, Safeguard.sh checks its publication history, maintainer profile, code patterns, and known malicious signatures. Packages with no history, recent registration dates, or suspicious behavior are flagged before they reach production. For organizations where AI code assistants are part of the development workflow, Safeguard.sh provides the verification layer that the AI assistants themselves do not.