Slopsquatting: when your AI invents the dependency and someone registers it
You ask a coding agent to add CSV export to your Node service. It writes the feature, runs its tests, then executes npm install csv-parser-plus. The install succeeds. The feature works. You merge it.
csv-parser-plus does not exist. It has never existed. Your agent invented the name on the spot, and somebody registered it on npm last Tuesday.
That's slopsquatting. Typosquatting, except nobody had to typo anything.
The phantom restaurant
Imagine a navigation app that, when it doesn't know a restaurant, invents one. Name, address, turn-by-turn directions, star rating. People drive there. Now imagine you're a scammer with a lease. You don't need to hack the app. You just open a kitchen at the address it keeps sending people to, and wait for the customers.
Slopsquatting is that, with npm and PyPI as the street. The model invents a package name, the attacker registers it, the install command delivers the foot traffic. And npm packages can run arbitrary code on install through postinstall scripts, so the phantom restaurant gets to cook in your kitchen.

The term was coined in April 2025 by Seth Larson, developer-in-residence at the Python Software Foundation: AI slop plus typosquatting. It was a joke with a thesis, and the thesis has since been measured.
The numbers, because this sounds made up
At USENIX Security 2025, researchers from UT San Antonio, the University of Oklahoma, and Virginia Tech generated 576,000 code samples with 16 code-generating models, then checked every imported package name against the real registries. 19.7 percent of samples referenced at least one package that does not exist. That came out to 205,474 unique fake names. Open-weight models hallucinated more than commercial ones: 21.7 percent of their samples versus 5.2 percent.
The hallucinations are also stable, and that is what turns a curiosity into an attack. Re-run the same prompt ten times, and 43 percent of hallucinated names appear in every single run. Fifty-eight percent appear in more than one. These aren't random slips, they're fingerprints. An attacker needs a list, a registry account, and patience. Nothing else.
The shapes are predictable too. Per the same paper: 51 percent of the fake names are pure fabrication, 38 percent are two real packages mashed together, and 13 percent are near-typos of real ones.
2026: better models, same hole
A May 2026 replication (arXiv 2605.17062) ran five frontier models (Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, DeepSeek V3.2) through 199,845 prompts. Hallucination rates dropped to between 4.62 and 6.10 percent per model. Real improvement.
It also found 127 package names that all five models invented identically. Different companies, different training pipelines, same fake packages, and 53 of those names were still unclaimed and registrable. The models are converging on a shared phantom namespace. Register one of those names and you don't need to know which assistant your victim uses. Every assistant walks to the same fake door.
It has already happened
Three incidents worth knowing, all documented:
huggingface-cli (2023). Models kept recommending pip install huggingface-cli when the real install is pip install huggingface_hub[cli]. Researcher Bar Lanyado registered the fake name as an empty package to see what would happen. Over 30,000 downloads in three months, one of them courtesy of an Alibaba repository README that had copy-pasted the hallucinated install command. The package was harmless. The person who registers the next one might not be doing research.
unused-imports (npm, ongoing). A malicious package sitting next to the real eslint-plugin-unused-imports, catching the exact name models suggest when they mean the real one. npm put it under a security hold. As of February 2026 it was still pulling roughly 233 downloads a week.
react-codeshift (January 2026). A textbook conflation of jscodeshift and react-codemod. Security researcher Charlie Eriksen found it inside LLM-generated agent instructions on GitHub, already spread to 237 repositories through forks, with coding agents still attempting installs daily. He registered the name defensively, before someone less polite did.
There's an escalation path, too. July 2026 research (arXiv 2607.07433) chains the hallucination with prompt injection: pre-register the fake resource an agent will invent, put an adversarial prompt inside it, and the agent executes it inside its own tool loop the moment it fetches the thing. It worked on all six assistants the researchers tested, Cursor and Copilot Chat included.
The honest asterisk
A 2026 census (preprint, data on Zenodo) asked the obvious question: of the names models invent, how many actually get claimed? Across 6,800 generations from five open-weight models, 1,641 names were confirmed absent from the registry. Re-checked later: all 1,641 still unregistered. Among 149 older hallucinated names from public datasets, 22 were registered, and none of those were malicious.
So far, in that dataset, there is no mass land-grab on the phantom namespace. What exists today is pinpoint work: a handful of names with real traffic. Uncertainty is doing most of the work in the scare pieces on this topic. The risk concentrates where agents auto-install, which is exactly where the fixes go.
Why agents broke the old safety net
The old defense against a hallucinated package was a human squinting. You can usually tell a wrong name at a glance. Models don't glance. The agent generates code, reads its own imports, invokes the installer, reports success. Nobody in that loop knows what a suspicious package name looks like, and npx makes it worse, because it fetches and runs in a single motion, lockfile never consulted.
There's a 2026-edition remake of the classic xkcd about all modern infrastructure resting on one maintainer in Nebraska. In the remake, the guy in Nebraska replaced himself with a GenAI agent because the tokens were free. Same tower, except now the load-bearing peg at the bottom invents three more pegs on demand.

What to actually do
In order of effort:
- The five-second check. Any dependency an AI proposes: open
pypi.org/project/<name>ornpmjs.com/package/<name>before installing. Kills the entire class of attack. Costs five seconds. - Check who and when. The registry page shows the publisher and the registration date. An "official" helper registered last week by an account that publishes nothing else is not a dependency, it's a fishing lure.
- Freeze your installs.
npm ciin CI, nevernpm install. Nothing new gets resolved at deploy time. And don't let anything npx a name nobody has verified; that command is the whole attack in three characters. - Gate the agent. If your coding agent can install packages, put an allowlist or a human approval step in front of it. The Cloud Security Alliance's April 2026 note recommends exactly this, plus lockfile pinning and hash verification. Treat every import statement an AI writes as untrusted input, because that is what it is.
A satirical post made the rounds in May with the headline "'No Way to Prevent This,' Says Only Package Manager Where This Regularly Happens." Funny, and also an accurate summary of npm's design philosophy. You can't fix the registry from your desk. You can stop trusting inventories you never verified.
The models got better this year and the attack surface stayed the same size. Your defense is still one browser tab.