A developer asks Copilot for a quick way to batch-resize images in Python. The assistant suggests pip install pdf-toolkit-pro. It looks plausible — the naming convention matches real PyPI packages, and the assistant states it with total confidence. The developer runs the command. There's just one problem: pdf-toolkit-pro doesn't exist, or rather, it didn't until an attacker who guessed an LLM would eventually suggest it registered the name six months earlier and filled it with a credential-stealing payload.
This is slopsquatting: registering package names that AI coding assistants hallucinate, then waiting for developers to install them. It's not a hypothetical. A 2025 academic study tested 16 large language models across 576,000 code generation samples and found that 19.7% of recommended packages didn't exist — and attackers don't need to guess randomly, because the same fake names come up again and again. Here's what's driving it, how big the exposure is, and what actually stops it.
What Is Slopsquatting and How Is It Different from Typosquatting?
Slopsquatting is the registration of a non-existent package name that an AI model hallucinated, rather than a misspelling of a real one. Typosquatting relies on human error — a developer types reqeusts instead of requests, and a malicious lookalike is waiting. Slopsquatting relies on model error: the developer types the AI-suggested command exactly as given, but the package the model invented was never real in the first place.
The term was coined by Seth Larson, security developer-in-residence at the Python Software Foundation, in early 2024, and popularized through security research from Socket and academic teams through 2025. The distinction matters for defense: typosquat detection can flag edit-distance from known package names, but a hallucinated package name might be entirely novel-looking and plausible — fastapi-auth-utils, torch-vision-helpers, aws-lambda-toolkit — names that follow real naming conventions closely enough that neither a human reviewer nor a naive scanner blinks.
How Often Do AI Coding Assistants Actually Hallucinate Packages?
Far more often than most teams assume. The study "We Have a Package for You!" (Spracklen et al., USENIX Security 2025) ran 30 prompts across 16 code-generating LLMs and found an overall package hallucination rate of 19.7%, producing more than 205,000 unique hallucinated package names across the dataset. Open-source models fared worse — CodeLlama and similar models hallucinated in roughly a third of samples — while commercial models like GPT-4-class systems were lower, in the 5% range, but still far from zero. Across both Python (PyPI) and JavaScript (npm) ecosystems, no model tested was immune.
That rate isn't a one-off fluke either. When researchers reran the same prompts ten times, 58% of hallucinated packages showed up again in at least one rerun, and 43% of them repeated in every single rerun. That repeatability is what turns a model quirk into an attack surface: an attacker doesn't need to compromise a model or poison training data, they just need to query it enough times to find the hallucinations that recur reliably, then register those exact names before a real developer does.
Has Slopsquatting Already Been Exploited, or Is It Still Theoretical?
It's already happened, and it happened early. In 2023, security researcher Bar Lanyado (then at Vulcan Cyber, later Lasso Security) asked ChatGPT for help with a coding task and received a suggestion to install a package called huggingface-cli — which did not exist on PyPI at the time (Hugging Face's actual tool ships differently). As a proof of concept, Lanyado registered an empty, harmless version of that exact package name. Within three months it had been downloaded more than 30,000 times, and Lanyado found internal build scripts and documentation from at least one large enterprise, Alibaba, referencing the fake package by name — meaning the hallucination had propagated from a chat window into real internal tooling.
That was a defensive researcher racing to register the name before someone malicious did. There's no guarantee that pattern holds going forward: the economics favor attackers, since registering a package costs nothing and a single popped hallucination can land in hundreds of codebases before anyone notices. Security vendors including Socket have since documented copycat slopsquatting packages appearing on both PyPI and npm within days of being surfaced in public LLM hallucination research — a sign that some actors are actively monitoring this research for target names.
Why Do Models Keep Hallucinating the Same Fake Names?
Because LLMs generate plausible token sequences, not verified facts, and package names sit exactly where confident pattern-matching and factual accuracy diverge. A model trained on millions of pip install <package> and npm install <package> examples learns the shape of a package name — hyphenated, descriptive, framework-prefixed — without any built-in mechanism to check whether that specific string resolves to a real registry entry. When a prompt sits in a gap in training data (a niche library, a newer framework, a less common combination of features), the model fills it with the statistically likely-looking name rather than admitting it doesn't know one.
This is also why the same hallucinations recur across prompts and even across models: they're pattern completions of the training distribution, not random noise, so different models converging on similar training data converge on similar invented names. Larger context windows and retrieval-augmented tooling reduce but don't eliminate the problem, because many developers still use bare chat interfaces or IDE autocomplete without live package-registry verification.
Which Ecosystems and Workflows Carry the Most Risk?
Python and JavaScript carry the most documented risk, because PyPI and npm both allow open, instant, unverified package registration and both are the default targets in LLM training and benchmark data. The Spracklen study found hallucination rates were consistently present in both ecosystems, with no clear winner for "safer" — Python's data science and ML tooling sprawl gives models more surface area to hallucinate plausible-sounding utility packages, while npm's sheer package volume (over 3 million packages as of 2025) makes it easy for a fake name to blend in.
The riskiest workflow isn't a developer typing commands manually — it's automated or semi-automated pipelines that consume AI output with less human scrutiny: AI coding agents that execute suggested installs directly, CI/CD steps that regenerate dependency files from AI-assisted scaffolding, and "vibe coding" workflows where a developer accepts a full block of AI-generated setup instructions without checking each package individually. The more automation sits between the hallucination and the install, the less chance a human catches the fake name before it executes.
How Safeguard Helps
Slopsquatting defeats the two things developers normally rely on: their own judgment (the name looks legitimate) and the AI's confidence (it's stated as fact, not a guess). Stopping it requires verification that doesn't depend on either.
Safeguard addresses this at the points where hallucinated packages actually enter a codebase:
- Registry-truth dependency verification. Every package pulled into a build — whether a developer typed it, an AI assistant suggested it, or a CI job auto-generated it — is checked against verified registry metadata, publish history, and maintainer reputation before it's trusted, not just before it's flagged after the fact.
- New and low-reputation package scrutiny. Freshly registered packages with minimal download history, thin maintainer records, or naming patterns that mimic popular libraries are surfaced for review instead of silently entering the dependency tree — exactly the profile a slopsquatted package has in its first weeks.
- SBOM-driven drift detection. Safeguard tracks what's actually shipping in software bills of materials over time, so a package that appears in a manifest without a corresponding, reviewed pull request or ticket — a common signature of AI-assisted dependency additions — gets flagged for a closer look.
- Pipeline-stage enforcement. Policy checks sit in CI/CD, so an AI coding agent or automated scaffolding step that tries to pull an unverified or newly-registered package is stopped before merge, not discovered after a production incident.
- Attestation and provenance checks. For ecosystems and packages that support signed provenance, Safeguard verifies build attestations so a package's origin can be confirmed independently of what any assistant — human or AI — claimed about it.
The core problem with slopsquatting isn't that AI models are careless; it's that trust in a name has quietly shifted from "a human vetted this" to "an assistant said this exists." Safeguard's job is to put verifiable, registry-grounded truth back in that gap — so a hallucinated package name gets caught at the door instead of in production.