Ask an AI coding assistant how to accomplish some task, and it may cheerfully tell you to pip install a package that does not exist. The name sounds right — it follows the naming conventions of the ecosystem, it reads like something that should exist — but no such package was ever published. This is package hallucination, and on its own it is merely annoying: the install fails, you move on. The problem is what happens when an attacker gets there first. If they register the hallucinated name on the public registry with a malicious payload, the next developer whose assistant suggests that exact name installs the attacker's code. This attack has a name now — slopsquatting, a term coined in 2025 that blends "AI slop" with the older "typosquatting" — and it is one of the cleaner examples of AI creating an entirely new supply-chain attack surface.
Why models hallucinate package names
A language model does not look up packages; it predicts plausible text. When it generates an import or an install command, it produces the most statistically likely token sequence given the context, and "likely" is not the same as "real." If a package name fits the patterns the model absorbed during training — the right prefix, a sensible suffix, the conventions of the ecosystem — the model will emit it whether or not anyone ever published it. Hallucinated names are therefore not random gibberish; they are convincing, which is exactly what makes them dangerous.
Academic research presented in 2025 measured the scale of the problem across many models and hundreds of thousands of code-generation prompts. The headline findings are worth internalizing:
- Roughly one in five dependency recommendations across the tested models pointed at a package that did not exist.
- Open-weight models hallucinated substantially more often than commercial ones, but no model was immune.
- Critically, hallucinations were repeatable — a large share of invented names recurred across multiple runs of the same prompt. Repeatability is the attacker's gift: it means a hallucinated name is not a one-off fluke but a predictable target you can pre-register and wait on.
That last point is the whole attack. An adversary does not need to guess. They can run popular models against common prompts, harvest the names those models reliably invent, register the most frequent ones, and let developers' own assistants deliver the victims.
Slopsquatting versus its cousins
It helps to place slopsquatting next to the attacks it resembles:
- Typosquatting relies on a human typo —
requstsinstead ofrequests. Slopsquatting relies on a machine's confident invention, no typo required. - Dependency confusion exploits resolvers preferring a public package over an intended private one; the December 2022 PyTorch incident, where a malicious
torchtritonpackage on the public index shadowed the intended dependency, is the canonical case. Slopsquatting is upstream of resolution — the wrong name enters the manifest in the first place because an AI put it there.
All three end the same way: attacker code running in your build or your product. Slopsquatting is distinctive because the recommendation itself is the attack vector, and that recommendation carries the fluent authority of an AI tool the developer already trusts.
Defending against hallucinated dependencies
You will not fix this by asking models to stop hallucinating; they cannot reliably comply. You fix it by refusing to let a package name become an install without verification.
- Verify existence and reputation before installing. Every new dependency an assistant suggests should be checked: does it exist, is it the widely-used package you meant, how old is it, who maintains it, how many downloads does it have? A brand-new package with a plausible name and no history is the exact signature of a slopsquat.
- Gate dependency additions in CI. Do not rely on a developer eyeballing an install command. Make new-dependency introduction a checked event in the pipeline so an unrecognized package blocks the build instead of shipping in it.
- Pin and lock. Lockfiles with hashes ensure that what you reviewed is what you install, and that a later re-registration of a name cannot silently change the artifact.
- Prefer an internal, curated source. Proxying installs through an approved registry means a hallucinated public name simply is not available to resolve, closing the door before it opens.
- Educate developers on the pattern. The habit to build is skepticism toward any install command an assistant produces, especially for a package the developer has never heard of. The fluency of the suggestion is not evidence of the package's existence.
How Safeguard helps
Slopsquatting is, at its core, a dependency-verification problem, and dependency verification is exactly what Safeguard automates. Software composition analysis (SCA) checks every dependency in a manifest against existence, reputation, and vulnerability data, so a hallucinated or freshly-registered impersonation package is flagged the moment it appears rather than after it has run in your build. Delivered through the Safeguard CLI, that check runs in CI as a blocking gate, turning "the assistant suggested it" into "the pipeline verified it." The Griffin AI detection engine adds context by evaluating how a suspect dependency is actually used, and when a bad or vulnerable dependency needs replacing, auto-fix remediation proposes the corrected, verified package.
The irony of slopsquatting is tidy: AI created the attack, and disciplined dependency governance — the same discipline that has always defended the software supply chain — defeats it. The names your assistant invents only become a breach if you let them install unchecked.
Stop hallucinated packages before they install — get started free, read the documentation, or compare Safeguard vs Snyk on dependency security.