In 2025, researchers from the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech ran 576,000-plus code-generation prompts through 16 large language models and published the results at USENIX Security under the title "We Have a Package for You!" The headline number: 19.7% of the packages those models recommended for pip install or npm install did not exist anywhere on a real registry. Commercial models did better — GPT-4 Turbo hallucinated at just 3.59%, with a commercial-model average around 5.2% — but open-source models averaged 21.7%, and CodeLlama's 7B and 34B variants topped 33%. The more unsettling finding wasn't the rate, though; it was the repeatability. Re-running identical prompts ten times reproduced the exact same hallucinated package name on every single run 43% of the time, and 58% of hallucinated names showed up more than once. That repeatability is what turned an annoying model quirk into an attack surface: if a name is predictable, an attacker can register it before a real developer ever asks their AI assistant for it. This post explains why LLMs hallucinate dependency names in the first place, how attackers are already weaponizing that behavior, and what to actually check before you let an AI-suggested package anywhere near a lockfile.
Why do LLMs hallucinate package names at all?
LLMs hallucinate package names because they generate text by predicting the statistically likely next token, not by querying PyPI or npm to confirm a name exists. A model trained on millions of GitHub files and Stack Overflow answers learns the shape of a plausible import statement — a name that looks like it belongs next to numpy or express — without any built-in mechanism to verify the name resolves to a real, published artifact. The USENIX researchers broke down exactly what these fabrications looked like: 51% were pure inventions with no real counterpart, 38% were conflations that blended two real package names into one plausible-sounding hybrid, and 13% were typo-like variants of an existing package. All three types come from the same root cause — the model is pattern-matching on naming conventions it has seen, not performing a lookup. This is structurally the same failure mode behind hallucinated API methods and function signatures: the model produces the syntax it has statistically learned to associate with a task, whether or not that exact symbol exists in the library's actual source.
What is slopsquatting, and how is it different from typosquatting?
Slopsquatting is a term coined in 2025 by Seth Larson, Developer-in-Residence at the Python Software Foundation, to describe attackers registering the exact package names that LLMs hallucinate, then loading them with malicious payloads and waiting for a developer or AI coding agent to install one. It differs from classic typosquatting in a meaningful way: a typosquat bets on a human fat-fingering reqeusts instead of requests — a misspelling of something real. A slopsquat targets a name an AI model invented from whole cloth, one that no developer would type from memory but that an AI assistant will confidently suggest and an agent may install without a human ever reading the name at all. Because the USENIX study showed the same hallucinated names recur across repeated prompts, an attacker doesn't need to guess blindly — they can run the same models the rest of the industry uses, harvest the repeatable hallucinations, and pre-register the highest-probability names before anyone else does.
Has slopsquatting actually happened, or is it theoretical?
It has moved past theory into demonstrated proof-of-concept, which is different from confirming a large-scale malicious campaign has already succeeded in the wild. Security researchers have registered hallucinated package names as empty, harmless placeholder packages specifically to measure how often real users would install them — and documented meaningful download counts within weeks, showing the exploitation path is real and low-effort for anyone willing to publish a malicious payload instead of an empty one. The mechanics require no novel tooling: register the name on PyPI or npm before anyone else does, publish a package that does something harmful on install (a post-install script is enough), and wait for AI-assisted developers or autonomous coding agents to run pip install or npm install on a name their assistant just suggested. The attack is cheap because registry namespaces are first-come, first-served and free to claim, and the target list is effectively published for free every time a researcher documents which names a given model hallucinates.
How do you verify an AI-suggested dependency before installing it?
Verification starts with treating every AI-suggested package name as unverified input, not a trusted recommendation, and checking it against the registry directly rather than trusting that the model's confident tone implies the package exists. At minimum: confirm the package is actually listed on PyPI, npm, or the relevant registry; check its publish history for a plausible maintainer track record rather than a single recent release; and look at whether it has a real repository URL, meaningful download counts predating the AI tool that suggested it, and a version history that looks organic rather than a single version dropped yesterday. Pin exact versions in a lockfile so a future npm install can't silently resolve to a different, newly-registered package under the same name. Where possible, route installs through a curated or allow-listed registry for AI-assisted workflows rather than resolving directly against the public index, and treat install-time scanning as a required gate rather than an optional nicety — the entire point of slopsquatting is that the malicious payload runs the moment the install completes, before a code review would ever catch it.
How Safeguard Helps
Slopsquatting's signature — a never-before-seen package name, no repository URL, an aggressive or unusual versioning pattern, or a name sitting suspiciously close to a well-known library — is exactly what Safeguard's Eagle classification model is built to catch. Eagle scores every artifact across indicator classes including metadata anomalies (newly-published package, no repo URL, unusual author history) and typosquat similarity (name within edit-distance 2 of a top-1000 package owned by a different publisher), and it covers PyPI and npm on every publish with retroactive historical scanning. That means a hallucinated name an attacker just registered doesn't need to have been previously identified as malicious to get flagged — the metadata pattern alone raises its score. Enforcement happens before the install completes: the built-in "Typosquat detected" guardrail blocks any package within edit-distance 2 of a known name that isn't owned by the expected publisher, and the Gold Registry admits nothing that Eagle scores above 30, giving AI-assisted workflows a curated resolution path instead of a direct line to the public index. Combined, that's a verification layer sitting exactly where slopsquatting is designed to slip through — the moment between an AI assistant suggesting a name and a developer or agent typing install.