Typosquatting preyed on your fingers. Slopsquatting preys on your AI's imagination — and your AI is a far more consistent victim.
Here's the attack in one paragraph. AI coding assistants sometimes recommend software packages that don't exist — confident, plausible-sounding names for libraries nobody ever wrote. Researchers have measured this precisely, and the hallucinations turn out to be predictable: models invent the same fake names over and over. So attackers flip the script. Instead of waiting for a developer to mistype cross-env, they study which package names AI models tend to hallucinate, register those names on public registries, fill them with malware, and wait. The next developer — or autonomous coding agent — who trusts the AI's suggestion installs the attacker's code directly into the build. No typo required. The AI itself pulls the malware in.
This is worth your attention even if you're not a developer, because the structural insight generalizes: slopsquatting is the first mainstream attack class that targets the model's failure mode instead of the human's. Registries spent decades building defenses against human error — spell-distance checks, lookalike detection. None of that catches a fabricated-but-plausible name, because it isn't a misspelling of anything. As AI writes a larger share of the world's code, attacks aimed at how AI fails will scale right along with it. Guardrails designed for human mistakes won't save you. You need guardrails designed for AI mistakes — which is, not coincidentally, how we think about deploying AI Employees.
Key Takeaways
- Slopsquatting is registering packages under names AI models hallucinate, so the malware gets recommended — and installed — by the AI itself.
- USENIX Security research measured the problem: across 576,000 generated code samples, 19.7% of recommended packages didn't exist, yielding 205,474 unique fake names.
- The hallucinations are predictable — 58% of fake names recurred across runs — which is exactly what makes them attackable at scale.
- It's already happening in the wild: a placeholder for the hallucinated
huggingface-clipackage drew over 30,000 downloads in three months. - The defense stack is unglamorous and effective: dependency allow-lists, lockfile discipline, provenance checks, and a verification gate before anything an AI wrote reaches CI.
What Is Slopsquatting, and How Is It Different From Typosquatting?
The term — a blend of “AI slop” and “typosquatting” — was coined by Python Software Foundation developer-in-residence Seth Larson and popularized by Ecosyste.ms creator Andrew Nesbitt, as Socket's research team documented when the attack class first drew serious attention.
Typosquatting is decades old: an attacker registers crossenv hoping developers fat-finger the real cross-env. Registries have real defenses against it — they block near-miss spellings of popular packages and flag suspicious lookalikes. Slopsquatting routes around all of it. As VentureBeat's analysis puts it, an LLM recommends fictitious packages that sound plausible rather than ones that look mistyped — a registry that catches crossenv will wave through cross-env-extended, because it isn't close enough to anything to look like a typo. It's not an error in the human sense at all. It's an invention.
And inventions, it turns out, are reproducible. Because LLMs generate the statistically likely next token rather than checking a registry, the same prompt contexts summon the same phantom packages again and again. That repeatability converts a quirk into an attack surface: learn what the models dream up, register the dream, load it with a payload, and let the AI do your distribution for you. Malicious packages can then sit undetected in production dependencies for months.
How Big Is the Package-Hallucination Problem, Really?
Big enough to measure rigorously. The definitive study — “We Have a Package for You!” from researchers at the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech, presented at USENIX Security 2025 — tested 16 popular code-generation models across 576,000 Python and JavaScript code samples. The numbers deserve a table:
| Finding | Number |
|---|---|
| Generated packages that didn't exist | 19.7% (440,445 of 2.23 million) |
| Unique hallucinated package names | 205,474 |
| Average hallucination rate, commercial models | 5.2% |
| Average hallucination rate, open-source models | 21.7% |
| Best performer (GPT-4 Turbo) | 3.59% |
| Best open-source performer (DeepSeek 1B) | 13.63% |
| Hallucinated names that recurred across runs | 58% |
| Names that recurred every single time | 43% |
Three of those rows matter more than the rest. First, the commercial-vs-open-source gap: open models hallucinate packages at roughly four times the rate of proprietary ones, so teams standardizing on open-source coding models carry proportionally more of this risk. Second, the recurrence rates — 58% of fake names repeating across runs — are the attacker's business case. Random noise can't be squatted; consistent hallucinations can. Third, per SecurityWeek's coverage of the research, the researchers' warning is about the ecosystem effect: every user who receives the same fictitious recommendation becomes a potential installer of the same adversary-controlled package.
Package hallucination is also just one face of a broader reliability problem. VentureBeat cites a separate study finding general hallucination rates ranging from 50% to 82% depending on the model and prompting method — and even the best-performing model tested couldn't get below 23% with prompt-based mitigation. Package names happen to be the place where a hallucination stops being an embarrassing answer and becomes executable code in your build.
The trend lines amplify all of it. VentureBeat cites research tracking 31,267 vulnerabilities across 14,675 packages that found reported vulnerabilities growing 98% annually — nearly four times the 25% growth rate of open-source packages themselves — alongside an 85% increase in the average lifespan of a vulnerability. Meanwhile, per the same VentureBeat analysis, developers who use AI tools estimate over 40% of their committed code now includes AI assistance, 72% of those who have tried AI coding tools use them daily, and both numbers are expected to keep climbing. We wrote about what happens at the far end of that curve when Anthropic reported 80% of its code is now AI-authored: AI-generated code volume is compounding, and slopsquatting exposure compounds with it.
Has Slopsquatting Actually Happened in the Wild?
Yes — this stopped being theoretical a while ago. Aikido Security's field documentation collects the cases worth knowing:
huggingface-cli— AI models repeatedly recommended this nonexistent Python package (the real tool ships insidehuggingface_hub). When a researcher registered it as an empty placeholder, it accumulated over 30,000 genuine downloads in three months, and even appeared in a public Alibaba repository's documentation. Every one of those downloads was a live-fire demonstration: had the placeholder carried a payload, it would have executed inside 30,000 environments.unused-imports— a confirmed malicious npm package trading on confusion with the realeslint-plugin-unused-imports. As of early February 2026 it was still drawing 233 downloads a week from developers following AI recommendations.react-codeshift— a hallucinated blend ofjscodeshiftandreact-codemodthat appeared in 47 AI-generated agent skills on GitHub and spread to 237 repositories through forks, with autonomous agents continuing to attempt daily installs of a package that never existed.
Notice what these cases share: none of them would have looked suspicious by the usual heuristics. The names were plausible, the context was right, and in the huggingface-cli case the download count itself became false social proof — thousands of other people had “vetted” the package by making the same mistake. This is why the practitioners' guidance is to verify the publisher and the registration history, never the name or the popularity numbers.
That last example is the one that should reorganize your threat model. The installers weren't people. They were AI agents executing skill instructions — the same category of risk we dissected in the malicious-test-file supply chain incident. When agents install dependencies autonomously, the human checkpoint that might have paused at an unfamiliar package name isn't in the loop at all.
Why Does This Attack Target the Model Instead of the Developer?
Because the model is the more scalable victim. Human typos are random and personal; model hallucinations are systematic and shared. An attacker who registers one well-chosen hallucinated name isn't attacking one careless developer — they're attacking every user of every model that dreams that particular dream, simultaneously, indefinitely.
Andrew Nesbitt's analysis pushes the logic one step further, showing how slopsquatting composes with dependency confusion — the 2021 attack class Alex Birsan used to compromise more than 35 major companies. LLMs trained on leaked or public code learn the naming patterns of companies' internal packages, then hallucinate plausible variations of them. Attackers pre-register those variations publicly; when a developer asks an AI for help with internal tooling, the model recommends the attacker's public package in place of the private one. As Nesbitt puts it, the combination “inverts the discovery problem” — attackers spray, and the models do the targeting.
It can get worse from here, and honesty requires saying so: researchers note that adversarial techniques like retrieval poisoning could deliberately steer models toward hallucinating attacker-chosen names, and the commercial models' current 4x safety edge is an observation, not a guarantee — visible asymmetries attract attackers. This is also not just a “which model is safest” question. The same architectural lesson from credential attacks on AI coding agents applies: what the AI can reach determines the blast radius of what the AI gets wrong.
What's the Defense Stack for AI-Assisted Development?
None of this requires abandoning AI-assisted coding — it requires accepting that AI failure modes need their own controls. Here's the stack, in priority order:
| Layer | Control | What it stops |
|---|---|---|
| 1. Allow-list | Maintain an approved-dependency list; new packages require a human decision to enter it | Hallucinated packages entering the build at all |
| 2. Lockfile discipline | Commit lockfiles; install with exact pinned versions (npm ci, not ad-hoc installs); pin your registry | Silent introduction of new or swapped dependencies |
| 3. Existence & provenance check | Before any new dependency: verify it exists, check its age, publisher identity, and download history — not just the name | Freshly registered squats masquerading as established tools |
| 4. Scoped/private-first resolution | Use scoped namespaces for internal packages; configure resolution to prefer private registries | The slopsquatting-meets-dependency-confusion hybrid |
| 5. Agent install permissions | Autonomous coding agents don't get unattended install rights; dependency changes route through review | Agents pulling phantom packages with no human in the loop |
| 6. Verification gate before CI | Everything AI-authored passes automated dependency scanning and a human-owned review gate before merge | The residue the other five layers miss |
Ongoing monitoring belongs in the stack too, even though it didn't earn a numbered row: watch for unusual package installations in your environments, and keep threat intelligence on known slopsquatting campaigns flowing to whoever owns the dependency gate — several security vendors now track registered-hallucination packages specifically, and the unused-imports case shows these squats keep collecting victims for months after they're publicly identified.
Two implementation notes from the trenches. First, the provenance check is the highest-value habit per minute spent: a package that's three weeks old with one maintainer and no repository link is a red flag no matter how confidently your assistant recommended it — verify the publisher, not just the name. Second, the verification gate belongs in your pipeline architecturally, not as a policy memo. This is the same principle behind our resilience playbook for AI-generated code in production: controls that depend on everyone remembering to be careful eventually fail; controls built into the path to production don't.
If your team has been through an npm scare before, this list will look familiar — it extends the same hygiene we laid out in the Shai-Hulud worm action plan, with the new twist that the “user error” being exploited now belongs to the machine.
What This Means If Your Business Ships AI-Assisted Code
Here's our position, stated plainly: AI Employees and coding agents need guardrails designed for AI failure modes, not human ones. Spell-checkers, “are you sure?” dialogs, and registry typo-defenses were built for how people err. Models err differently — confidently, plausibly, and repeatably — and slopsquatting is simply the first attack class to industrialize that difference. It will not be the last.
For the Northeast Indiana businesses we work with — manufacturers with internal tooling, professional-services firms whose developers lean on Copilot, teams whose share of AI-assisted code is climbing toward that 40% mark — the practical takeaway fits in one sentence: if AI writes code that reaches your production systems, someone must own the dependency gate. That's a role, not a tool purchase. Our 5-check AI security audit covers where this gate fits among the other controls, and if you'd rather have it stood up than explained, Cloud Radix's security practice builds exactly these guardrails — allow-lists, provenance checks, and verification gates that assume the AI will eventually hallucinate, and make it boring when it does. Talk to us before your coding assistant's imagination becomes someone else's distribution channel.
Frequently Asked Questions
Q1.What is slopsquatting?
Slopsquatting is a supply-chain attack in which adversaries register software package names that AI coding assistants tend to hallucinate — plausible-sounding libraries that don't actually exist — and fill them with malicious code. When a developer or autonomous agent follows the AI's recommendation and installs the package, the malware enters the codebase directly. The term blends "AI slop" and "typosquatting."
Q2.How is slopsquatting different from typosquatting?
Typosquatting exploits human typing errors with lookalike names, and registries have mature defenses against near-miss spellings. Slopsquatting exploits AI hallucinations: the fake names are inventions, not misspellings, so spell-distance defenses never trigger. It also scales differently — one registered hallucination targets every user of every model that repeatedly generates that name.
Q3.How often do AI coding tools hallucinate packages?
USENIX Security 2025 research testing 16 models across 576,000 code samples found 19.7% of recommended packages didn't exist — 205,474 unique fake names. Commercial models averaged 5.2% hallucination rates versus 21.7% for open-source models, and 58% of hallucinated names recurred across repeated runs, which is what makes them predictable enough to attack.
Q4.Has anyone actually been attacked this way?
Yes. A researcher's placeholder for the commonly hallucinated huggingface-cli package drew over 30,000 authentic downloads in three months. The malicious npm package unused-imports was still receiving hundreds of weekly downloads in early 2026, and the hallucinated react-codeshift name spread through 237 GitHub repositories via AI-generated agent skills.
Q5.Are commercial AI models safe to use for coding, then?
Safer, not safe. A 5.2% average hallucination rate still means roughly one in twenty package recommendations may not exist, and researchers caution that adversarial techniques could deliberately increase hallucinations. Model choice reduces exposure; only process controls — allow-lists, lockfiles, provenance checks, and a review gate — actually close it.
Q6.What's the single most important defense for a small team?
A dependency allow-list combined with lockfile discipline: no new package enters the build without a human verifying it exists, checking its publisher and history, and deliberately approving it. It costs minutes per new dependency and blocks the entire attack class at the point of entry — including installs attempted by autonomous coding agents.
Q7.Where can a Northeast Indiana business get help defending against slopsquatting?
Start by assigning a named owner for the dependency gate — whether you're a Fort Wayne manufacturer with internal tooling or a professional-services firm whose developers use Copilot — then audit against the six-layer defense stack above. Cloud Radix, based in Auburn and serving Fort Wayne and Northeast Indiana, builds these controls as standing infrastructure: allow-lists, provenance checks, and CI verification gates designed for AI failure modes.
Sources & Further Reading
- VentureBeat: venturebeat.com/security/forget-typosquatting-slopsquatting — Forget typosquatting; slopsquatting is the software supply chain threat created by AI coding tools.
- USENIX Security 2025 / arXiv: arxiv.org/abs/2406.10279 — We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs.
- Socket: socket.dev/blog/slopsquatting-how-ai-hallucinations-are-fueling-a-new-class-of-supply-chain-attacks — The Rise of Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks.
- SecurityWeek: securityweek.com/ai-hallucinations-create-a-new-software-supply-chain-threat — AI Hallucinations Create a New Software Supply Chain Threat.
- Andrew Nesbitt: nesbitt.io/2025/12/10/slopsquatting-meets-dependency-confusion.html — Slopsquatting Meets Dependency Confusion.
- Aikido Security: aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks — Slopsquatting: The AI Package Hallucination Attack Already Happening.
Who Owns Your Dependency Gate?
If AI writes code that reaches your production systems, someone must own the gate it passes through. We build the allow-lists, provenance checks, and CI verification gates that assume the AI will eventually hallucinate — and make it boring when it does.
Schedule a Free ConsultationNo contracts. No pressure. Just an honest conversation about what would help your business.
