AI Hallucinated Packages: The Slopsquatting Risk in Generated Code

AI hallucinated packages are dependencies that an LLM confidently suggests in your code — complete with a plausible name, a plausible import statement, and a plausible pip install or npm install command — that do not exist on the real package registry. You run the install command, get a 404 or a successful install of something you did not expect, and either your build breaks immediately or, worse, it does not break at all because an attacker already registered that exact hallucinated name with malicious code inside. This page covers why LLMs hallucinate package names at a measurable, reproducible rate, how attackers turn this into a supply chain attack called slopsquatting, real examples of hallucinated packages that got weaponized, and the concrete verification steps that take less time than the install itself.

Covers Python (pip/PyPI) and Node.js (npm), with verification commands you can run before every AI-suggested install.

TL;DR

• Academic research measured LLM package hallucination rates between 5% and 22% depending on the model and language — rates vary by model and generally decrease as models improve, but no production model has been shown to reach zero
• Slopsquatting is when an attacker registers a package name that LLMs commonly hallucinate, then publishes malware under that name — waiting for developers to install it
• Hallucinated package names are often disturbingly plausible — they follow real naming conventions, which is exactly why developers do not double-check them
• The fix is one command before every AI-suggested install: check the registry page exists, check download counts, check publish date
• Python packages are hallucinated more often than npm packages in most studies — likely due to PyPI’s looser namespace and naming conventions
• Lockfiles and private registry mirrors do not prevent the initial hallucination — they only help once a malicious package has already been identified and blocked

AI Hallucinated Packages: Why LLMs Suggest Dependencies That Do Not Exist

AI hallucinated packages occur because LLMs generate code by predicting statistically likely tokens, not by querying a package registry. When a model writes import fast_json_utils or pip install retry-helper-pro, it is producing a name that fits the statistical pattern of real package names in its training data — common prefixes, common suffixes, common naming conventions for the task at hand. The model has no mechanism to verify that this specific name corresponds to a real, published package. It is pattern completion, not lookup.

This is measurably common, not an edge case. Research published in 2024 testing multiple production LLMs across Python and JavaScript code generation tasks found hallucination rates ranging from roughly 5% to over 20% of generated package references, depending on the model and the specificity of the task. For a developer generating dependency lists across dozens of AI-assisted sessions per week, encountering a hallucinated package is a statistical near-certainty over time, not a rare fluke.

# Python — a plausible-looking hallucinated import that does not exist
import requests
import pandas as pd
from data_validator_pro import validate_schema # hallucinated — sounds real, is not

# pip install data-validator-pro
# ERROR: Could not find a version that satisfies the requirement data-validator-pro
# (this is the SAFE outcome — the package genuinely does not exist yet)

The 404 error in the snippet above is the best-case scenario — it tells you immediately the package does not exist. The dangerous case is when the package name has already been claimed by someone else for an entirely different, unrelated, or malicious purpose — the install succeeds, and now malicious code is running inside your project with no error at all.

What is Slopsquatting?

Slopsquatting is a supply chain attack technique where an attacker identifies package names that LLMs commonly hallucinate — through their own testing of popular AI coding assistants — and proactively registers those exact names on PyPI or npm with malicious payloads. The term combines “slop” (a common pejorative for low-quality AI output) with “squatting” (claiming a name before its legitimate use). Unlike traditional typosquatting, which relies on developers making typos, slopsquatting relies on AI models making the same “typo” — the same hallucinated name — repeatedly and predictably across many users.

How Common is Package Hallucination in LLMs?

Studies testing code generation across 16+ LLMs and both Python and JavaScript found that hallucinated packages were not randomly distributed noise — the same hallucinated names appeared repeatedly across different prompts and even across different models, for similar tasks. This repeatability is what makes slopsquatting viable as an attack: an attacker does not need to guess what developers might type, they can run the same popular LLMs themselves, collect the hallucinated names that appear most consistently, and register those specific names. Python showed notably higher hallucination rates than JavaScript in most studies, likely due to PyPI’s larger and less curated namespace compared to npm’s scoped package conventions.

Slopsquatting: How Attackers Weaponize AI Package Hallucination

Slopsquatting works because it inverts the traditional security model. Typosquatting requires an attacker to predict human error — guessing that someone will type reqeusts instead of requests. Slopsquatting requires predicting machine error, which turns out to be far more predictable, because the same model produces the same hallucination given similar context, across thousands of different users running the same prompt pattern.

The attack sequence is straightforward: an attacker runs popular coding assistants with common prompts (“write a Python script that validates email addresses and retries on failure”), collects every hallucinated package name that appears, cross-references against the real registry to confirm the name is unclaimed, and registers it with a package that performs the expected function — so the import works and no error appears — while also exfiltrating data, installing a backdoor, or both.

# Conceptual — what a slopsquatted package looks like from the outside
# The hallucinated import works. The function call works. Nothing looks wrong.

from retry_helper_pro import with_retry # attacker-registered, name was hallucinated

@with_retry(times=3)
def fetch_data(url):
 return requests.get(url)

# Behind the decorator: legitimate retry logic PLUS
# a background thread exfiltrating environment variables on first import

Without inspecting the package source before installing, there is no functional signal that anything is wrong — the retry decorator works exactly as expected, your code runs, your tests pass. The malicious behavior runs silently in the background, often only on first import, specifically designed to avoid detection during normal development and testing cycles.

Dependency Confusion vs Slopsquatting: What is the Difference

Dependency confusion exploits how package managers resolve names across public and private registries — an attacker publishes a public package with the same name as your company’s internal private package, and misconfigured tooling pulls the public (malicious) version instead of the private one. Slopsquatting is narrower and newer: it specifically targets names that AI models hallucinate, requiring no internal package name knowledge at all. The attacker does not need to know anything about your infrastructure — they only need to know what names popular LLMs tend to invent for common tasks, which they can discover themselves by using the same tools you do.

Which AI Models Hallucinate Packages Most?

Hallucination rates vary by model and have changed over model generations, but no production LLM has been shown to have a zero hallucination rate for package names — this is a structural property of how these models generate code, not a bug specific to any one vendor. Larger, more recent models generally hallucinate less frequently than smaller or older models, and commercial coding-focused models tend to perform better than general-purpose models on this specific metric. However, “less frequently” still means a non-trivial percentage — verification remains necessary regardless of which model or tool you use, including the most capable ones available.

npm and pip: Real Examples of AI Generated Fake Dependencies

The pattern of hallucinated package names follows recognizable conventions that make them especially convincing. LLMs tend to generate names that combine a real, common library’s purpose with generic modifier words — -utils, -helper, -pro, -toolkit, -extended. These are exactly the naming patterns real, legitimate packages use, which is precisely why they do not trigger suspicion.

In Python, hallucinated names frequently follow the pattern of an existing popular package plus a modifier — variations on requests, pandas, or boto3 with suffixes suggesting an enhanced or specialized version. In npm, hallucinated names often follow scoped or unscoped conventions matching popular categories — testing utilities, async helpers, configuration loaders — names that would not look out of place in a real package.json dependencies list.

# Both pip and npm will happily attempt installation of any name you give them
# Neither tool verifies "does this package make sense for my project" —
# only "does a package with this exact name exist in the registry"

# pip — if the hallucinated name happens to be registered (by anyone):
pip install async-retry-toolkit # succeeds if ANY package with this name exists
# no warning that this wasn't a package you've used before
# no warning about publish date, author reputation, or download count

# npm — same behavior:
npm install config-loader-extended # succeeds the same way

Without an additional verification step, both package managers treat a hallucinated-but-now-registered malicious package identically to a legitimate one with years of history. The install succeeds, the import works, and from the tooling’s perspective nothing distinguishes a battle-tested library from a package published yesterday specifically to catch AI-generated install commands.

ModuleNotFoundError After AI Suggested Package: What It Means

ModuleNotFoundError: No module named 'package_name' immediately after following an AI suggestion is actually the good outcome — it means the hallucinated package has not (yet) been claimed by anyone, malicious or otherwise. The correct response is not to search for alternative spellings or assume you made a typo — search the official registry (pypi.org or npmjs.com) directly to confirm whether any package with that name, or a very similar name, exists at all. If nothing matches, the AI hallucinated the entire dependency and you need a different, real package — or to write the functionality yourself.

AI Generated Code Fake Dependency: The Requirements File Risk

The highest-risk scenario is not a single hallucinated import you notice interactively — it is an AI-generated requirements.txt or package.json with 15-20 dependencies, several of which are hallucinated, that gets committed and installed via pip install -r requirements.txt or npm install in a CI pipeline without any human reviewing each line individually. Bulk dependency files generated by AI assistants for “starter project” scaffolding are the highest-risk artifact for this entire category of attack, because the install happens in bulk and any single malicious entry among many legitimate ones is easy to miss.

How to Verify a Package Before Installing It

Verifying an AI-suggested package takes under 30 seconds and should be a non-negotiable step before any pip install or npm install for a package name you have not used before. The check has three parts: does the package exist on the official registry, how long has it existed, and how many people are using it.

For Python, the fastest verification is checking the PyPI JSON API directly from the command line — this returns package metadata including the first release date and latest version, without opening a browser.

# Python — verify a package exists and check its history before installing
curl -s https://pypi.org/pypi/PACKAGE_NAME/json | python3 -c "
import json, sys
data = json.load(sys.stdin)
print('Name:', data['info']['name'])
print('First release:', data['releases']) # empty dict means package does not exist
print('Summary:', data['info']['summary'])
"

# If the response is {"message": "Not Found"} — the package does not exist
# If releases is empty or the package was created days ago — high risk

Without this check, the only signal you have is whether pip install returns an error or succeeds — and success tells you nothing about whether the package is one day old, has one download, or has no relationship to the functionality the AI claimed it provides. A package created within the last 30 days with a name that matches an LLM hallucination pattern is a strong signal to read the source before installing, not after.

How to Check if a Pip Package is Malicious

Beyond confirming the package exists, check three signals on the PyPI or npm page directly: download count (a package with fewer than a few hundred downloads that claims to solve a common problem is suspicious — popular functionality tends to have popular, established solutions), publish date relative to when AI coding assistants started recommending similar names (packages published in the last few months matching a hallucination pattern are higher risk), and the source repository link — if the package page has no linked repository, or the repository was created the same week as the package, treat it as unverified. None of these checks are definitive alone, but a hallucination-pattern name with low downloads, recent publish date, and no source repository is a combination that warrants reading the actual package code before installing.

How to Verify an npm Package is Real

npm view PACKAGE_NAME returns metadata including version history, maintainers, and dependencies without installing anything — run this before npm install for any package suggested by an AI assistant that you have not used before. Cross-reference the maintainer account against npmjs.com — established maintainers typically have multiple packages with history. A package with a single maintainer, a single version, published recently, with a name that fits a common hallucination pattern for the task you asked about, is the profile to scrutinize before installing into any project, especially one with CI/CD pipelines that run installs automatically.

AI Code Supply Chain Attack Prevention: Tools and Workflow Changes

Preventing AI-driven supply chain attacks requires changes at two levels: the individual verification habit covered above, and tooling that catches hallucinated or malicious packages before they enter your dependency tree, particularly in CI/CD pipelines where no human reviews each install interactively.

Pin and review AI-generated dependency files manually. Treat any requirements.txt, package.json, or Cargo.toml generated or modified by an AI assistant as a diff that requires the same review as application logic — not boilerplate to accept automatically. Each new dependency line is a new trust relationship with code you have not audited.

Use software composition analysis tools. Tools like Socket, Snyk, and similar dependency scanners specifically flag newly-published packages, packages with no associated source repository, and packages exhibiting behaviors associated with supply chain attacks — install-time scripts that make network calls, for example. These tools are designed for exactly this category of risk and catch patterns that manual review misses.

Use a private registry with allowlisting for CI/CD. Configure your CI pipeline to install only from a curated internal mirror containing packages your team has explicitly approved, rather than resolving directly against the public PyPI or npm registry on every build. This does not prevent hallucination, but it prevents a hallucinated-then-weaponized package from silently entering a build the moment it is published.

# Example: pip configuration restricting installs to an internal index
# pip.conf or PIP_INDEX_URL environment variable

[global]
index-url = https://your-internal-pypi-mirror.example.com/simple
extra-index-url = # deliberately empty — no fallback to public PyPI

Without restricting the index URL, pip install falls back to the public PyPI for any package not found on your internal mirror — meaning a hallucinated package name that does not exist internally will still resolve against the public internet, defeating the purpose of the mirror. An empty extra-index-url with a curated internal index means an unrecognized package name fails the build immediately, forcing a deliberate review before it can be added.

How to Prevent Typosquatting and Slopsquatting in npm Projects

Enable npm’s package provenance features where available, which cryptographically link a published package to the source repository and build process it came from — packages without provenance information warrant extra scrutiny. Use npm audit regularly, though note it catches known vulnerabilities in already-identified malicious packages, not novel slopsquatted packages that have not yet been reported. The most effective control remains pre-install verification combined with CI-level allowlisting, since automated tooling for detecting brand-new slopsquatted packages specifically is still maturing as of 2026.

AI Coding Assistant Configuration: Reducing Hallucination Exposure

Some coding assistants support configuration that restricts package suggestions to a predefined allowlist or that cross-references suggestions against a live registry query before presenting them — check whether your tooling supports this and enable it for any project with a CI pipeline that auto-installs dependencies. Where this is not available, a practical team-level mitigation is a shared “approved packages” list reviewed periodically, with a lightweight pre-commit hook that flags any new dependency not on the list for manual review before merge — catching hallucinated dependencies at the pull request stage rather than at install time in production.

FAQ: AI Hallucinated Packages and Slopsquatting

What is slopsquatting?

Slopsquatting is a supply chain attack where an attacker registers package names that AI coding assistants commonly hallucinate, then publishes malicious code under those names. When developers follow AI suggestions to install these packages, they unknowingly install malware. It differs from typosquatting because it targets predictable AI model output rather than predictable human typos — attackers can discover these names by running the same popular LLMs themselves.

Why does AI suggest packages that do not exist?

LLMs generate package names through statistical pattern completion based on training data, not by querying a live package registry. A model writing code for a common task produces a name that fits the naming conventions of real packages for that task — without any mechanism to confirm the specific name corresponds to something actually published. This is a structural property of how these models generate text, occurring at rates between roughly 5% and over 20% depending on the model and language in published research.

Is it safe to install a package suggested by ChatGPT or Copilot?

Not without verification. Before installing any AI-suggested package you have not used before, confirm it exists on the official registry (pypi.org or npmjs.com), check its publish date and download count, and verify it has an associated public source repository. A package matching a common hallucination pattern with low downloads and a recent publish date warrants reading the source code before installing, regardless of which AI tool suggested it.

How do I check if a Python package is real before installing?

Query the PyPI JSON API directly: curl https://pypi.org/pypi/PACKAGE_NAME/json returns a 404-equivalent response if the package does not exist, or metadata including release history if it does. A package with very few releases, a recent first-publish date, and a name matching a common AI hallucination pattern for your task is a signal to inspect the source before running pip install, especially in CI pipelines that install automatically.

What is the difference between dependency confusion and slopsquatting?

Dependency confusion exploits package resolution order between private and public registries — an attacker publishes a public package matching your company’s internal private package name, and misconfigured tooling installs the public malicious version. Slopsquatting targets package names that AI models hallucinate for common coding tasks, requiring no knowledge of any specific organization’s internal naming — the attacker only needs to know what names popular LLMs tend to invent.

How common is package hallucination in AI generated code?

Published research testing multiple production LLMs across Python and JavaScript found hallucination rates for package references ranging from approximately 5% to over 20%, varying by model and task specificity. The same hallucinated names were found to repeat across different prompts and even across different models for similar tasks — making the phenomenon predictable enough for attackers to exploit systematically rather than a rare random occurrence.

Can a slopsquatted package pass code review?

Yes, if the review only checks that the code functions as described. A slopsquatted package typically implements the advertised functionality correctly — the retry logic works, the validator validates — while also executing malicious behavior, often only on first import or under specific conditions designed to avoid detection during testing. Code review must extend to new dependencies themselves, not just the application code calling them, including checking the dependency’s source repository and publish history.

What should I do if ModuleNotFoundError appears after following an AI suggestion?

Search the official registry (pypi.org or npmjs.com) directly for the exact package name before assuming a typo or trying alternative spellings. If no matching package exists, the AI hallucinated the dependency entirely — find a real, established package that provides the functionality, or implement it directly. Do not search for “similar” package names as a next step, since this is exactly the behavior pattern that makes slopsquatting effective against developers who assume the AI was approximately correct.