Your AI Invented a Package. Someone Registered It.
AI coding tools invent packages that do not exist, and the same fake names repeat. How slopsquatting works, what the research shows, and how to stay safe.
When an AI coding assistant writes code for you, it sometimes tells you to install a software package that does not exist. Researchers found this happens with about one in five package recommendations, and that the same fake names come back again and again. Attackers have noticed. Register the name the AI keeps inventing, wait for someone to install it, and you are inside their project. The attack has a name now, slopsquatting, and malicious packages using invented names are already live in public registries.
What is actually happening
Modern software is assembled rather than written. You pull in ready-made packages from public registries such as npm for JavaScript and PyPI for Python, and your project depends on hundreds of them. Installing one is a single command.
AI coding assistants know this, so when you ask for working code they often include an install line. The problem is that models sometimes name a package that was never published. The name looks right, it fits the task, and it does not exist. If you run the command, nothing happens, or rather, nothing happened until attackers worked out they could publish something under that name first.
The term slopsquatting was coined by Seth Larson of the Python Software Foundation and popularised by developer Andrew Nesbitt. It is a play on typosquatting, the old trick of registering a misspelling of a popular package and waiting for someone to fat-finger the install.
The foundational study is We Have a Package for You!, presented at the 34th USENIX Security Symposium in 2025 by researchers at the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech. It won a Distinguished Paper Award. The scale is worth stating precisely, because secondary coverage frequently garbles it. The team generated 576,000 code samples using 16 popular code-generating models, in Python and JavaScript, across two prompt datasets. Those samples contained roughly 2.23 million package references in total. Of those, 19.7 percent were hallucinated: packages that do not exist. Python averaged about 15.8 percent, JavaScript about 21.3 percent. Across all the hallucinations, the researchers catalogued 205,474 unique invented package names. A 2026 re-evaluation on newer frontier models, The Range Shrinks, the Threat Remains, found per-model hallucination rates had fallen to roughly 4.6 to 6.1 percent. That is a large improvement and it does not remove the problem. At a few percent of every package suggestion, across the volume of AI-written code now being produced, the absolute number of chances is still enormous.The numbers from the research
Why this is an attack and not just a bug
A one-off mistake is annoying. A repeatable mistake is a business model.
The USENIX researchers took 500 prompts that had produced a fake package and ran each one ten more times. Forty-three percent of the invented names came back on every single run, and 58 percent appeared more than once. The hallucinations are not random noise. They are a stable property of the model.
It gets worse across models. The 2026 re-evaluation reported 127 package names that five different frontier models invented identically. An attacker does not need to guess. They can run the prompts themselves, collect the names that keep appearing, register those names, and wait.
The researchers understood this clearly. In their public code repository they state that they deliberately do not release the list of hallucinated package names, because publishing it could enable package confusion attacks at scale. When the people who measured a problem decline to publish their own data, that tells you how exploitable it is.
Why normal defences miss it
Registries and security tools already watch for typosquatting, usually by measuring how many character edits separate a suspicious name from a real one. That check does not catch this. The Cloud Security Alliance's research note sorts the hallucinations from the USENIX data into three groups:
Pure fabrications, about 51 percent: plausible-sounding names that resemble nothing real. Something like aws-helper-sdk sounds like it should exist, and is nowhere near any actual package.
Conflations, about 38 percent: two real packages merged into one. The model knows jscodeshift and react-codemod, and produces react-codeshift.
Typo variants, about 13 percent: close enough to a real name that existing defences might flag them.
So roughly nine in ten hallucinated names are not typos at all, and a similarity check will never see them coming. This is a new category of risk wearing the clothes of an old one.
It is already in the wild
Two documented cases show the shape of the problem.
A package called unused-imports, which models hallucinate in place of the real eslint-plugin-unused-imports, kept recording roughly 233 downloads a week as of February 2026, even after npm had placed it under a security hold. A flagged package can keep finding victims for months, because the AI keeps recommending the name.
The second case is more unsettling. In January 2026, security researcher Charlie Eriksen found that a hallucinated npm package, react-codeshift, had spread across 237 repositories through forks, with agents still trying to install it daily. As documented in a review of the pattern, it originated in a single commit of AI-written agent instruction files that no human had reviewed. Eriksen registered the name himself, defensively, before anyone else could.
An honest caveat belongs here. As of mid-2026 there was no publicly documented case of a successful breach that began with a slopsquatted package. What has been documented is malicious packages sitting live on hallucinated names, models reliably producing those names, and the human checkpoint disappearing. That is a loaded gun rather than a casualty list, and it is still worth treating seriously.
Why AI agents make this worse
Until recently, this attack needed a person in the middle. The assistant suggested a package, a developer read the suggestion, and at some point chose to install it. That is a weak checkpoint, but it is a checkpoint.
Coding agents that resolve dependencies and run install commands on their own remove it entirely. Nobody reads the name. And as the react-codeshift case showed, once a hallucinated name is written into an instruction file that gets copied, forked and shared, it propagates on its own. Researchers have also described a technique chaining a hallucinated resource with a prompt injection, so that an agent fetching the invented thing can be steered into running attacker-supplied code.
This is the same lesson as every other agent security story this year. The model is not the dangerous part. The dangerous part is removing the human who used to glance at what was about to happen.
What to do about it
Check that a package exists before you install it
Search the registry for the exact name. Look at the download count, the publish date and the repository link. A package that appeared three weeks ago with no history and no source repository deserves suspicion, especially if an AI just recommended it.
Be more careful the more plausible the name sounds
Half of these are pure fabrications that sound exactly right. Sounding right is the attack.
Pin your dependencies and use a lockfile
Standard practice, and it limits what a bad install can quietly become later.
Do not let an agent install dependencies unsupervised
If you run coding agents, require approval for anything that adds a dependency. This is the single highest-value control available, and it costs almost nothing.
Review AI-written instruction and config files like code
The react-codeshift case started in a file nobody read because it was not code. Anything that tells an agent what to install is as sensitive as the code itself.
Teach this to anyone on your team using AI to write code
Most people who now generate code with AI have never heard of this failure mode, because they are not security professionals. They do not need to be. They need one habit: verify the package before installing it. Edapt covers practical AI risks like this in its AI workshops for working professionals, with dates on the events page.
Frequently asked questions
What is slopsquatting?
Slopsquatting is a software supply chain attack in which someone registers a package name that AI coding assistants frequently invent, so that developers or AI agents who follow the AI's recommendation install the attacker's code instead of nothing. The term was coined by Seth Larson of the Python Software Foundation.
How often do AI coding tools recommend packages that do not exist?
The USENIX Security 2025 study found 19.7 percent of package references across 576,000 generated code samples were hallucinated, with Python at about 15.8 percent and JavaScript at about 21.3 percent. A 2026 re-evaluation on newer frontier models found rates of roughly 4.6 to 6.1 percent.
Why can attackers predict which packages an AI will invent?
Because the hallucinations repeat. When researchers re-ran prompts that had produced a fake package, 43 percent of the invented names returned on every single run. A 2026 study also found 127 names that five different frontier models invented identically.
How is slopsquatting different from typosquatting?
Typosquatting relies on a human mistyping a real package name, and defences catch it by measuring string similarity. Only about 13 percent of hallucinated names are close typos. Roughly half are entirely invented names that resemble nothing real, so similarity checks do not flag them.
Has anyone actually been attacked this way?
Malicious packages registered on hallucinated names have been found live, and one kept recording around 233 downloads a week in February 2026 after being flagged. As of mid-2026 there was no publicly documented case of a successful breach that started with a slopsquatted package.
Does this affect me if I do not write code?
Indirectly. It affects anyone whose business runs software built with AI assistance, which increasingly means everyone. The practical action for a non-technical owner is to ask whoever builds your software whether AI agents can install dependencies without human approval.
How do I check whether a package is real?
Search the exact name on npmjs.com or pypi.org. Check the download history, the publish date, the maintainer and whether it links to a real source repository. If an AI recommended it and it looks newly published with no history, do not install it.
Where this leaves things
The honest summary is that this is a known, measured, partly mitigated problem that is getting better at the model level and worse at the workflow level. Hallucination rates are falling. The number of people shipping AI-written code without reading it is rising faster.
The fix is not sophisticated. Look at the package before you install it, and do not let an agent do it for you unsupervised. That is the whole defence, and it works today. More analysis like this is on the Edapt blog.
Sources
Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, 34th USENIX Security Symposium, 2025 (full paper).
PackageHallucination, the authors' code and data repository, including their decision not to publish the hallucinated name list.
Cloud Security Alliance AI Safety Initiative, Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks, 19 April 2026.
The Range Shrinks, the Threat Remains, a 2026 re-evaluation of package hallucination rates on frontier models.
Socket, The Rise of Slopsquatting, and Xygeni, Slopsquatting Evolution, for the documented real-world cases.