Slopsquatting

What Is Slopsquatting?

Slopsquatting is a supply-chain attack where someone registers packages under names that AI coding tools hallucinate, so developers who install a model's invented dependency pull the attacker's code instead of an error. It works because models hallucinate the same plausible package names repeatedly, making those names predictable and worth squatting.

Key Takeaways

• The attack chain is simple: a model invents a package name, an attacker has already registered that name on npm or PyPI with malicious code, and a developer or agent runs the install command without checking.
• It exploits a repeatable pattern, since models tend to hallucinate the same plausible-sounding names across sessions, which lets attackers harvest candidate names by prompting models at scale.
• Agentic workflows raise the stakes. An AI coding agent that installs its own dependencies can complete the entire attack chain with no human reading the package name.
• Mitigations are ordinary supply-chain discipline applied to a new trigger: verify a package exists and is legitimate before installing, use lockfiles and private registries, and gate agent-initiated installs behind approval or an allowlist.

How It Works

Language models generate code by predicting plausible tokens, and import statements are no exception. When a model needs functionality it does not precisely remember, it may emit a dependency that looks right, follows the naming conventions of the ecosystem, and does not exist. Security researchers measuring this across 576,000 generated code samples from 16 LLMs found that an average of 5.2% of packages recommended by commercial models, and 21.7% by open-source models, did not exist [1]. Critically, the fabrications were not random noise: in the same study, 43% of hallucinated package names repeated in all 10 re-runs of the identical prompt, and 58% recurred more than once across 10 iterations [2].

That predictability is the whole attack. An adversary prompts popular models with common coding tasks, collects the package names that come back, filters for ones that are unregistered, and publishes malicious packages under those names. The payload typically runs on install or on first import: credential theft, environment variable exfiltration, or a backdoor. From there the attack rides normal developer behavior. Someone accepts an AI suggestion, runs pip install or npm install, and the registry happily serves the squatter's code. The name is not a typo of anything, which is what separates slopsquatting from classic typosquatting; the name was never real.

Defenses stack. Individual developers verify unfamiliar packages before installing: check the registry page, the repository link, the download history, and the publish date, since a package created last week with no repository is a red flag. Teams enforce lockfiles, dependency review on pull requests, private registries or proxies with allowlists, and scanners that flag newly published or low-reputation packages. For agents, the guardrail is structural: the agent proposes dependencies but a human or a policy check approves them, and the sandbox the agent builds in has no credentials worth stealing.

Example

A developer asks a coding agent to add retry logic to a Python service that calls a flaky API. The agent writes clean code importing a helper library with a perfectly idiomatic name that blends the task and the framework, then adds it to requirements.txt and runs the install as part of its loop. The package exists on PyPI, published three weeks earlier, because an attacker had harvested it from model outputs. Its setup script exfiltrates the CI environment variables on install. The team catches it in staging when their dependency firewall flags a package younger than their minimum-age policy. The post-incident change: agent-initiated installs now resolve only through the company's internal registry proxy, which mirrors approved packages and rejects everything else.

What People Get Wrong

The misconception is that slopsquatting is just typosquatting with a trendy name, already covered by existing tooling. Typosquatting defends against human fingers: tools compare names against popular packages and catch one-character deviations. Slopsquatted names are not near anything. They are novel, plausible, convention-following names that no similarity check will flag, and the installer is increasingly an agent rather than a person who might hesitate. The defense has to shift from "does this name look like a typo" to "does this package have a verifiable history."

Package hallucination

Package hallucination is the model-side half of the problem: an AI system confidently referencing a library, module, or API that does not exist. It is a specific case of AI hallucination, and it happens most with niche tasks, newer ecosystems, and plausible-sounding combinations of real project names. On its own, a hallucinated package is a build error and a few wasted minutes. It becomes a security issue the moment someone registers the name, which is exactly what slopsquatting does. The pool of names is not small: the USENIX Security 2025 measurement study recorded 440,445 package hallucinations in total, including 205,474 unique non-existent names an attacker could register [3]. The rate varies by model and ecosystem, but no current model is immune, and agents that generate and execute install commands in one loop convert each hallucination into an attempted download. Reducing it helps: retrieval against a real package index, verification steps in the agent loop, and prompts that require the model to justify each new dependency all cut the rate. Elimination is not on the table with current architectures, so the registry-side and pipeline-side defenses carry the real weight.

FAQ

Where does the name slopsquatting come from? It blends AI slop, the derogatory term for careless machine-generated output, with typosquatting, the older attack of registering near-miss domain and package names. The term spread through the security community in 2025 after research quantified how often coding models fabricate dependencies.

Which ecosystems are most exposed? Any registry with open, instant publishing: npm and PyPI are the primary targets because publishing is frictionless and install scripts run code. Ecosystems with curated or namespaced registries are harder to attack, and internal mirrors with allowlists close the door almost entirely.

How do I check whether a package an AI suggested is real and safe? Look it up on the registry directly, not through search. Then check age, download counts, a linked source repository that actually contains the code, and a maintainer with history. If AI code generation suggested it and it fails any of those checks, treat it as hostile until proven otherwise.

Sources

1. arXiv / USENIX Security 2025 (Spracklen et al.). "5.2% of commercial-model and 21.7% of open-source-model package recommendations did not exist, across 576,000 code samples from 16 LLMs." https://arxiv.org/abs/2406.10279. Accessed August 2026.
2. arXiv / USENIX Security 2025 (Spracklen et al.). "43% of hallucinated package names repeated in all 10 re-runs of the same prompt; 58% recurred more than once." https://arxiv.org/html/2406.10279v3. Accessed August 2026.
3. arXiv / USENIX Security 2025 (Spracklen et al.). "440,445 total package hallucinations, including 205,474 unique non-existent package names." https://arxiv.org/abs/2406.10279. Accessed August 2026.