Slopsquatting: How AI-Hallucinated Packages Became a Supply Chain Attack

Slopsquatting runs in three steps, and none of them require the attacker to compromise anything that already exists.

First, reconnaissance. The attacker queries one or more LLMs with common coding prompts, the kind a developer would actually ask (build a REST client, parse a CSV, connect to Redis) and records which package names the model recommends that do not correspond to anything actually published on PyPI or npm. The USENIX researchers categorized how these hallucinated names arise: some are pure fabrications with no real analog, some are typo-like variants of a real package, and a large share are conflations, where two real, similarly-purposed packages get merged into a plausible-sounding name that matches neither. Socket's own 2026 research on five frontier models (Claude, Gemini, DeepSeek, and GPT variants, tested in April 2026 against 199,845 code responses) found 127 hallucinated names shared across all five models it tested, meaning the same fabricated name showed up regardless of which AI assistant a developer happened to be using. After PyPI's and Socket's own security review filtered out names that were already claimed or flagged, 53 of those shared names, 41 on PyPI and 12 on npm, remained available for anyone to register.

Second, registration. The attacker claims the hallucinated name on the relevant registry and publishes a package designed to look legitimate enough to survive a glance: a working facade that does something plausible, wrapped around a payload that runs on install. Because the name is not a typo of anything (a human proofreading a requirements.txt file has nothing to catch), and because it did not arrive through a phishing email or a suspicious link, it slips past the review habits most teams have actually built.

Third, distribution, and this is the part slopsquatting does not need to build itself. Every developer, and every AI coding agent, that asks a similar question later gets served the same hallucinated recommendation, because the underlying behavior that produced it in the model has not changed. The attacker does not have to advertise the malicious package or trick anyone individually; the LLM does the recommending for them, repeatedly, for free, to anyone who asks a similar enough question.

Two separate studies, run about a year apart, give a reasonably solid picture of how often this actually happens and whether it is getting better or worse.

The USENIX Security 2025 paper by Spracklen and colleagues remains the most rigorous public dataset. It tested 16 code-generating models, both commercial and open source, across 576,000 generated code samples and found an average hallucination rate of 19.7% for recommended package names. The gap between model classes was large: commercial models clustered around 5%, while open source models averaged closer to 21%. The study also found that 8.7% of hallucinated names invented in a Python context turned out to be real, valid JavaScript packages instead, a specific conflation pattern worth knowing about because it means a name flagged as "not real for this language" is not automatically safe to dismiss.

Socket's April 2026 follow-up, run by researcher Aleksandr Churilov against five current frontier models (Claude Haiku 4.5 and Sonnet 4.6, Gemini 2.5 Pro, DeepSeek V3.2, and GPT-5.4-mini) across 199,845 responses, found materially lower per-model rates, ranging from 4.62% to 6.10%. That is a real improvement over the 2025 baseline, consistent with model providers tightening up on code generation accuracy generally. But the more useful finding for defenders was not the raw rate, it was the overlap: 127 hallucinated names were shared across all five models tested, and after PyPI and Socket's own review removed names that were already registered or already flagged as suspicious, 53 names (41 on PyPI, 12 on npm) remained genuinely available for anyone to claim. Socket's own writeup is explicit that this is an exposure finding, not a confirmed attack: there is no evidence in that study that any of the 53 available names had actually been registered maliciously at the time of publication.

That distinction matters for how a team should read this whole topic. The hallucination rate has come down since 2025, and the frontier-model study found no confirmed malicious registrations among the names it surfaced. What has not come down is the predictability: names that repeat across models and across queries are, by definition, the ones worth squatting on, and that predictability does not go away just because the raw percentage does.

Slopsquatting has moved from a theoretical risk to a documented pattern in stages, and it is worth being precise about which cases were proof-of-concept research and which were confirmed malicious campaigns, because the two get conflated often in coverage of this topic.

The earliest and best-documented case is huggingface-cli on PyPI. In late 2023, security researcher Bar Lanyado noticed that AI coding assistants repeatedly recommended installing a package called huggingface-cli, when the actual Hugging Face command-line tool installs as part of the huggingface_hub package with a bracketed extra. Lanyado registered the hallucinated name himself and published a deliberately harmless package to test whether the phenomenon had real reach. It did: the package logged more than 30,000 authentic downloads over roughly three months, and Alibaba's GraphTranslator project ended up referencing the hallucinated install command directly in its own public README, having apparently copied it from an AI-generated suggestion without checking it against the real package. This was reported independently by The Register, Slashdot, and InfoWorld at the time, and it remains the clearest evidence that a hallucinated name can achieve real, sustained developer trust with zero attacker outreach.

A more recent case is react-codeshift on npm. In January 2026, Aikido Security researcher Charlie Eriksen found that AI coding assistants were hallucinating this name as a conflation of two real packages, jscodeshift and react-codemod, and that the hallucinated name had already propagated into 237 GitHub repositories through AI-generated agent skills that invoked it directly via npx, with no human necessarily reading the command before it ran. Eriksen registered the name himself as a proof of concept before an actual attacker could, which means, like huggingface-cli, this case demonstrates reach and plausibility rather than a confirmed live compromise. What makes it a meaningfully different data point than huggingface-cli is the delivery mechanism: the hallucinated name was not copy-pasted by a human from a chat window, it was executed automatically by agentic tooling acting on the model's suggestion.

A separate npm package, unused-imports, is reported as a confirmed malicious registration rather than a research proof of concept: it mimics the real eslint-plugin-unused-imports, a name pattern AI assistants are documented to confuse, and researchers at ReversingLabs have linked the campaign to the North Korea-attributed threat group tracked as Famous Chollima. As of early February 2026 it was still recording roughly 233 weekly downloads despite npm security-holding it. Because this attribution comes from third-party threat intelligence reporting rather than a primary source this article independently verified in full, treat the specific attacker attribution as reported rather than confirmed, while the existence of a malicious package targeting that naming confusion is well documented across multiple outlets.

None of this is the same incident as the March 2026 LiteLLM PyPI compromise, and it is worth being explicit about why. That attack, covered in full in our LiteLLM supply chain attack writeup, involved threat actor TeamPCP compromising the real, legitimate LiteLLM package's publishing pipeline (by first breaching Aqua Security's Trivy scanner and using stolen tokens to push malicious LiteLLM releases) rather than registering a name an AI model hallucinated. It is a different supply chain vector: a trusted, already-popular package's build and release process was hijacked, not a fabricated name that developers were tricked into trusting for the first time. Both belong in a supply chain threat model, but they call for different controls, and conflating them understates how many distinct ways a dependency can turn hostile.

The react-codeshift case is the clearest illustration of what changes when AI moves from suggesting code to executing it. A human developer who is handed a suspicious install command at least has the option to pause and Google the package name. An AI coding agent operating with tool-use permissions, wired into an agent skill or automated pipeline, can go from "the model suggested this package" to "npx just ran it" with no intermediate checkpoint at all, which is exactly the path Eriksen documented: agent skills invoking the hallucinated name directly, no human review in the loop.

This is not a hypothetical concern specific to one vendor's tooling. Any workflow where an LLM's output is piped directly into a shell, a CI job, or an autonomous coding agent's next action removes the one control that has protected developers from this class of risk for years: a human pausing before running an unfamiliar install command. The same pattern that makes AI coding assistants valuable, reducing the friction between "I need a library for this" and "the code that uses it is running", is the pattern that removes the friction an attacker needs eliminated to make slopsquatting work.

CI/CD pipelines compound this further. A build script that pins dependencies loosely, or a Dockerfile that runs pip install -r requirements.txt against a file an AI assistant helped draft, inherits whatever hallucinated name made it into that file, and runs it in an environment that often holds far more valuable credentials than a single developer's laptop. If a hallucinated or slopsquatted package does make it into a build environment, the detection and containment steps look the same as for any other build pipeline compromise: see how to detect supply chain compromise in a software build pipeline for the general playbook, and the GitHub Actions supply chain incident response checklist for the CI-specific forensic steps once a bad package is confirmed to have run.

None of the controls below are exotic. Slopsquatting succeeds because ordinary install-time hygiene gets skipped when the recommendation came from an AI assistant that developers implicitly trust more than they would trust a random forum post. Restoring that scrutiny is most of the work.