Slopsquatting: when LLM hallucinations become an attack surface

"Slopsquatting" is the name researchers have given to a class of supply-chain attacks where an attacker registers a package name that a large language model frequently hallucinates as a recommendation. When developers paste an LLM's suggestion into a terminal — pip install fast-data-utils — and the named package exists, but is malicious, the developer has been slopsquatted. The attack is the inverse of typosquatting: the developer didn't typo, the model did.

This post is a research note on the shape of the problem and what reduces the surface.

How LLM hallucinations create attack surface

LLMs trained on a snapshot of code and discussion will sometimes generate import statements or install commands for packages that don't exist. Studies of large model outputs have measured non-trivial rates of hallucinated package names — often single-digit percent of generated import suggestions across a range of mainstream models. The exact rate depends on the model, the prompt, and the language ecosystem.

For an attacker, the question is not whether models hallucinate (they do) but whether the hallucinations are consistent. If the same model, given different but topical prompts, produces the same fictional package name with reasonable probability, that name is a registrable attack target.

Public research (notably analyses from 2024 and 2025) shows that hallucinated package names are not uniformly random. Models bias toward plausible naming patterns: <topic>-utils, <topic>-tools, python-<topic>, <framework>-<feature>. When many developers prompt the same model on similar questions ("what's the best Python library for parsing PDFs?"), the model converges on a small set of fictional names.

The attack flow

The attacker:

1. Probes the model at scale. Submits topical prompts and records the package names suggested in the output.
2. Filters for names that the model produced multiple times across varied prompts.
3. Cross-checks each name against the public registry. Names that don't exist on PyPI / npm are candidates.
4. Registers the names and publishes a package — initially benign, possibly with a working stub of the suggested functionality, sometimes with a hidden payload.

Step 4 is where it diverges from typosquatting. Typosquatters publish stubs that pretend to be the real package; slopsquatters publish stubs that pretend to be the package the model said exists. The latter has no real reference to compare against — the developer is asking the model what to install, not what to typo-correct.

What makes slopsquatting effective

The developer trusts the model more than the registry. When an authoritative-sounding LLM recommends pip install some-thing, developers paste it. If the package exists, the install runs without prompting for verification.

Search engines start ranking the squatted package. Once published, the package appears in registry search and may rank for the topical query the developer asked the model. The squat reinforces itself.

Conversational developers move fast. A typical pair-coding-with-LLM session involves trying many libraries quickly. There is little incentive to stop and verify each one's pedigree.

What reduces the surface

Verify before installing. The mechanical fix is to look up the package on the registry before installing — check the publisher, prior versions, GitHub repository, weekly downloads. Tooling that surfaces this metadata at install time is more reliable than expecting developers to switch context.

Cooling-period gates. A slopsquatted package is, by construction, brand new. The first install attempt against a brand-new, unobserved package is exactly what a cooling gate refuses. The friction of "this package was registered three days ago and only one person has installed it" is enough to surface the question to the developer.

Internal package allowlists for production. For projects that go to production, restrict installable packages to a vetted list. New additions go through a review. Slopsquatting cannot land a package the allowlist hasn't approved.

Don't run LLM-generated install commands without inspection. Pasting pip install ... from any source — LLM, blog post, Stack Overflow — without verifying the package exists, has prior history, and is the package you intended is the same risk pattern. LLM output is not categorically worse than other sources; it just produces output at higher volume.

Open questions

Slopsquatting is recent enough that public datasets on its prevalence are limited. Open questions for the research community:

• What fraction of top-ranked LLM-suggested packages are non-existent at the time of suggestion, by ecosystem and by topic?
• What fraction of squatted hallucinated names get installed at non-trivial rates before they're pulled?
• Do model providers have an obligation (or incentive) to filter outputs against the live registry?

The answers will likely move quickly as model providers add tooling and as registries add more first-time-publisher friction.

Takeaway

Slopsquatting is the LLM-era variant of typosquatting. It exploits the developer-LLM trust loop and the registry's open publish path. The defenses that work are structural: verify packages before install, hold brand-new versions through a cooling window, and constrain production installs to a curated allowlist. Each defense is cheap individually; together they remove most of the surface.