In June 2024, a security researcher asked several popular AI coding assistants for a pip install command to work with a Hugging Face model. More than one model confidently suggested a package called huggingface-cli — a name that sounds official but does not correspond to the real package (huggingface_hub). The researcher registered the hallucinated name on PyPI as a proof of concept. Within three months it had been pulled down over 30,000 times by developers who trusted the AI's suggestion and never checked. Nobody had to breach a registry, steal credentials, or write clever malware to get there — they just had to notice what a language model was already inventing and wait for someone to run pip install. This is slopsquatting: a typosquatting-style attack that doesn't require a typo, because the AI already wrote the bad name for you.
What Is Slopsquatting, and Why Does It Work?
Slopsquatting is the practice of registering package names that AI coding tools hallucinate, so that when a developer copies the suggested install command, they pull down attacker-controlled code instead of nothing at all. The term was coined in 2024 by Seth Larson, security developer-in-residence at the Python Software Foundation, as a play on "typosquatting" and "AI slop." Traditional typosquatting relies on human error — someone types reqeusts instead of requests. Slopsquatting flips the trust model: the developer types the name correctly, exactly as the AI recommended, and the package still doesn't belong to the project it claims to. Because the install command "looks right" and comes from a tool the developer already trusts to write correct code, it bypasses the skepticism that normally protects against copy-pasted commands from sketchy forum posts.
How Often Do AI Coding Assistants Hallucinate Package Names?
More often than most engineering teams assume. A 2024 academic study from researchers at the University of Texas at San Antonio, Virginia Tech, and the University of Oklahoma — "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" — ran 576,000 code-generation samples across 16 popular models in Python and JavaScript and found that roughly 1 in 5 recommended packages didn't exist, totaling over 205,000 unique hallucinated package names. Open-weight models fared worse than commercial ones, with hallucination rates averaging in the low-to-mid 20% range compared to roughly 5% for the better commercial models tested, though even the best-performing models still invented package names some of the time. At the scale modern teams generate code with Copilot, Cursor, or in-house agents, a 5-20% hallucination rate on dependency suggestions isn't a rounding error — it's a standing queue of exploitable names.
Why Do Hallucinated Package Names Repeat Instead of Being Random?
Because the same prompt tends to produce the same hallucination, which is exactly what makes the attack economically viable. The UTSA-led study reran identical prompts ten times each and found that a large share of hallucinated names showed up again and again rather than varying randomly — meaning the same fake package name got suggested repeatedly across sessions, users, and even different models trained on overlapping data. If hallucinations were one-off noise, an attacker would have no reliable target to register in advance. Because they're stable and predictable — often plausible-sounding compound names like python-json-utils or a slightly-off variant of a real maintainer's naming convention — an attacker can mine public LLM outputs, forums, and GitHub Copilot suggestions to build a shortlist of high-probability names, then register the most promising ones on PyPI, npm, or crates.io and wait.
Has Slopsquatting Already Happened in the Wild?
Yes — researchers have already proven the exploit path works, and it predates the term itself. Security researcher Bar Lanyado documented the technique in 2023, before "slopsquatting" had a name, showing that ChatGPT repeatedly recommended a nonexistent package in response to common coding questions; he registered it as an empty proof-of-concept package and watched real download counts climb into the tens of thousands, including downloads originating from large companies' CI pipelines. That single case demonstrates the full kill chain: model hallucinates a name, researcher (or attacker) claims it, unsuspecting developers and even automated build systems install it. The 2022 torchtriton dependency-confusion compromise of PyTorch nightly builds — where attackers exploited a name collision to get malicious code executed inside Meta's infrastructure — shows the blast radius available once a lookalike or invented package name lands in a real build pipeline, even though that specific incident stemmed from a different naming gap rather than an LLM hallucination.
Which Ecosystems and Models Are Most at Risk?
Python and JavaScript are the most studied and most exposed, simply because they dominate AI-assisted coding workloads and have the loosest publishing barriers. PyPI and npm both allow essentially anonymous, instant package registration with no waiting period and minimal name-squatting protection, which is precisely the environment slopsquatting needs. Within those ecosystems, the same 2024 study found open-source and smaller code models hallucinated at roughly 4x the rate of top commercial models, but no model tested — including GPT-4-class systems — hit zero. Internal AI coding assistants and fine-tuned models trained on a company's own (sometimes stale or incomplete) internal package index carry an additional risk: they can hallucinate names that look like internal tooling, which is far more dangerous if an attacker registers the same name on a public registry that your build accidentally resolves against due to misconfigured internal-vs-public registry precedence.
How Can Teams Detect Hallucinated Dependencies Before They Ship?
Detection has to happen at the point a dependency enters the codebase, not after, because a hallucinated package that gets merged behaves exactly like a legitimate one until it executes malicious code. That means checking every new dependency — whether a human typed it or an AI agent suggested it — against signals that a hallucinated name lacks: registry age, maintainer history, download trends prior to the AI's training cutoff, and whether the package was published suspiciously close to when it started appearing in AI outputs (a strong slopsquatting tell, since legitimate packages typically predate their popularity). Manually vetting every pip install or npm install suggested by Copilot or an autonomous coding agent doesn't scale, especially as more of the software supply chain gets written by agents operating with minimal human review of each individual dependency choice.
How Safeguard Helps
Safeguard treats every new dependency — regardless of whether it was added by a human or an AI coding assistant — as an unverified claim until proven otherwise. Our supply chain security platform screens package additions against registry provenance, publish-date and maintainer-reputation signals, and behavioral indicators (install scripts, obfuscated payloads, unexpected network calls) that distinguish a young, unproven, potentially hallucinated package from an established one, catching exactly the pattern slopsquatting relies on: a brand-new, thinly-maintained package that suddenly starts getting installed. Because AI-assisted development pipelines can introduce dependencies faster than manual review can keep up, Safeguard integrates directly into CI/CD and pre-merge workflows to flag risky new packages before they reach a lockfile, giving security teams a policy gate specifically tuned for the AI-generated dependency problem rather than relying on developers to manually fact-check every package name their coding assistant suggests. As AI-written code becomes a larger share of what ships to production, verifying the supply chain those tools point to is no longer optional — it's the control that keeps a model's confident guess from becoming your next incident.