Slopsquatting: When Your AI Coding Assistant Invents a Package Name and an Attacker Is Waiting
Here’s a moment every developer using an AI assistant has lived through: you ask it to solve something, it fires back a clean block of code, and right at the top is an import or an npm install for a library you’ve never heard of. It sounds right — aws-helper-sdk, fastapi-middleware, something perfectly plausible. So you run it. And most of the time, nothing bad happens. But sometimes that package name is one the AI simply made up — and someone was betting you’d run it anyway.
That bet has a name now: slopsquatting. It’s a supply-chain attack built entirely on the fact that AI models confidently invent software packages that don’t exist. Attackers register the invented names on public registries like npm and PyPI, fill them with malicious code, and wait. It’s clever, it’s cheap, and it’s far more predictable than you’d hope. Let’s break down exactly how it works and, more importantly, how to make sure it never lands in your project.
First, the weird part: AI invents packages that don’t exist
Large language models don’t look things up when they generate code — they predict what looks like a correct answer based on patterns. Usually that prediction is spot-on. But when a model isn’t sure which library does the job, it doesn’t stop and say “I don’t know.” It generates a name that fits the pattern of a real package, complete with a confident install command. This is called package hallucination, and it’s the same underlying behavior we’ve covered before in why a clear spec beats firing off a vague prompt: the less certain the model is about your intent, the more it improvises.
On its own, a hallucinated package name is just an annoying error — you try to install it, it 404s, you move on. The problem is what happens when someone gets there first.
How slopsquatting turns a typo-free mistake into an attack
The name borrows from typosquatting — the old trick of registering reqeusts to catch people who fat-finger requests. Slopsquatting is the AI-era mutation of that idea, and it’s more dangerous for one simple reason: it isn’t triggered by your typo, it’s triggered by the machine’s confident suggestion. The chain looks like this:
- The model hallucinates a package name when answering coding questions — a name that doesn’t exist on the registry.
- An attacker harvests these names by running common prompts through popular models and collecting the fakes that come back.
- They register the name for real on npm, PyPI, or a similar registry, and publish a package containing malicious code — a credential stealer, a backdoor, a crypto miner.
- You (or your AI agent) run the install from a code snippet, and this time it works. The package installs cleanly. So does the payload.
The gut-punch is the last step. Because the name now resolves to a real package, nothing looks broken. No error, no warning — just a dependency you didn’t vet, running with the same trust as everything else in your project. It’s the same class of problem as the GhostApproval flaw we looked at, where the danger hides inside a step you were trained to click straight through.
The part that should worry you: it’s predictable
You might assume hallucinated names are random noise — a different fake every time, impossible to plan around. If that were true, slopsquatting would barely be worth an attacker’s effort. It isn’t true, and that’s the whole problem.
Researchers at the Cloud Security Alliance ran the same coding prompts through models ten times each and watched what came back. The results are stark: 43% of hallucinated package names showed up on every single run, and 58% reappeared on more than one run. Only a minority were one-off flukes. In other words, a given model tends to hallucinate the same fake names over and over.
That consistency is exactly what an attacker needs. They don’t have to guess — they can map which fakes a popular model reliably produces, register that short list, and know that a steady trickle of developers will be handed those names for months. Predictable hallucination is a stable, harvestable target. That’s what elevates this from a curiosity to a real supply-chain threat.
How to protect yourself: verify before you install
The good news is that the defense is refreshingly low-tech. You don’t need a new tool or a security team — you need one habit: never install a package an AI names without confirming it’s real and reputable first. Here’s the practical checklist.
- Look up every unfamiliar package on the actual registry. Before running the install, open the package’s page on PyPI or npm directly. Does it exist? How many downloads does it have — thousands and steady, or eleven and all from last Tuesday? Who maintains it, and does it link to a real source repository with real history?
- Treat brand-new, low-download packages as guilty until proven innocent. A legit library that solves a common problem has a track record. A package registered three weeks ago with no stars, no history, and a name that sounds a little too convenient is the exact shape of a slopsquatting trap.
- Don’t blind-run AI-generated shell commands. The riskiest move is copy-pasting an entire
pip install ...ornpm install ...line straight from a chat window into your terminal. Read what it’s installing first — the same care you’d take with any code from a stranger, because that’s effectively what it is. - Pin and lock your dependencies. Use lockfiles and pinned versions so your builds pull the exact packages you’ve already vetted, not whatever resolves at install time. This also stops a compromised update from sliding in silently later.
- Use a private registry or allowlist for real projects. On a team, route installs through an internal proxy or approved-package allowlist so a hallucinated name can’t even be fetched from the public internet without review.
- Keep a human in the loop on autonomous agents. If you’re letting an AI agent install its own dependencies — like the terminal-driving agents we covered with Goose — that’s precisely where an unverified install can happen with nobody watching. Gate dependency changes behind a human review step.
Run through that list and slopsquatting basically stops working on you. Every step is aimed at the single weak point the attack depends on: a human (or agent) trusting a name without checking whether the thing behind it is real.
The bigger lesson for coding with AI
Slopsquatting isn’t a reason to stop using AI coding assistants — they’re too useful, and this is a solvable problem. It’s a reminder of what these tools actually are: brilliant, fast pattern-generators that do not know the difference between a real library and a plausible-sounding one. They aren’t lying to you; they genuinely can’t tell. The confidence is the same whether the answer is right or invented.
So the working relationship is simple. Let the AI write the draft, suggest the approach, and save you the boilerplate — that’s where it shines. But the moment its output reaches out and touches the real world — installing a package, running a command, hitting a URL — that’s your job to verify. Trust the speed. Check the facts. Do that consistently and you get the best of the tool without inheriting its blind spots.
Frequently asked questions
What is slopsquatting? It’s a software supply-chain attack where criminals register software package names that AI models hallucinate — invent — in generated code. When a developer trusts the AI’s suggestion and installs the package, they get the attacker’s malicious code instead of a legitimate library.
How is it different from typosquatting? Typosquatting preys on human typos (registering reqeusts to catch people misspelling requests). Slopsquatting preys on AI hallucinations — the fake name comes from the machine’s confident suggestion, not your mistake, which is why it slips past people who type carefully.
Why is it considered predictable? Studies found that a large share of hallucinated package names repeat across multiple runs of the same prompt — in Cloud Security Alliance testing, 43% reappeared on every run. Because models tend to hallucinate the same names consistently, attackers can identify and pre-register them.
How do I protect my projects? Verify every unfamiliar package on the real registry before installing, distrust brand-new low-download packages, never blind-run AI-generated install commands, pin dependencies with lockfiles, and keep a human review step on any autonomous coding agent that installs its own dependencies.
The takeaway
Slopsquatting works because of a very human reflex: an assistant we trust hands us a name, it sounds right, and we run it. The whole attack lives in that half-second of unearned trust. Close that gap — glance at the registry, distrust the too-new package, read the install line before you paste it — and the entire scheme falls apart. AI can write your code faster than ever. It just can’t be the one that decides what’s safe to run. That part is still, thankfully, up to you.
Sources & further reading:
- Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks (Cloud Security Alliance)
- Phantom Squatting: AI-Hallucinated Domains as a Software Supply Chain Vector (Palo Alto Unit 42)
Related Reading
- Your AI Coding Assistant Can Be Tricked: The GhostApproval Flaw and How to Code Safely with AI
- AI Slop Is Taking Over Your Feed: How to Spot It, and the New Tools Fighting Back
- An AI Just Hacked Three Real Companies During a Test — What It Actually Means for You