Slopsquatting is a supply chain attack that exploits a quirk of large language models: when asked to write code, AI coding assistants frequently invent package names that sound plausible but don't exist. So what is slopsquatting, exactly? It's the practice of registering those hallucinated names on public registries like PyPI or npm, so that when a developer copies AI-generated code and runs pip install or npm install, they pull down an attacker-controlled package instead of hitting an error. The term blends "slop" (low-quality AI-generated output) with "typosquatting," but the mechanics differ in an important way: there's no typo involved, only a confident wrong answer from a model. Because hallucinated names repeat across sessions, prompts, and even across different LLMs, attackers can predict which fake names are worth squatting on before a single victim ever copy-pastes the code. It's a purely AI-native twist on an old dependency-confusion problem.
What is slopsquatting and how is it different from typosquatting?
Slopsquatting is registering a non-existent package name that an AI model hallucinated, while typosquatting is registering a misspelled variant of a real, already-popular package (reqeusts instead of requests). Typosquatting relies on human error — a developer fat-fingering a package name during manual install. Slopsquatting relies on model error: the LLM itself generates an import statement or an install command referencing a library that was never published, often because the name is a plausible-sounding blend of real package naming conventions (combining a known framework with a common utility suffix, like torch-utils-pro or aws-lambda-toolkit). The developer trusts the AI's output, runs the install command as-is, and never questions whether the package exists — there's no misspelling to catch on a second glance, which makes this category of AI hallucinated package attack harder to spot through visual review alone.
Why do AI coding assistants hallucinate package names?
AI coding assistants hallucinate package names because LLMs generate the statistically most probable next token, not a verified fact, and package names sit outside what the model can ground-truth at inference time. A 2024 academic study by Spracklen et al., "We Have a Package for You," tested 16 popular code-generating models — including both commercial and open-source LLMs — across roughly 576,000 generated code samples and found more than 205,000 unique hallucinated package references. Commercial models hallucinated packages in about 5.2% of outputs; open-source models did so in 21.7%. Worse, the hallucinations weren't random noise: when researchers re-ran the same prompts, a substantial share of the same fake LLM generated package names reappeared consistently, meaning an attacker only needs to query popular coding models a handful of times to build a reliable target list of names to squat on.
How does a slopsquatting supply chain risk actually play out in practice?
The slopsquatting supply chain risk plays out when an attacker registers a hallucinated name on a public registry before anyone else does, then waits for organic downloads driven by AI-assisted developers rather than by any active phishing or social engineering. Security researcher Bar Lanyado demonstrated this in a widely cited 2024 proof of concept: after collecting package names that ChatGPT and other models repeatedly hallucinated in response to coding questions, he published a harmless dummy package under one of those names, huggingface-cli. Within three months it had racked up more than 30,000 downloads, and — notably — a large enterprise's internal repository instructions referenced installing it, apparently copied straight from AI-generated guidance without verification. A malicious actor doing the same thing would simply swap the dummy payload for a credential stealer, a cryptominer, or a backdoor, and the infection vector would look, from the developer's side, exactly like a routine pip install.
What makes this attack hard to catch with traditional tooling?
Traditional tooling struggles with slopsquatting because most dependency scanners check for known-bad packages, license issues, or CVEs in already-cataloged libraries — they aren't built to flag a package purely because it's new, obscure, and was suggested by an AI assistant rather than chosen deliberately by a human engineer. A newly published package with zero prior reputation, a generic-sounding name, and no red flags in its metadata can sail through a standard SCA (software composition analysis) scan on day one, because there's nothing in a CVE database yet — the package might be hours old. Code review doesn't reliably catch it either, since reviewers are trained to scrutinize logic changes, not to verify that every dependency listed in a pull request actually corresponds to a legitimate, long-standing project. The AI coding assistant package risk compounds further in fast-moving teams that lean on Copilot, Cursor, or similar tools to scaffold entire services, where dozens of dependencies can be introduced in a single AI-assisted session without a human ever independently confirming each one exists as claimed.
How can development teams reduce their exposure to slopsquatting?
Development teams reduce slopsquatting exposure primarily by verifying package provenance before install rather than after, rather than trusting AI-suggested dependency names at face value. Practical steps include pinning dependencies to specific, previously-vetted versions instead of accepting whatever an AI assistant types in a code snippet; checking registry metadata such as publish date, maintainer history, and download counts for any package that's unfamiliar; and routing AI-assisted code through the same dependency-approval workflow as any other new library, no exceptions for "the AI suggested it." Some teams also fine-tune internal coding assistants or apply retrieval-augmented generation against an approved internal package index, so the model is grounded in what actually exists in the organization's ecosystem rather than free-associating from its training data. None of these steps are exotic — they're the same supply chain hygiene practices that already apply to human-introduced dependencies — but they need to be applied consistently to AI-generated code, which too often gets a pass because it "looks" complete and confident.
How Safeguard Helps
Safeguard closes the gap that slopsquatting depends on: the assumption that a package name appearing in code — human-written or AI-generated — can be trusted by default. Safeguard continuously analyzes dependencies introduced anywhere in your software supply chain, flagging packages with suspicious characteristics common to slopsquatting targets, such as very recent publish dates, thin or nonexistent maintainer history, low adoption relative to how confidently they're referenced in code, and naming patterns that closely mirror well-known libraries without their track record. Because Safeguard evaluates provenance and reputation signals rather than only matching against known-malware databases, it can catch a freshly squatted package before it accumulates the CVE history that legacy scanners wait for. For teams leaning heavily on AI coding assistants, Safeguard integrates into CI/CD and pull request workflows so that every newly introduced dependency — however it was suggested — is checked against the same supply chain risk criteria, turning "the AI told me to install it" from a blind trust decision into a verified one.