Slopsquatting: Security Risks of Hallucinated Package Names in Agent-Generated Plans and Artifacts

Slopsquatting is SSA descriptive wording for a security-relevant gap between what an agent's own generated artifact claims and what is actually true: a dependency name, import statement, or install command the agent writes as part of a plan or code artifact refers to a package that was never real when the agent generated it, and an adversary has pre-registered that exact, predictable name on a public package registry. The defining consequence is that a later install step, run by the same agent, a CI pipeline, or a developer who trusted the agent's output, pulls attacker-controlled code under whatever privileges that install step holds.

What it is

The defining object is an agent-generated plan or artifact treated as verified fact rather than an unconfirmed claim: a `requirements.txt` entry, a `package.json` dependency, an `import` line, a Dockerfile `RUN pip install` command, or a task-list step that names a library to add. The defining cause has two parts. First, the model hallucinates a package name that sounds plausible but does not exist, a behavior that is not adversarial by itself. Second, an adversary who has studied which hallucinated names recur predictably registers that exact name on a public registry before anyone else does. The defining consequence is that an install step downstream of the agent's output executes attacker-controlled code because nothing in the pipeline checked whether the named package was ever real, or who actually controls it now.

This differs from an agent simply being wrong about a fact. A wrong fact stays inert until someone acts on it. A hallucinated package name becomes an executable attack path the moment an install command runs, because package managers do not distinguish "a name the model just invented" from "a name a developer typed after checking the registry."

What it is not

Typosquatting, where a human developer mistypes a real package's name and an attacker has registered the misspelling. The untrusted input there is a keystroke, not a model hallucination, even though the resulting malicious package can look identical.
A model recommending a real, existing package that happens to be low-quality, unmaintained, or later compromised through an ordinary supply-chain incident with no hallucination involved.
MCP tool poisoning, which targets a tool's own description, definition, or call result rather than content the agent generates as a task artifact.
Model-weight attacks, training-data poisoning, and reproducible exploit payloads or registration walkthroughs.

In scope

Hallucinated package, library, or API references appearing in agent-generated dependency manifests, import statements, install commands, Dockerfiles, or CI configuration.
The predictability of hallucinated names, where the same or similar prompts cause repeated generation of the identical nonexistent name across models and sessions, which is what makes a name practical for an adversary to pre-register.
Adversarial registration of a predicted hallucinated name on a public package registry such as PyPI, npm, crates.io, or RubyGems.
Propagation once a hallucinated reference is committed to a shared repository, lockfile, or CI pipeline that other sessions, agents, or teammates later build from.
Defensive controls for registry verification, lockfile discipline, sandboxed installation, and recovery.

Target state, trust boundaries, and impact

The target state is the agent's own generated artifact, a specific line naming a package, once it is treated as a verified reference rather than an unconfirmed string the model produced. The relevant trust boundary sits between "the model wrote this name" and "this name identifies a real package that is safe to install," and most agent pipelines, build tools, and human reviewers do not independently verify that second claim before an install step runs. Nothing about the artifact's origin, that it came from the agent that is supposed to be helping, signals whether the name inside it was ever checked against reality.

Three preconditions are usually present: the agent must generate content that names an installable or importable dependency; a public registry must allow open registration of arbitrary package names; and the pipeline from generation to install or execution must lack a step that confirms the named package's identity, publish history, or maintainer before trusting it. Resulting effects include arbitrary code execution under the privileges of whatever process runs the install, whether that is the agent's own sandbox, a CI runner with repository secrets, or a developer's workstation; credential and token theft staged through a package's install-time hooks; and, once a poisoned dependency is committed to a shared manifest or lockfile, compromise reaching every later build that reuses it.

Persistence

A single hallucinated name that never leaves a throwaway session, discarded before any install runs, causes no lasting harm. Risk escalates once the reference is written into a manifest, lockfile, Dockerfile, or CI configuration that gets committed: from that point the poisoned reference is Cross-Session to Shared-System, read and potentially re-installed by every later session, pipeline run, or teammate who builds from that artifact, independent of whether the originating agent session still exists.

What the research establishes

Spracklen, Wijewickrama, Sakib, Maiti, Viswanath, and Jadliwala generated 576,000 code samples across two programming languages using 16 popular code-generating LLMs and found that commercial models produced hallucinated package references in at least 5.2 percent of outputs, while open-source models did so in 21.7 percent, identifying 205,474 unique hallucinated package names in total. The paper additionally reports that these hallucinations are not one-off noise: repeating the same prompt tends to reproduce the same invented name rather than a different random one, which is what makes a given hallucinated name predictable enough for an adversary to register in advance (We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, arXiv 2406.10279, v3, 2025-03-02, to appear at USENIX Security 2025).

The technique reached production before the research paper's final version was public. Security researcher Bar Lanyado, building on earlier hallucination testing conducted at Vulcan Cyber, identified that multiple LLMs recommended a nonexistent Python package named `huggingface-cli` and registered an empty package under that exact name as a proof of concept. Within three months the package logged more than 30,000 authentic downloads, and the same hallucinated name appeared as an install instruction in the README of an Alibaba research repository, evidence that the false recommendation had already propagated into other engineers' trusted references (Lasso Security, Diving Deeper into AI Package Hallucinations, 2024-03-28).

The pattern was named directly in 2025. Seth Larson, Security Developer-in-Residence at the Python Software Foundation, coined the term "slopsquatting" in April 2025, and the coinage was popularized by Andrew Nesbitt; the term positions the technique as a variant of the older cybersquatting family, where the exploited mistake is a model's hallucination rather than a person's typo (Wikipedia, Slopsquatting). Later coverage documented the defensive side directly: an analysis by Socket noted that some models, including GPT-4 Turbo, could correctly flag a package name they had just generated as hallucinated when specifically asked to double-check it, evidence that a self-verification step is not reliably present by default and has to be added deliberately rather than assumed (Socket, The Rise of Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks, 2025-04-08). This article does not reproduce the registration technique; it treats the above as evidence that agent-generated dependency references are a distinct, already-exploited entry path into the plans-and-artifacts target state.

Detection: observable signs

A dependency name, import, or install command in agent output has no verifiable match in the target registry's published package list.
The same or a similar prompt regenerates the identical, unfamiliar package name across separate sessions or separate runs.
A newly introduced dependency's registry entry has a short publish history, an unfamiliar maintainer, or a download curve that only started after the agent began referencing it.
An install step in a CI log references a package with zero prior appearance anywhere in the project's commit history.
A generated artifact is committed to a shared repository without a human or a second review step ever independently confirming the named packages are real.

Useful telemetry includes the full text of every generated manifest, import block, or install command; a diff between newly generated dependencies and the project's previously reviewed and pinned set; registry metadata, publish date, maintainer identity, and download history, for any dependency introduced for the first time; and whether the install step ran in an isolated, low-privilege environment or with production credentials attached.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders, not a standard requirement or a measured effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Registry existence and provenance check before install | A hallucinated name reaching an actual install step | Any agent or CI pipeline that generates installable dependency references | Confirms the package exists, not that it is safe; verify publish date and maintainer identity too, not existence alone. | | Lockfile pinning and hash verification | A first-seen package silently entering the dependency tree on a later, unreviewed rebuild | Build systems capable of reproducible installs | Protects re-installs but not the first introduction of an entry; pair with mandatory review at the moment a new dependency first appears. | | Sandboxed, least-privilege install execution | A malicious package's install-time code gaining full agent or CI privileges | Any environment that executes agent-generated install commands | Limits blast radius, not the hallucination itself; exercise the sandbox with a deliberately fake package name to confirm containment actually holds. | | Explicit model self-verification pass | A hallucinated name reaching the final artifact without a second check | Agents with a review or critic step available before output is finalized | Inconsistent across models per Socket's reporting; treat as a supplementary signal alongside registry verification, not a sole control. | | Private or allowlisted registry mirroring | Any unreviewed name, hallucinated or otherwise, becoming installable at all | Organizations that control their own build environment | Allowlist maintenance has ongoing overhead; verify the allowlist update process itself cannot be approved by the same unsupervised agent that generated the request. |

Prevention should treat every agent-generated dependency reference as an unverified claim requiring an independent registry lookup before any install step runs. Detection should diff newly introduced dependencies against a project's prior history and flag first-time, low-reputation entries for review. Containment should block the specific package, and any artifact that referenced it, from further installs pending review, rather than merely editing the reference out of the current file. Recovery should rebuild from the last known-clean lockfile, audit anything already installed under the poisoned reference, and rotate any credentials exposed to the compromised install step.

Boundaries with similar concepts

MCP tool poisoning, covered separately, targets a tool's own description, definition, or call result; slopsquatting targets content the agent itself writes as a task artifact, a dependency name rather than tool metadata, though the two can converge if a poisoned manifest ships inside a compromised MCP server package. Instruction file poisoning targets a file an agent loads as standing guidance at startup; a slopsquatted dependency is instead produced during a task and consumed later, usually by a build step rather than by the agent's own configuration-loading path, though a poisoned manifest committed alongside instruction files in the same repository can implicate both. Shared state poisoning covers state more than one agent or session reads as trusted; a slopsquatted dependency enters that category once it is committed to a shared repository other pipelines build from, but a single hallucinated name inside one discarded session's scratch output, never installed or committed, stays outside this narrower working term.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | arXiv 2406.10279 (v3, 2025-03-02, USENIX Security 2025) | Package hallucination | Primary empirical evidence establishing hallucination rates, scale, and repeatability across 16 code-generating LLMs; foundation for this article's threat model. | | Lasso Security / Bar Lanyado (2024-03-28) | `huggingface-cli` proof of concept | Documented real-world instance of a hallucinated name being registered and adopted at scale before being independently reviewed. | | Python Software Foundation / Seth Larson, via Wikipedia (coined April 2025) | "Slopsquatting" | Industry-coined term for the registration technique this article's scope covers; not an SSA-owned phrase. | | Socket (2025-04-08) | Slopsquatting as a named supply-chain attack class | Documents defensive tooling patterns and the inconsistency of model self-verification as a standalone control. | | OWASP Top 10 for LLM Applications 2025 | `LLM03:2025 Supply Chain` | Broader application-layer risk category for dependency and supply-chain weaknesses. | | OWASP Top 10 for Agentic Applications 2026 | `ASI04 Agentic Supply Chain Vulnerabilities` | Agent-specific supply-chain risk category covering tooling and dependency compromise reaching an agent. | | MITRE ATLAS v2026.06 | `AML.T0010 AI Supply Chain Compromise`; `AML.T0010.005 AI Agent Tool` | Attacker-behavior classification for supply-chain compromise reaching an AI agent's tooling; identifiers reused from this site's previously verified crosswalk entry. | | Agent State Attack | Slopsquatting in agent-generated plans and artifacts | SSA descriptive framing of this target state, not attributed to the sources above. |

Related terms

Agent state attack: the SSA Working Term this article's scope sits under.
MCP tool poisoning: the adjacent state surface for tool description and result poisoning rather than agent-generated artifact content.
Shared state poisoning in multi-agent systems: the boundary case where a poisoned dependency reference is committed to a repository other agents or sessions build from.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping this entry draws its standards references from.

FAQ

Is slopsquatting only a risk for coding agents?

The documented cases so far involve agents and chat assistants generating installable dependency references in code, but the underlying mechanism applies to any agent-generated artifact that names an external resource later fetched or executed without independent verification, not exclusively package managers.

Does the model have to be malicious for this to happen?

No. Hallucination itself is an ordinary model error, not an attack. The technique becomes exploitable only once an adversary has separately identified a predictable hallucinated name and pre-registered it; a hallucinated name that no one has claimed on a registry carries no exploitation path yet.

Is this the same as typosquatting?

No. Typosquatting exploits a human mistyping a real package's name. Slopsquatting exploits a model inventing a name that never existed, then relies on the same registration mechanism an attacker would use for typosquatting once that invented name is predictable enough to target.

Can a private, allowlisted registry fully eliminate the risk?

It removes the public-registry entry path, since an attacker cannot register a name inside a registry they do not control. The residual risk moves to the allowlist's own update process, which needs review that is not performed by the same unsupervised agent that generated the request to add the dependency.

Is a single hallucinated package name in an agent's output proof of an active attack?

No. Treat it as a lead. Confirm whether the name is actually registered on the target public registry, whether that registration predates or postdates typical agent usage of the name, and whether the reference ever reached an install step before concluding it represents exploitation rather than an inert hallucination.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for LLM Applications, Version 2025 (2024-11-18); OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); arXiv 2406.10279, v3 (2025-03-02).

Last verified: 2026-08-21. The arXiv paper's authors, dates, and reported findings were read from its abstract page; the Lasso Security post's author, date, and download figures were read from the source article; the term coinage and popularization were read from the cited Wikipedia article; the Socket post's author, date, and self-verification finding were read from the source article; the OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entry.

Change history: 2026-08-21, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** "Package hallucination" is a Research Term from arXiv 2406.10279. "Slopsquatting" is an Industry Term coined by Seth Larson and popularized by Andrew Nesbitt. `LLM03:2025`, `ASI04`, `AML.T0010`, and `AML.T0010.005` are Standard Terms owned by OWASP and MITRE. "Slopsquatting in agent-generated plans and artifacts" as the umbrella framing for this article is SSA descriptive wording, not a standard term.