Slopsquatting is a supply chain attack where adversaries register package names that LLMs hallucinate, so that developers who install AI-suggested dependencies without checking pull attacker-controlled code. The term (coined by Seth Larson, popularized by Andrew Nesbitt) describes typosquatting's successor: instead of gambling on human typos, the attacker lets the model generate the bait. It works because hallucinations are not random noise — they are plausible, sticky, and shared across everyone using similar models. That makes them farmable.
The numbers that make it a real attack class
The key study — Spracklen et al., "We Have a Package for You!" (USENIX Security 2025) — tested 16 code-generation models across 576,000 generated Python and JavaScript samples:
- Commercial models hallucinated package names in roughly 5 percent of samples; open-source models averaged over 21 percent.
- The runs produced over 205,000 unique hallucinated package names.
- The finding that matters most: 43 percent of hallucinated names recurred across all 10 re-runs of the same prompt. Hallucinations are reproducible.
That reproducibility is the economics of the attack. An attacker doesn't guess what a model might invent — they run popular prompts ("Flask JWT auth example", "scrape site with retries") through popular models, harvest the recurring fake names, and register them on PyPI and npm. Every developer who later asks a similar question gets pointed at the now-real, now-malicious package. Classic typosquatting waits for one careless human; slopsquatting is served to victims by their own tooling, with the model as an unwitting distribution channel.
There is also documented precedent for the endgame: the huggingface-cli experiment in 2024, where a researcher registered a commonly hallucinated name and collected tens of thousands of downloads in months — including from repos at large companies — with an empty package. A hostile version ships a postinstall script instead of nothing.
Why it slips past traditional defenses
Typosquat detection works on edit distance to known packages: requsets is one flip from requests, so registries and scanners flag it. Hallucinated names are different — flask-jwt-simple-auth, numpy-utils-extra, fastapi-session-manager — they are semantically plausible, not typographically close. Nothing about the name is anomalous; the anomaly is that the package is three weeks old with one maintainer, no repository link, and a suspicious install hook.
So detection has to move from name-shape to package reputation:
| Signal | Threshold that catches most slopsquats |
|---|---|
| Package age | Under 30–90 days at time of first internal use |
| Downloads | Below a floor sane for its claimed purpose |
| Repository link | Missing, or repo has no matching code |
| Maintainer history | New account, no other packages |
| Install scripts | postinstall / setup.py doing network or shell work |
None of these signals is decisive alone. Together they are close to a fingerprint.
The developer-side gates
The fix is not "review AI code harder" — nobody sustains that. It is making package introduction mechanically safe:
- Verify existence and history before install. Sixty seconds:
npm view <pkg> time.created versions --jsonorpip index versions <pkg>plus a glance at the repo. If the model named it and the registry shows a three-week-old package, stop. - Quarantine new packages via a proxy registry. Artifactory, Nexus, or a curated proxy configured to refuse packages younger than N days unless explicitly approved. This single control kills the "register and wait" window that slopsquatting depends on.
- Gate PRs on dependency diffs. Any change to
package.json, lockfiles,requirements.txt, orpyproject.tomltriggers an SCA check that scores the new package's age, reputation, and install scripts — and fails closed on unknowns. Safeguard ships this as a policy gate; whichever tool you use, the property you want is that a hallucinated package becomes a red CI check, not a prod incident. - Lower the hallucination rate at the source. RAG over your approved dependency list, temperature reductions, and prompts that instruct "only use packages from this manifest" measurably cut hallucination rates (the USENIX paper's mitigation experiments cut them substantially without hurting code quality). Worth doing; not sufficient alone.
We looked at the model-side behavior in more depth in our 2026 package hallucination update.
What registries and maintainers can do
Registries sit at the choke point. PyPI's malware reporting pipeline and npm's provenance attestations both help, but the slopsquat-specific moves are: velocity limits on new-account publishing, holding periods before brand-new packages are installable by default, and — the interesting one — proactively registering high-frequency hallucinated names as permanent placeholders, the way huggingface-cli eventually was. A few ecosystems have started quietly doing this with lists harvested from the public research datasets.
If you maintain a popular library, check what models hallucinate near your namespace (yourlib-utils, yourlib-extras, yourlib2) and consider registering the obvious ones. It is an hour of work that removes an attack primitive aimed at your users.
Frequently asked questions
How is slopsquatting different from typosquatting?
Typosquatting exploits human typing errors, so malicious names cluster within one or two edits of real packages. Slopsquatting exploits model hallucinations, so names are semantically plausible but often typographically distant from anything real — which is exactly why edit-distance-based detection misses them.
Which ecosystems are most exposed?
npm and PyPI, because registration is free and instant and both are what code models emit most. The research showed JavaScript and Python hallucination rates in the same band; Go is structurally more resistant since module paths resolve to real repositories, and Maven's group-ID verification raises the registration bar.
Do reasoning models still hallucinate package names in 2026?
Less, but yes. Newer models with better refusal training and retrieval grounding show materially lower rates than the 2024–2025 cohort, but no model reports zero, and open-weight models lag. Since hallucinations recur predictably per prompt, even a 1 percent rate at coding-assistant scale is thousands of exploitable names.
What is the single control I should implement this week?
A minimum-age rule for new dependencies — block or quarantine anything published in the last 30 days unless a human approves it. It is one policy in your registry proxy or dependency gate and it defeats the wait-for-victims mechanic that makes slopsquatting profitable.