You ask an AI coding agent to add CSV parsing to your Python project. It suggests installing a package called "csv-toolkit-pro." You run pip install without thinking twice. The package installs successfully, runs your code, and quietly sends your environment variables to a remote server.
That package never existed in any legitimate form. The AI hallucinated the name, and an attacker registered it first. This attack is called slopsquatting, and it is one of the fastest-growing supply chain threats in software development.
Slopsquatting Meaning Explained
Slopsquatting is the practice of registering package names on public registries like npm, PyPI, or RubyGems that AI models are likely to hallucinate. Researchers have found that roughly 20 percent of packages suggested by AI coding tools do not actually exist. Attackers monitor these hallucination patterns, register the fake names, and upload malicious code under those names.
The term combines "slop," referring to low-quality AI output, with "squatting," the act of occupying a name before its legitimate owner can claim it. It was coined in early 2025 as researchers began documenting the scale of the problem. It falls under the broader category of AI-driven development risks.
"The AI does not know the package is fake. It generates the name with the same confidence it uses for real ones."
Why AI Models Hallucinate Package Names
Large language models generate text by predicting the most likely next token based on patterns in their training data. When asked to recommend a package for a specific task, the model does not search a live registry. It constructs a plausible-sounding name from patterns it learned during training.
Sometimes the generated name matches a real package. Sometimes it does not. The model has no mechanism to verify whether the package exists, what version is current, or whether it has been compromised. It simply produces what sounds right. This is a fundamental limitation of how context shapes AI responses.
Slopsquatting vs Typosquatting
Slopsquatting is often compared to typosquatting, but the two attacks work differently and target different weaknesses.
| Aspect | Slopsquatting | Typosquatting |
|---|---|---|
| Attack vector | AI hallucination of package names | Human typing errors |
| Target | Developers using AI coding tools | Developers typing install commands manually |
| Package name | Sounds legitimate but never existed | One or two characters off from a real package |
| Detection | Hard because the name looks intentional | Easier because the real package is well known |
| Scale | Automated, AI generates the same fake names repeatedly | Random, depends on individual typos |
The key difference is predictability. Typos are random. AI hallucinations are not. If a model hallucinates "flask-restful-auth" once, it will likely suggest the same name to thousands of other developers asking the same question. That makes slopsquatting far more scalable than typosquatting. This is a direct consequence of how LLM hallucinations work.
The Scale of Hallucinated Package Names
A 2025 study tested multiple AI models by asking them to recommend packages across ten programming languages. The results were alarming.
- Roughly 20 percent of all recommended packages did not exist on any public registry
- Open-source models hallucinated package names at higher rates than commercial models
- The same fake package names appeared repeatedly across different prompts and sessions
- Some hallucinated names were already registered by unknown parties, suggesting active exploitation
- Python and JavaScript ecosystems were the most affected due to the size of their registries
The repeatability is what makes this dangerous. A hallucinated name that appears once is a curiosity. A hallucinated name that appears consistently across thousands of developer sessions is an attack surface.
How Slopsquatting Attacks Work
The attack chain is straightforward and requires minimal technical skill.
- The attacker prompts several AI models with common coding questions and collects the package names they suggest
- They cross-reference those names against real registries to find the ones that do not exist
- They register the hallucinated names on npm, PyPI, or other registries and upload packages containing malicious code
- They wait for developers to follow AI suggestions and install the poisoned packages
The malicious payload can do anything a normal package can do. Steal API keys from environment variables. Exfiltrate source code. Install a backdoor. Crypto-mine on your CI server. The attacker gets code execution on the developer's machine or build pipeline with zero interaction beyond the initial install command.
"The developer trusts the AI. The AI trusts its training data. The training data says nothing about what exists right now."
How to Prevent Slopsquatting in npm and pip
Verify Before You Install
Never blindly run an install command suggested by an AI agent. Before installing any unfamiliar package, check it manually. Search the registry. Look at the download count, the publish date, the maintainer history, and the source repository. A package with zero downloads and no linked repository is a red flag.
Use Lockfiles and Dependency Auditing
Lockfiles pin exact versions and prevent surprise installations. Run npm audit or pip-audit regularly to check your dependency tree against known vulnerability databases. These tools will not catch a brand-new slopsquatted package, but they add a layer of defense. This ties into broader security practices for developers.
Pin Trusted Registries
Configure your package manager to only install from verified sources. In npm, use a private registry or scoped packages. In pip, use --index-url pointing to a curated internal mirror. This prevents the package manager from pulling unknown packages from the public registry.
Review AI-Generated Dependency Lists
When an AI agent adds packages to your requirements.txt or package.json, review every entry before running the install. This is part of managing the broader problem of unreviewed AI output that teams call workslop.
Use Socket or Similar Tools
Tools like Socket analyze packages for suspicious behavior at install time. They flag packages that access the network, read environment variables, or execute post-install scripts in unexpected ways. Adding these to your CI pipeline catches slopsquatted packages before they reach production. This is part of building a secure CI pipeline.
What Registries Are Doing About It
Package registries are beginning to respond. PyPI has started requiring two-factor authentication for maintainers and flagging packages with suspicious upload patterns. npm has implemented provenance attestation that links packages to their source repositories.
But registries face a fundamental challenge. They cannot ban a package name just because an AI might hallucinate it. There is no way to know in advance which names will be hallucinated, and blocking speculative registrations would break the open nature of these ecosystems.
The most promising approach is a combination of registry-side detection and developer-side verification. Neither alone is sufficient. Concepts like the lethal trifecta show why multiple layers of defense matter.
Conclusion
Slopsquatting exploits the gap between what AI models suggest and what actually exists on package registries. With roughly 20 percent of AI-recommended packages being hallucinated names, attackers have a massive and predictable attack surface to exploit. The defense is straightforward but requires discipline. Verify every unfamiliar package before installing it, use lockfiles and audit tools, pin trusted registries, and treat every AI-generated dependency list as untrusted input. Managing verification debt starts with reviewing what your agents install. As AI coding tools become the default way developers discover packages, slopsquatting will only grow as a threat unless these habits become as automatic as the install commands themselves.
