This post explains how attackers exploit AI-generated package name hallucinations to launch supply chain attacks, a technique called slopsquatting. It details how this threat differs from typosquatting, why AI assistants increase risk, and practical steps developers and teams can take to defend against these new attacks.
Slopsquatting is a supply chain attack that exploits AI hallucinations, not human typos. As AI coding assistants become the default in many workflows, attackers are watching for the package names these models invent. If you trust an AI-suggested dependency without checking, you could be opening the door to a supply chain attack.
Slopsquatting targets the trust you place in your AI assistant, not your own typing. In traditional typosquatting, attackers register package names that are close misspellings of popular libraries—think exress instead of express, or python-dateutl for python-dateutil. The attacker is betting you’ll make a typo.
With slopsquatting, the attacker isn’t guessing your mistake. They’re monitoring the names that AI coding assistants hallucinate. When a model invents a package that doesn’t actually exist, an attacker grabs that name and uploads a malicious version. The next time the AI suggests requests-oauth2-helper (which never existed before), and you install it, you’re now running the attacker’s code—even though you spelled everything correctly.
Here’s the difference in a nutshell:
| Typosquatting | Slopsquatting |
|---|---|
| Exploits human typos | Exploits AI hallucinations |
| Targets existing package names | Targets AI-invented names |
| Relies on user error | Relies on model error |
| Defended by typo-detection tools | Bypasses typo-detection tools |
Slopsquatting is a direct response to the growing use of AI for code generation and dependency suggestions. The attack surface has moved from user input errors to vulnerabilities introduced by AI models.
AI code assistants frequently hallucinate package names. Ask for a code snippet that does something specific, and the model might recommend an import from a package that doesn’t exist, but sounds plausible.
A USENIX Security 2025 study found that 19.7% of packages recommended by large language models (LLMs) across Python and JavaScript didn’t actually exist in the ecosystem. Commercial models hallucinated at least 5.2% of the time; open-source models, at least 21.7%. These are minimum rates, not upper bounds. That’s one hallucinated package for every 20 suggestions, minimum, even with commercial models.
The real danger: model hallucinations are reproducible, not just random noise. When researchers prompted models repeatedly, 43% of the hallucinated package names came back every single time. Attackers don’t need to guess random names—they just scrape model outputs, look for recurring hallucinations, and register those names.
Attackers can now preemptively squat on names that the model is likely to invent and recommend, weaponizing the AI’s confident but incorrect suggestions. All it takes is a developer copying and pasting the recommended install command.
Here’s how it plays out:
requests_oauth2_helper and tells you to install it:
from requests_oauth2_helper import attach_oauth2_token
pip install requests-oauth2-helper
By trusting the model's output, you've potentially exposed your system to compromise. No typo, no warning, nothing that would trigger typo-detection tools.
This isn’t rare. Because hallucinated names repeat, attackers can automate the attack:
When teams rely on AI tools to suggest dependencies, the old boundaries of trust shift. ...and often include code that appears functional. As a result, developers may focus on reviewing the code logic while overlooking the legitimacy of the dependency names.
The risks:
For teams, every AI-assisted install command is now a potential supply chain attack vector.
Since AI models are likely to continue generating non-existent package names, we need effective strategies and tools to detect them. Here’s what I do:
Search the package registry yourself
Don’t trust the AI’s package name blindly. Look it up on PyPI, npm, or your ecosystem’s registry. If it was published very recently, treat it as suspicious.
Check the package metadata
Who maintains it? Does it have a real homepage, documentation, or release history? Are there issues, stars, or any sign of a community?
Audit the code before installing
For small packages, read the source before you pip install or npm install. For binaries, check for reproducible builds or audit reports.
Pin and review dependencies
Use lockfiles. Don’t let transitive dependencies drift without scrutiny.
Document and review AI-suggested dependencies as part of code review
Require that all new dependencies added via AI suggestions go through human review.
Tooling for slopsquatting is only starting to emerge. Some approaches from existing supply chain security can help, and a few platforms are experimenting with AI-aware checks:
Package reputation databases
Services like PyPI’s “recently published” warnings or npm’s download counts can raise red flags for brand-new, little-used packages.
Dependency scanners
Tools like pip-audit, npm audit, or Snyk catch known vulnerabilities. They won’t catch brand-new slopsquatted packages, but they can highlight packages with suspicious or no history.
AI-aware dependency checkers (experimental)
Some security platforms are beginning to experiment with model-aware auditing, flagging packages that appear likely to be hallucinated.
Internal allowlists
Maintain a list of approved dependencies for your project or organization. Any new package—especially those surfaced by AI—should go through a review process before being added.
None of these are perfect, and slopsquatting is new enough that most detection is still manual. Combining these steps raises the bar considerably.
AI coding assistants are here to stay, but so are the attackers watching what they invent. Treat every package suggestion as potentially hostile until proven otherwise.
Join the discussion
Nothing here yet — be the first to weigh in.