Dependency Hallucination in AI-Generated Package Manifests

A hallucinated package is a name an AI coding assistant suggests, imports, or tells a developer to install that does not exist on npm, PyPI, crates.io, or any other public registry. It is not a typo and it is not a known library under a different name. It is invented whole, but built to look real: it follows the naming conventions developers expect (crypto-validator, auth-helper-pro), it slots into an import statement without complaint, and it survives a glance from a tired engineer at 11pm. Large language models generate these names because they are predicting statistically likely text, token by token, not looking anything up. There is no live query against a registry at the moment of generation, so the model has no way to confirm the package it just recommended actually exists.

Researchers studying this behavior have split hallucinated names into three categories. The largest, at 51%, are fabricated names with no real-world referent. Next come conflations, at 38%, where the model fuses two real package names into something that sounds like it should exist (imagine a mash-up of requests and urllib3 that reads as plausible but isn't). The smallest group, 13%, are typo-variants, close cousins of real names that look like fat-fingered input. The fabricated and conflated categories are the dangerous ones precisely because they don't look like errors. They look like competent, idiomatic choices.

How often hallucinations occur, across models and registries

The clearest measurement of this problem comes from Spracklen et al., who ran 2.23 million code samples across 16 models, covering both Python and JavaScript. Across all 16 models, the average hallucination rate came out to 19.6%, roughly one in five package references pointing at something that does not exist, producing 205,474 unique hallucinated package names in total. That is not a rounding error. That is roughly one in five package references pointing at something that does not exist.

The gap between commercial and open-source models is where the study gets more interesting. Commercial models averaged a 5.2% hallucination rate, while open-source models averaged 21.7%, a difference of 16.5 percentage points. GPT-4 Turbo posted the lowest rate in the study at 3.59%. Certain CodeLlama models exceeded 33%, meaning roughly one in three suggested packages from those models was fictional.

A 2026 replication (arXiv 2605.17062) tested five frontier models released between October 2025 and March 2026, running 199,845 paired Python and JavaScript prompts. The rate compressed considerably, landing between 4.62% and 6.10% depending on the model, real progress even as the spread between the best and worst performer narrowed sharply from 16.5 percentage points to a small fraction of its original size. That is real progress. But a persistent floor across frontier models, all trained after the original study's findings were public, means this is a structural property of how these models generate text. It's a structural property of how these models generate text, and it is settling into a persistent baseline rather than trending toward zero.

Repeatability turns a statistical quirk into a targetable attack surface

Spracklen et al. ran the same prompts ten times each to test the stability of hallucinated names. They found that 43% of hallucinated package names reappeared on every single run, and 58% reappeared on more than one run. That is the finding that turns this from a curiosity into a security problem.

Random noise is hard to weaponize. A name that shows up once in a thousand generations and never again isn't worth an attacker's time. But a name that comes back every time, from the same model, given a similar prompt, is a fixed target. An attacker doesn't need to guess. They need to run the same class of prompts a handful of times, note which names repeat, and register those names on the relevant registry. From that point on, every developer using that model with a similar prompt pattern is a potential victim, and the attacker collects them passively, indefinitely, off a single registration.

The 2026 replication sharpens this further. It identified a set of 127 names, 109 on PyPI and 18 on npm, that all five tested frontier models hallucinated simultaneously, a model-agnostic target list. That is a model-agnostic target list. Register those 127 names once, and the payload sits in wait for users of any of the five providers, regardless of which assistant they happen to be running.

How slopsquatting works in the supply chain attack taxonomy

Seth Larson, the Python Software Foundation's Developer-in-Residence, coined the term "slopsquatting" in April 2025, and the name spread quickly after Andrew Nesbitt amplified it on Mastodon. The mechanic is straightforward: an attacker figures out which package names a given model tends to hallucinate, registers those exact names on npm, PyPI, or RubyGems, and waits. The next developer who asks that model for help, gets the same phantom suggestion, and runs the install command pulls the attacker's package straight into their project.

Slopsquatting is a pull attack. Nobody has to phish anyone. Nobody has to breach a network. The victim's own tooling reaches out and retrieves the payload voluntarily, because the developer asked their assistant for a dependency and trusted the answer.

It helps to place slopsquatting next to two attacks it gets confused with. Typosquatting exploits human typing mistakes, someone means to type request and types requets instead, and it gets caught by name-similarity and lookalike detection. Dependency confusion exploits the order in which package managers resolve names between public and private registries, and it gets caught by namespace controls and registry configuration. Slopsquatting exploits something neither of those defenses touches: a name an AI model invented that happens to look completely legitimate. Catching it requires malicious-package detection and pre-install existence checks, not spell-checking and not registry namespace rules.

The kill chain from hallucinated name to compromised environment

The attack runs in four steps, and none of them require much technical sophistication.

First, discovery. The attacker prompts an LLM directly, or watches output from tools like GitHub Copilot, Claude Code, or Cursor circulating on GitHub and developer forums, looking for hallucinated names that show up repeatedly.

Second, registration. The attacker claims the phantom name on the matching registry. This step needs nothing more than a registry account and the speed to act before anyone else notices the same pattern.

Third, payload construction. The registered package gets filled with a credential stealer, a backdoor, or code that tries to propagate further down the supply chain. Attackers who want the package to survive scrutiny will build a convincing README, fake documentation, and sometimes a GitHub repository dressed up to mimic a real, well-known project.

Fourth, delivery. The developer runs npm install or pip install, and the package's postinstall hook fires with the same permissions as the rest of the build process. There is no separate approval gate at that moment. The malicious code runs as if it were any other dependency, because as far as the tooling is concerned, it is one.

Real incidents that show the attack is not theoretical

The clearest demonstration came from a researcher's proof-of-concept around huggingface-cli. Multiple LLMs consistently hallucinated huggingface-cli as an installable package name, when the correct command is pip install -U "huggingface_hub[cli]". Lanyado uploaded an empty package under the hallucinated name, no functional code, no README, no SEO push behind it, purely to see what would happen. Within three months, it recorded more than 15,000 authentic downloads. The hallucinated name also turned up in the README of an Alibaba research repository, which shows the problem spreading through AI-generated documentation, not only through AI-generated code.

A second case involves an npm package called unused-imports. AI models hallucinate this name in place of the legitimate eslint-plugin-unused-imports. As of early February 2026, the malicious package was still live on npm and pulling in roughly 233 weekly downloads, even after npm had placed it under a security hold. That detail matters: a registry taking action does not zero out the install rate. Developers relying on stale caches, old scripts, or assistants that keep suggesting the same dead name keep feeding it downloads regardless.

Charlie Eriksen at Aikido Security documented a case where a hallucinated package name spread through live AI infrastructure, with autonomous agents incorporating and acting on it. Nobody planted that name as a deliberate lure. It propagated organically, agent to agent, through code reuse, showing that the hallucination-to-execution pipeline can run without a human attacker in the loop. Socket Security has documented dozens of separate cases through 2025 and 2026 of attackers deliberately targeting exact phantom names tied to popular coding assistants.

Why existing tooling does not catch this

Standard software composition analysis tools, npm audit, pip-audit, Dependabot, work by comparing a project's dependency tree against known vulnerability databases. A package registered yesterday has no CVEs assigned to it yet, so it comes back clean by definition. The tool is answering a question that doesn't apply here, returning a clean result only because no CVE has been assigned yet. It's just answering a question that doesn't apply here.

Static analysis tools have the same blind spot from a different angle. They look at code structure, at the abstract syntax tree, checking for known-bad patterns. A hallucinated import is syntactically indistinguishable from a real one. There is no malformed syntax to flag, because the attacker's package, once registered, is a perfectly normal, installable piece of software.

Retrieval-augmented validation, where an AI's suggestions get checked against a live package list before being accepted, sounds like it should close the gap, and it does close part of it. But it fails on exactly the timeline that matters most: once the attacker has registered the hallucinated name, that name now exists in the registry. The validation check passes. The malicious package installs without triggering a single warning. And for attackers willing to put in the extra effort, a convincing README and a repository that mirrors a legitimate project's structure will get past a casual human code review too.

Agentic coding pipelines amplify the risk beyond individual developers

The population exposed to this isn't a niche of early adopters experimenting with AI tools on the side. 84% of developers already use or plan to use AI coding tools, and 51% of professional developers report using them daily, the mainstream of software development, not the fringe. That is the mainstream of software development, not the fringe.

Agentic tools compound the exposure because they collapse the steps between suggestion and installation. Tools like GitHub Copilot, Claude Code, and Cursor can write the import statement, add the dependency to requirements.txt or package.json, and trigger the install command, all without a human pausing to look at the manifest in between. Andrej Karpathy's term for this workflow, "vibe coding," captures the pattern well, since the developer describes what they want, the AI implements it, and the developer may never type or even look at the specific package names the agent chose on their behalf.

Both sides of this problem are scaling through automation at the same time. Attackers monitor AI output at scale and can register a newly spotted hallucinated name within hours of it appearing. Developers, meanwhile, are accepting AI-generated suggestions at scale, often without pausing to verify anything against the registry directly. Those two automation curves meet at exactly one point: the install command. That is where the entire risk concentrates, and it is the point where none of the standard tooling described above is built to intervene.

Defenses that reduce exposure across the development lifecycle

Reducing exposure means intervening before that install command runs, and the interventions start well before code generation even happens.

Prompt hygiene is the first layer. Naming known-safe libraries explicitly in a prompt, rather than letting the model pick freely, cuts down the model's opportunity to invent something. Time-anchored prompts, ones that ask for "the latest" library or reference a specific date, spike hallucination rates as high as 84% in some testing, so those should be avoided. Submitting a prompt with a misspelled library name is similarly risky: a single-character error in the prompt can trigger hallucinations in up to 26% of tasks, since the model tries to reconcile a name that doesn't quite match anything real. Where model settings are configurable, consulting the model's documentation for guidance on output reliability can also help narrow generation toward more grounded predictions.

None of this replaces a pre-install existence check against the live registry, and none of it replaces malicious-package scanning on anything that does get installed. But prompt discipline is the cheapest control available, and it's the one under a developer's direct control before a single dependency ever gets resolved.