What is slopsquatting?
Engineering culture and software practice
Slopsquatting is a software supply-chain risk in which AI coding tools invent package or library names that do not exist, and attackers register those names so that anyone who trusts the generated code installs malicious software. The term was coined in 2025 by Seth Larson, the Python Software Foundation's security developer-in-residence, and popularised by Andrew Nesbitt. It is typosquatting's AI-era descendant: the human typo is replaced by an AI hallucination.
What this means
Modern software is assembled from thousands of small, reusable building blocks called packages, downloaded from public libraries. When an AI coding tool writes code, it sometimes confidently names a package that does not actually exist. That is a specific kind of AI hallucination.
Slopsquatting is the attack that exploits this. If a made-up package name keeps appearing in AI-generated code, an attacker can register that exact name in a public library and fill it with malicious code. The next person whose AI tool suggests the same name installs the attacker's package without realising anything is wrong.
The danger is trust. The developer trusts the AI, the tool trusts the library, and the install appears to work. Nothing looks broken, which is precisely why the pattern is effective and why it needed a name.
Why it matters
For a small organisation, the realistic scenario is mundane. A contractor or a staff member pastes in AI-generated code, it pulls in a package nobody has heard of, and it installs cleanly. The usual reassurance, that it installed and ran fine, is no defence at all, because a malicious package installs just as smoothly as a legitimate one.
The consequences can be serious: stolen credentials, a foothold in your systems, or malicious code running inside software your customers use. Because the entry point looks like an ordinary dependency, it can sit unnoticed.
The wider lesson reaches beyond code. AI tools invent plausible references of every kind: citations that do not exist, URLs that lead nowhere, package names for libraries that were never written. Slopsquatting is the case where that habit becomes a security hole, and it is a useful reminder to verify anything an AI confidently names before you rely on it.
As of September 2026 this is a recognised and researched risk rather than a hypothetical one, though the exact rates change as models improve. This article describes it defensively, at the level needed to recognise and prevent it, and contains no instructions for carrying it out.
How it works
Where the term came from
The term slopsquatting was coined in 2025 by Seth Larson, the Python Software Foundation's security developer-in-residence, and popularised by Andrew Nesbitt, who posted it publicly on the social network Mastodon in April 2025 and credited Larson for the name. It is a play on typosquatting, the long-established trick of registering names that mimic popular ones to catch human typing errors. The "slop" part points to the sloppy, hallucinated output of AI. Because the coining sat on social media, it is best treated as the primary origin fact and substantiated through the independent research and reporting below.
The scale of the underlying problem was measured in the peer-reviewed paper "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", by Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath and Murtuza Jadliwala, presented at the USENIX Security Symposium in 2025 and a distinguished paper award winner. Using 16 code-generating models and generating 576,000 code samples, the researchers found that 19.7 percent of recommended packages were hallucinations, with commercial models hallucinating at least 5.2 percent of the time and open-source models 21.7 percent, yielding 205,474 unique fictitious package names. A preprint of the work appeared on the arXiv repository in 2024. Government and security bodies issued guidance on AI-generated code and dependencies through 2025 and 2026, and the term has been used steadily in security press since, which is the evidence that it has stuck rather than faded.
How it works at the level of pattern
The pattern has four steps. An AI tool invents a package name that does not exist. The same name recurs, because these hallucinations are often repeatable rather than random: when the researchers reran 500 hallucination-triggering prompts ten times each, 43 percent of the hallucinated packages reappeared in all ten runs and 58 percent recurred more than once. An attacker registers that predictable name in a public library and puts malicious code inside it. And a developer who trusts the generated code installs it. The repeatability is what makes the attack worthwhile: the attacker can predict which invented names future users will be given. There was an early real-world signal of this dynamic in 2023, before the term existed, when a researcher uploaded a harmless package under a name that models kept hallucinating and watched it accumulate tens of thousands of downloads.
The defences
The defences are established supply-chain hygiene applied with fresh urgency. Verify that a package genuinely exists and has a real history, a maintainer and a track record, before trusting it. Use lockfiles and pinned versions so your software only installs the exact, known dependencies you approved. Prefer private registries and allowlists that limit what can be pulled in. Run dependency scanning tools that flag unknown or suspicious packages. Review the dependencies in AI-generated code specifically, not just the logic. And treat all generated code as untrusted input until a person has checked it. None of these is exotic; together they close the gap that slopsquatting relies on.
What it shares with older attacks
Slopsquatting sits alongside typosquatting, which preys on human misspellings, and dependency confusion, which tricks systems into fetching a malicious public package instead of an intended private one. All three exploit the same soft spot: software trusts names, and a name is easy to fake. The novelty is only in the source of the mistaken name, which is now an AI model rather than a human finger.
Examples
A professional services firm hires a contractor to build a small internal tool. The contractor uses an AI coding assistant, which suggests a handful of packages, one of which is invented. An attacker has registered that name. The tool installs and runs, and the malicious package quietly harvests credentials. The firm's mistake was accepting "it installed fine" as proof of safety. A dependency check against known, reputable packages would have caught the stranger.
A charity's volunteer builds a data tool with AI help and pushes it live the same day. Because there is no lockfile and no scanning, nobody notices that one dependency is a package registered only days earlier with no history. Had the volunteer been asked to confirm that each package existed with a real maintainer and track record, the newcomer would have stood out immediately.
A software team of eight uses AI tools daily but treats every generated dependency as suspect. Their build only installs pinned, approved versions, their scanner flags anything unknown, and a person reviews new dependencies before they are added. When an agent suggests a package nobody recognises, the process stops and someone checks. The same AI habit that endangered the others is, here, contained by ordinary discipline.
Common misunderstandings
The first misunderstanding is that slopsquatting is the same as an AI hallucination. It is not. A hallucination is the general phenomenon of an AI inventing something; slopsquatting is one specific, exploitable consequence of it, where the invented thing is a package name that an attacker can register. Unlike a hallucination in a piece of prose, this one has a direct security payload.
The second is that it is just typosquatting. Rather than relying on a human mistyping a name, slopsquatting relies on an AI inventing one, which means the "mistake" can be predicted and mass-produced.
The third is that a package installing without error means it is safe. Installing cleanly proves nothing; malicious packages install exactly as smoothly as legitimate ones.
The fourth is that this only affects large software companies. Any organisation whose contractors or staff paste AI-generated code is exposed, and smaller firms often have the least dependency checking in place.
The fifth is that it is unrelated to other AI errors. It is the security-critical member of a wider family that includes invented citations and invented URLs; the common thread is an AI confidently naming something that does not exist.
Risks and boundaries
This is a recent term, coined in 2025, and usage may still shift as of September 2026; this article was written in that month and may sit under the library's security theme at publication. The specific hallucination rates come from a particular study and a particular set of models, and they will change as models improve or regress, so the figures should be read as a snapshot rather than a constant.
The boundary worth stating is that slopsquatting names a narrow, real pattern, not every risk in AI-generated code. It is not the same as dependency version conflicts, which are a separate problem in the same territory, and it is not a reason to distrust all packages, only a reason to verify names before trusting them. The folklore risk runs in two directions: dismissing it as hype, when the underlying research is solid, or overstating it as a reason to avoid AI tools entirely, when ordinary supply-chain hygiene contains it. This article is deliberately defensive and conceptual, and includes no instructions for carrying the attack out.
What to do next
Make "it installed fine" an unacceptable answer. Require that every dependency, especially in AI-generated code, is confirmed to exist with a genuine history and maintainer before it is trusted.
Put basic supply-chain hygiene in place: lockfiles and pinned versions so only approved dependencies install, dependency scanning to flag unknowns, and, where practical, private registries or allowlists.
Ask any supplier that uses AI coding tools how they check the packages that generated code pulls in, who reviews new dependencies, and whether they scan for malicious ones. Treat an absence of process as a real risk.
Extend the habit of verification to all AI output. If a tool can invent a package name, it can invent a citation or a URL, so build a culture of checking anything an AI confidently names before relying on it.
FAQs
What is slopsquatting in plain terms?
It is when AI coding tools invent package names that do not exist, attackers register those names with malicious code, and developers who trust the AI install them.
Who coined the term?
Seth Larson, the Python Software Foundation's security developer-in-residence, coined it in 2025, and Andrew Nesbitt popularised it by posting it publicly and crediting Larson.
How common are the invented package names behind it?
A 2025 USENIX Security study found 19.7 percent of recommended packages were hallucinations, with over 205,000 unique fake names across 576,000 code samples from 16 models.
Why is an install succeeding not proof of safety?
Because a malicious package installs just as cleanly as a legitimate one. A successful install says nothing about whether the code is safe or trustworthy.
How is it different from typosquatting?
Typosquatting exploits human typing errors; slopsquatting exploits AI-invented names, which are repeatable and can be predicted and mass-registered by attackers.
How do we defend against it?
Verify packages exist and have a history, use lockfiles and pinned versions, scan dependencies, prefer private registries and allowlists, and review the dependencies in generated code.
Does this only matter for tech companies?
No. Any organisation whose staff or contractors use AI-generated code is exposed, and smaller firms often have the least checking in place.