You ask your AI assistant how to do something. It gives you clean, confident code, with an install line at the top:
pip install aws-helper-sdk
You run it. The build works. You move on.
Except aws-helper-sdk never existed. The model made it up. And last month, someone registered that exact name on PyPI — with malware inside — because they knew the model would suggest it.
That's slopsquatting, and it's the supply-chain attack built specifically for the AI coding era. The name was coined in 2025 by Seth Larson of the Python Software Foundation [1], and unlike most security scares, this one is measured, documented, and already in the wild. Let me walk through how it works, the numbers that make it real, and — the part you actually came for — how to not get caught by it.
Typosquatting needed your mistake. This one doesn't.
You already know typosquatting. An attacker publishes a malicious package called expres, betting that someone, someday, fat-fingers pip install express. It works occasionally, but it depends on a human error, and most people spell express correctly.
Slopsquatting flips the burden of the mistake. You don't have to slip. The AI makes the mistake for you — reliably, confidently, in code that looks completely correct — and the attacker registered the hallucinated name in advance. You did everything right. You just trusted the tool, and the tool invented a dependency that a stranger was already squatting.
That's the whole shift: the vulnerability moved from your carelessness to your trust.
The numbers that make this real
This isn't a thought experiment. The foundational study — "We Have a Package for You!", presented at USENIX Security 2025 — generated 576,000 code samples across 16 different LLMs and checked every package the models recommended [2].
The headline result: 19.7% of all recommended packages were hallucinated — nearly one in five. Across those hallucinations, the researchers logged 205,474 unique non-existent package names [2]. That's not a rounding error; that's a vast, ready-made attack surface.
The rate isn't uniform. Open-source models were worse (up to ~22%); commercial models did better, with GPT-4 Turbo the best performer at 3.59% [3]. And a 2026 re-evaluation of newer frontier models found the range had narrowed to roughly 4.6%–6.1% — better, but nowhere near zero [4]. The problem is shrinking, not gone.
So somewhere between 1-in-20 and 1-in-5 of the package names your AI hands you may point at something that doesn't exist. On its own, that's just an annoyance — a failed install. What turns it into an attack is the next fact.
The part that turns a bug into a weapon: it's predictable
Here's the insight that makes slopsquatting genuinely dangerous, and it's worth sitting with.
If hallucinations were random — a different made-up name every time — attackers couldn't do much with them. You can't register 205,000 names and hope someone hits the exact one you own. The noise would protect you.
But hallucinations aren't random. When the researchers took 500 prompts that had produced a fake package and re-ran each one ten more times, 43% of the hallucinated names came back on every single run [2]. Same prompt, same model, same invented package, over and over.
It gets sharper. A 2026 cross-model study found 127 package names that five different frontier models all invented identically [4]. Different tools, same phantom dependencies.
That predictability is the exploit. A systematic, repeatable model behavior becomes a namespace an attacker can register in advance [5]. They don't guess — they run the popular models against the popular prompts, harvest the hallucinations that reliably recur, register those exact names with malicious code, and wait. The model does the targeting for them, for free, every time a new developer asks a similar question.
Why your existing defenses don't catch it
You might think your supply-chain tooling has this covered. Mostly, it doesn't — because it was built for the last attack.
Typosquatting detection works on string similarity: how many single-character edits turn expres into express? That's a sensible defense against typos. But slopsquatted names aren't typos. The same study found that, by edit distance, only about 13% of hallucinated names were simple typos of real packages — nearly half were wildly dissimilar to anything that exists [6]. A name like aws-helper-sdk or fastapi-middleware [5] doesn't resemble a real package closely enough to trip a similarity check. It just sounds plausible — which is exactly what a language model is good at generating, and exactly what makes it slip past a human reviewer who isn't familiar with the specific ecosystem.
The defense built for human error is blind to machine error. That gap is the opening.
This is already happening
Slopsquatting isn't a projection. Malicious packages registered on hallucinated names are live in public registries right now. Security researchers documented one slopsquatted package that was still recording roughly 233 weekly downloads as of February 2026 — even after npm had placed a security hold on it [3]. People (and their agents) were still pulling it.
The propagation vector is worse than individual installs, too. When a hallucinated install command lands in documentation — a README, a tutorial, an official-looking guide — it spreads to everyone who copies it. There are documented cases of AI-recommended install commands for non-existent packages making it into trusted institutional docs [3]. One hallucination, copied into one popular guide, becomes thousands of installs.
And there's a structural reason the attack surface is so large: roughly 90% of the open-source ecosystem is dormant — millions of abandoned forks and experiments nobody looks at [5]. Humans stay on the well-trodden paths. Models sample the entire internet, including the forgotten corners, which is part of why they surface names that sound real but aren't.
How to actually defend against it
Here's the part you can act on today. There's no single magic fix — the honest defense is a few layered, boring controls plus one mindset change. The mindset change is the important one:
Treat any package name an LLM gives you as untrusted input, not a verified fact. A package name emitted by a model is a claim, not a citation. Every claim gets checked before it becomes a dependency. If you internalize only one thing, internalize that.
Concretely:
-
Verify before you install. Before running an AI-suggested
install, actually look the package up. Does it exist? How old is it? How many downloads? Does it have a real repo, real maintainers, real history? A package that "sounds official" but was published three weeks ago with 200 downloads is a screaming red flag — that's what a freshly-registered slopsquat looks like. -
Pin and hash your dependencies. Use lockfiles (
package-lock.json,poetry.lock), pin versions, and where you can, require hashes (pip install --require-hashes). Nothing should enter the build that you didn't deliberately vet. - Put a gate between the model and the registry. For teams: a private registry, an allow-list, or a dependency firewall so only approved packages resolve. The AI can suggest whatever it wants; only vetted names actually install.
- Scan new dependencies in CI, and flag the new ones for human eyes. A dependency scanner plus a rule that any newly added package gets a human review catches the slopsquat before it merges.
- Scan your own docs and READMEs. Hallucinated install commands propagate by copy-paste. Check your documentation for package-manager commands the same way you'd check code.
-
This one is critical for agents: if you have an autonomous coding agent that runs its own
installcommands, it will pull the malware with zero human in the loop. An agent that can install is an agent that can be slopsquatted at machine speed. Gate its installs behind verification or approval — do not let it self-install unvetted packages.(Some agent platforms are starting to build these install gates in — Xenition, which I work on, is one — but the principle matters more than any tool.)
None of these is exciting. All of them together turn "the AI said so, so I ran it" into "the AI suggested it, so I checked it." That's the whole defense.
The takeaway
Typosquatting punished carelessness — you had to make the mistake. Slopsquatting punishes trust — specifically, the quiet assumption that AI-generated code is basically correct, so the install line at the top is basically safe.
It isn't. About one in five of those lines (fewer on newer models, but never zero) points at nothing — and the ones that point at nothing point there predictably, which is exactly what lets an attacker be standing at the other end when you arrive.
So the rule is simple, and it costs you ten seconds: a package name from an AI is a claim to verify, not a fact to run. Check that it exists, that it's real, that it's the one you meant — every single time. Because the one time you don't bother might be the exact name someone registered last month, hoping you wouldn't.
Honest question: have you ever run an AI-suggested install command without first checking the package actually existed? Be honest — I have, more than once, before I knew this was a thing. What does your verify-before-install workflow look like now, and has anyone here actually caught a slopsquatted package in the wild?
Sources & further reading: [1] The term "slopsquatting" was coined by Seth Larson (Python Software Foundation) and popularized by Andrew Nesbitt, 2025. [2] Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs," USENIX Security Symposium 2025 (576,000 samples across 16 LLMs; 19.7% hallucination rate; 205,474 unique fake names; 43% recurrence on rerun). [3] Reporting and analysis from Socket, the Cloud Security Alliance research note on slopsquatting (April 2026), and industry writeups (GPT-4 Turbo 3.59%; the ~233 weekly-downloads case as of Feb 2026; documentation-propagation cases). [4] 2026 frontier-model re-evaluation ("The Range Shrinks, the Threat Remains"): per-model rates ~4.6%–6.1%; 127 package names hallucinated identically across five models. [5] Snyk / industry commentary on predictability as the exploitable property, example hallucinated names, and open-source dormancy (~90%). [6] USENIX 2025 study's Levenshtein-distance analysis: ~13% of hallucinated names were simple typos; ~38% were "conflations" merging two real names. Figures come from academic and vendor research across 2025–2026; treat specific numbers as reported-as-of-writing and follow the primary sources — especially the USENIX paper — for methodology and the latest data.