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.
Top comments (9)
This is the "see you there" arriving, then — the buildable half, wearing a supply-chain badge.
Honest answer first: yes, more than once — and almost always in a throwaway environment, which is exactly the rationalization this attack is built around. "The build worked, I moved on" is the whole story.
The thing I'd push one step further: the predictability you flag cuts both ways. If 43% of hallucinated names recur on every rerun, then your model's hallucination set is finite and enumerable. Run your real prompt corpus, collect every package name it invents, and that list becomes regression fixtures and a seed denylist for your registry gate. Attackers harvest your model's hallucinations from the outside; the cheap defense is to harvest them from the inside, from your own traffic, first.
On "gate its installs" — a gate that leaves no record is a habit, not a control. After an incident, "we had a verification step" is a policy statement; what an auditor (or an insurer) needs is the sequence itself: which model emitted the name (a claim), what the registry check returned (a verification), what approved or refused the install (a decision) — three separate events, reconcilable after the fact, the way you'd reconcile a payment decision against a provider response. That's the pattern behind the flight-recorder journal I keep mentioning: an agent that can install is an agent that must journal.
And your docs point might be the sleeper: agents increasingly write the docs too, so the verification has to attach to the artifact and re-run in CI — not just to the moment someone pastes the line.
Nothing caught in the wild on my side yet. But the early-warning metric is now obvious: the fake name that comes back on every rerun is the one to watch.
The inversion is the sharpest thing added: if 43% of hallucinations recur, the model's hallucination set is finite and enumerable — so run your own prompt corpus, harvest what it invents, and that list becomes regression fixtures and a seed denylist. Attackers harvest your model's hallucinations from outside; the cheap defense is beating them to it from the inside. That flips a scary stat into a build step.
And you're right that a gate with no record is a habit, not a control — three reconcilable events (claim, verification, decision) is the difference between "we had a step" and evidence. An agent that can install is an agent that must journal. See you there, indeed.
Twice now, then — "see you there" has closed both of these. So, the address: the journal's reconciliation layer, where claim, verification and decision become typed, replayable events, is sitting open as an issue that needs skeptics more than applause. You know where it lives. Bring the attempted breaks.
Long-lived trust is how a generated package name turns into a supply-chain problem after the human has left the chat. We tie dependency approval to the task, verify the package and owner, and hard-stop when that envelope expires. “The model suggested it” is not a permission model.
Hey, I'm building a small open-source CLI that analyzes a codebase and generates architecture/structure documentation. I'm looking for a few developers willing to run it against a real project and tell me where it gets things wrong.
You don't need to upload your code anywhere just run:
npx @autodocify/autodocs analyze .
Requires Node 20+.
If you try it, I'd especially like to know what it missed or misunderstood.
The 19.7% hallucination rate across 16 models is bad enough, but the 43% that recur on every re-run is the detail that makes this weaponizable, an attacker only needs the name to be predictable. Registering 205,474 plausible package names isn't hard once the model keeps suggesting the same fakes. Are you screening install-time against a known-good allowlist, or catching these at PR review?
You report 19.7% of recommended packages hallucinated across 576,000 samples, and the 43% recurrence figure is being read as good news — pre-register the phantom names and the attack dies. The practitioner catch is the other half of those numbers: only 43% recurred, and only ~13% were simple typos, so pre-registration covers the head of the namespace while a long tail of 205,474 made-up names stays unreachable. That leaves a registry-level allow-list that 404s anything unknown before the agent's pip install reaches the public index as the only control that doesn't degrade as models drift.
The tail is real, but the harvest was never meant to come from the study's 205k — it comes from your own corpus, on your own prompts, so the set that matters is whatever your stack actually re-invents. And the same corpus is the drift detector: re-run it on every model upgrade, diff the phantom set, and the gate learns the new names before production does. Allow-list stays the strong control; the harvest is what keeps it current.
The part about treating AI-generated package names as claims rather than facts really stands out. I think dependency verification should become a normal part of any AI-assisted coding workflow, especially when agents can install packages automatically.