Here’s a question worth sitting with: when your AI coding agent suggests pip install some-helper-lib, do you check whether that package actually exists before the install command runs? Or does the agent just run it?
If you’re being honest, the agent probably runs it. That’s the whole point of agentic coding — you stopped babysitting every command months ago. And that gap, between “the model suggested a package” and “the package is real and safe,” is exactly where slopsquatting lives.
The term was coined by Seth Larson, the Python Software Foundation’s developer-in-residence, and it spread fast after Andrew Nesbitt popularized it on Mastodon in April 2025. The idea is simple enough to be unsettling: LLMs hallucinate package names that don’t exist, attackers register those names with malware attached, and your agent installs them on the next prompt. No typo required. No phishing. The model does the social engineering for you.
Slopsquatting is not typosquatting wearing a new hat
People keep collapsing these two into one bucket, and that’s a mistake because the defenses differ.
Typosquatting bets on human fingers slipping. You meant to type requests, you typed reqeusts, and someone parked malware on the misspelling. It’s an attack on your motor skills. The fix is mostly attention — read what you typed.
Slopsquatting bets on machine confidence. The LLM doesn’t slip; it confidently invents a name that sounds completely plausible — python-json-logger-utils, fastapi-auth-middleware, something that fits the shape of real package names so well you’d never blink. You didn’t mistype anything. The model handed you a fake and presented it as fact, and your agent acted on it.
That difference matters because “be careful when you type” does nothing here. You weren’t typing. The suggestion arrived pre-formed, wrapped in the same authoritative tone the model uses for correct answers.
Why this actually works at scale
The scary part isn’t that models hallucinate packages occasionally. It’s how often and how consistently they do it.
The foundational research here is a USENIX Security 2025 paper with the cheerfully ominous title “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs.” The researchers ran over 576,000 code samples across 16 different models. On average, 19.7% of the packages those models recommended did not exist — which worked out to roughly 205,000 unique hallucinated package names.
A fifth of suggested packages, fabricated. Across hundreds of thousands of samples.
It’s not evenly spread, though. Commercial models behaved noticeably better — averaging around 5.2% hallucination rates, with GPT-4 Turbo coming in near 3.59%. Open-source models were the problem children, averaging about 21.7%, with CodeLlama hallucinating more than a third of its package suggestions. So if your agent is wired to a self-hosted open-weight model to save on tokens, your exposure is meaningfully higher than someone running a frontier commercial model.
Now the detail that turns a curiosity into an attack surface: 43% of hallucinated packages showed up again when the same prompt was rerun. Hallucination isn’t random noise. Feed a model a similar request and it tends to invent the same fake name repeatedly. That predictability is everything for an attacker. They don’t need to guess — they can run the popular models against common prompts, harvest the recurring fake names, and pre-register the ones that keep coming back. The model becomes a reliable distribution channel pointing at packages the attacker now controls.
Has anyone actually been hit?
I want to be straight with you here, because the vendor blogs get breathless about this and the reality is more nuanced.
As of early 2026, there’s no publicly confirmed, attributed in-the-wild slopsquatting attack that caused real damage. If you read a post claiming some named incident wiped out hundreds of repos, treat it with skepticism until there’s a credible writeup behind it — a lot of the “incidents” floating around are extrapolations or proof-of-concepts dressed up as breaches.
What we do have is a proof-of-concept that should remove any doubt about feasibility. A security researcher registered a package matching a name that models kept hallucinating — huggingface-cli — and it pulled in over 30,000 downloads in roughly three months. That wasn’t malware; it was a researcher making a point. But it proves the pipeline works end to end: model hallucinates a name, the name gets registered, real developers and their tooling install it at scale without anyone noticing.
So the honest framing is this. The barrier to entry is effectively zero — registering a package on npm or PyPI is free and takes minutes. The mechanism is proven. The only reason we’re not drowning in confirmed cases is timing, and “we haven’t seen the big one yet” is not a security posture I’d want to defend to anyone.
Where your team is actually exposed
The threat isn’t abstract “AI.” It’s specific workflows. Walk through your own setup and see which of these apply.
Agents that auto-run install commands. This is the sharp end. If Claude Code, Cursor’s agent mode, or any autonomous coding tool can execute npm install or pip install without you eyeballing the package name first, a hallucinated name goes straight to a registry fetch. No human in the loop, no chance to catch it.
Copy-pasted setup instructions. The model writes you a README or a “getting started” block with five install commands. You paste the whole thing into your terminal because reading five package names is boring. One of them is invented.
Agent skill and config files. As people share agent configurations, skill definitions, and .mdc-style instruction files, those files reference dependencies too. A hallucinated package baked into a popular shared config propagates to everyone who adopts it.
Dockerfiles and CI scripts the model generated. A fake package name in a RUN pip install line sits dormant until the next build, then quietly resolves against whatever an attacker registered in the meantime. The build still goes green.
The common thread: every one of these removes the moment where a human looks at a package name and thinks “wait, is that real?” Agentic workflows are valuable precisely because they remove that friction. Which means the friction has to move somewhere else — into tooling and policy.
Defenses that actually hold up
Plenty of advice on this topic amounts to “be careful.” Useless. You adopted agents to stop being careful about routine things. Here’s what genuinely shifts the risk, roughly in order of payoff.
Pin everything, with hashes
Lockfiles are your floor. If a dependency isn’t already in your lockfile with a known-good hash, it shouldn’t install. This single control neutralizes most slopsquatting, because a freshly hallucinated package by definition isn’t in your existing lockfile.
For npm, use npm ci in CI instead of npm install. npm ci installs strictly from package-lock.json and fails if anything drifts — it won’t happily resolve a new name the way npm install does.
For Python, generate a fully pinned, hashed requirements file with pip-compile (from pip-tools) and install with hash verification:
pip-compile --generate-hashes requirements.in
pip install --require-hashes -r requirements.txtWith --require-hashes, pip refuses to install anything whose hash you haven’t recorded. A hallucinated package has no entry, so the install dies instead of fetching attacker-controlled code.
Add a version cooldown
Set a release-age cooldown so brand-new package versions can’t reach your builds automatically. Most malicious packages get caught and pulled within days. If your policy is “nothing newer than 7 to 14 days old enters the build,” you sidestep the window when a freshly registered slopsquat is most dangerous and least scrutinized. It’s a blunt instrument, but it’s a remarkably effective one.
Turn off install scripts by default
A huge share of supply-chain damage happens during install, via lifecycle scripts that execute the moment a package lands. Install with --ignore-scripts and explicitly allowlist the handful of packages that legitimately need a build step — pnpm’s allowBuilds or LavaMoat’s allow-scripts handle this cleanly. A hallucinated package that can’t run its postinstall hook is far less able to steal your environment variables.
Lock the build network down
If your build environment can only reach a known allowlist of domains, a malicious package that does sneak in can’t exfiltrate anything. A credential stealer that can’t make outbound requests to an unknown host is mostly inert. This is the control that limits blast radius when the earlier layers fail.
Give your agent a “verify before install” rule
This is the one specific to the AI angle, and it’s underused. Most agents let you set standing instructions. Add an explicit policy: before running any install command, confirm each package exists on the official registry and has a plausible download history and age; never install a package you can’t verify; surface any unverifiable package to me instead of installing it.
It’s not bulletproof — the same model that hallucinated the name is now being asked to check it — but a registry-existence check is a factual lookup, not a generative guess, and it catches the obvious fabrications. Pair it with the lockfile discipline above; the agent rule is the cheap first filter, the lockfile is the wall behind it.
Where the tooling fits, and what it misses
You’ll see vendors pitch this as a solved problem if you just buy their scanner. It’s not that simple.
Software composition analysis and dependency-security platforms — the Socket, Snyk, Aikido, Endor Labs class of tools I compared earlier — genuinely help. Several now flag packages that are suspiciously new, have near-zero download history, or match known-hallucinated names, and some can block an install at the package-manager level before code lands. A package firewall sitting between your developers and the public registry is a real layer.
What these tools miss is the moment before the package exists in your dependency graph. If your agent invents a name and an attacker registered it last week with clean-looking metadata, a scanner checking against known-bad lists may wave it through — there’s nothing “known bad” about a package nobody has flagged yet. Reputation and age heuristics help, but a patient attacker can age a package to look established before weaponizing it. Tooling raises the cost of the attack; it doesn’t reduce it to zero. The deterministic controls — lockfiles, hashes, cooldowns — are what catch the case the scanner hasn’t learned about.
And don’t forget secrets hygiene underneath all this. If a malicious package does run, what it can steal depends on what’s lying around in your environment. Keeping credentials out of plaintext env files and in a proper secrets manager limits what a successful slopsquat walks away with.
The checklist
If you want one thing to paste into your team’s security doc, here it is:
npm ci/pip install --require-hashesin CI — never barenpm installor unpinnedpip install- Fully pinned lockfiles with hashes, committed and enforced
- Release-age cooldown of 7–14 days on new dependency versions
--ignore-scriptsby default, with an explicit build allowlist- Outbound network allowlist on build/CI runners
- A standing agent instruction to verify package existence before any install, and to surface anything unverifiable
- An SCA tool or package firewall as a backstop — not the primary defense
- Secrets in a manager, not in
.envfiles the build can read
None of these are exotic. They’re the same supply-chain hygiene that mattered before AI agents existed. What changed is the volume and the predictability of bad package names entering the funnel — your agent now generates attack surface at a rate no human typo ever could.
Spend ten minutes this week on one experiment: ask your usual coding agent to scaffold a small project in a language you don’t use often, then check every package it suggested against the actual registry. Count how many are real. Whatever number you get, that’s your honest baseline — and probably the most convincing argument you’ll find for turning on the lockfile enforcement you’ve been meaning to get to.