Code-generating LLMs suggest npm install or pip
install commands as part of their answers. A May 2025 USENIX
Security study, "We Have a Package for You! A Comprehensive Analysis of
Package Hallucinations by Code Generating LLMs," tested 16 models and
found that 19.7% of the packages they recommended did not exist at
all — 21.7% for open-source models versus 5.2% for proprietary
ones — and collected more than 205,000 unique hallucinated package names
across the study. That is not a rare edge case; it is roughly one in five
suggestions from the weaker end of that range.
An attacker who wants to distribute malware does not need to guess at random: they can generate code with the same class of models, collect the names those models hallucinate, and register the most repeated ones on the real registry ahead of time. The next developer who pastes the AI's suggested install command gets the attacker's package instead of an install error. Security researcher Andrew Nesbitt and later researchers named this slopsquatting — a play on typosquatting, where the "typo" is one the model made for you.
| Case | Date | What happened |
|---|---|---|
| huggingface-cli | 2023 | Security researcher Bar Lanyado registered a package under a name he had seen an LLM hallucinate and published it empty, as a proof of concept. It was downloaded more than 30,000 times in three months, and the same hallucinated name turned up inside an Alibaba research repository's own README. |
| PhantomRaven campaign | flagged October 2025 (active since November 2022) | Koi Security and DCODX documented 100+ malicious npm packages distributed under slopsquatted and typosquatted names; CrowdStrike assessed the malware itself was written with the help of an LLM. The packages stole authentication tokens, CI/CD secrets, and GitHub credentials. |
A package-lock.json pins a name and version that already
resolved successfully once. That tells you nothing about how the name got
there in the first place — it is equally consistent with "this was always
a real, well-known package" and with "an AI hallucinated this name, an
attacker had already squatted it by the time someone ran npm
install, and the lockfile faithfully recorded the attacker's
package as if it were the intended one." The moment that actually matters
is the first install of a newly added dependency, before it is
ever committed — which is also the one moment a lockfile, by definition,
cannot yet describe.
Two independent, narrow checks, neither of which needs to trust a model to grade its own homework:
node cli.mjs package.json # both checks, one read-only request per dependency node cli.mjs package.json --strict # also fail CI on a suspiciously new (but real) name
Get the free browser check and CLI — Node 18+, zero dependencies, MIT licensed. See also how this compares to Socket, an ongoing registry-aware scanning service, and how this compares to reading package.json by hand.
Only until someone registers the name. The risk window is between an AI assistant hallucinating a name and an attacker claiming it -- before that, install fails loudly and safely; after it, install succeeds quietly against the attacker's package, and nothing about the failure you would have expected ever happens.
A lockfile records a name and version that already resolved once, which means either it was always a real package, or it was a hallucinated name that had already been squatted by the time someone ran install and committed the lockfile -- a lockfile cannot tell those two apart after the fact. The moment that matters is the first install of a newly added name, before it is ever committed.
Some tools do, and it helps, but it relies on the same model that hallucinated the name to also catch its own mistake, which the USENIX study's own numbers argue against relying on alone. A check against the registry itself does not depend on the model being right twice.