Slopsquatting

Concept: Vocabulary that names a phenomenon.

Slopsquatting is a supply-chain attack in which someone registers a package name that code-generating models invent, so the next developer or agent who follows the model’s suggestion installs the attacker’s code.

Also known as: Hallucination Squatting, Package Hallucination Attack

The name is a portmanteau. Typosquatting is the old trick of registering a package name one keystroke away from a popular one and waiting for someone to mistype it. Slop is the pejorative for careless AI output. Seth Larson, the Python Software Foundation’s security developer-in-residence, put the two together in April 2025 to name a new version of the bet. Typosquatting bets on a human’s typo. Slopsquatting bets on a model’s plausible invention: a name that sounds right, follows the ecosystem’s naming habits, and doesn’t exist until an attacker creates it.

Understand This First

• Dependency — what a project takes on when it adds a package.

• AI Smell — the fabricated-reference smell that produces the invented name.

• Trust Boundary — the public registry sits on the far side of one.

What It Is

Code models sometimes recommend packages that don’t exist. Researchers call this package hallucination. The model has seen thousands of real names like jscodeshift and react-codemod, and when it needs a library for a task, it can produce a blend that fits the pattern perfectly and points at nothing.

On its own, a hallucinated package is a nuisance. The install fails, someone notices, and the agent picks a real library. Slopsquatting turns the nuisance into an attack. An adversary collects the names models invent, registers them on npm or PyPI, and fills them with code that runs at install time. Now the install succeeds. Nothing fails, nobody notices, and the attacker’s code runs with whatever access the installing process had.

The attack works because hallucinations repeat. Joseph Spracklen and colleagues generated 576,000 Python and JavaScript samples from 16 code models and found invented packages in at least 5.2% of commercial-model output and 21.7% of open-source-model output, covering 205,474 unique fake names. When they re-ran prompts that had produced a hallucination, about 43% of the invented names came back in all 10 runs, and about 58% came back more than once. A name that recurs is a name worth registering. An attacker doesn’t need to guess; they can ask the models themselves which packages they’ll invent.

Why It Matters

While a human sat between the suggestion and the install, slopsquatting had a natural checkpoint. A developer reading pip install in a chat window might pause at an unfamiliar name. A coding agent doesn’t pause. It writes the import, runs the package manager, reads the passing test, and moves on. The step where someone might have noticed is gone.

Agents also make the payload more valuable. Install scripts run in whatever environment the agent is working in, and that environment often holds model API keys, source-control tokens, and cloud credentials, because the agent needs them for its real work. A malicious package installed by an agent can take the Secrets that agent was trusted with. Because the agent can also commit and push in the same task, the new dependency can reach CI and teammates’ machines before a person has looked at it.

The invented name also spreads through generated text. An agent that writes documentation, a README, or a reusable Skill can bake the hallucinated install command into an artifact that other agents read as instructions. Every agent that follows those instructions later installs whatever is registered under that name at that moment.

The exploit has already been shown to work. In research published in March 2024, Bar Lanyado noticed models repeatedly recommending a nonexistent Python package called huggingface-cli and uploaded an empty package under that name as a test. It drew more than 30,000 downloads in three months, and the hallucinated install command had found its way into the README of a public Alibaba research repository.

How to Recognize It

Slopsquatting is hard to see in a passing build, so the signals live in the dependency diff and the registry record:

• A dependency in an agent’s change that you’ve never heard of and that nobody asked for.

• A package whose name blends two real ones, or bolts a framework prefix or a -cli suffix onto a familiar name.

• A registry entry that’s days or weeks old, has one or two versions, few downloads, no linked source repository, or a publisher with no other packages.

• An install-time script (postinstall in npm, setup code in a Python source distribution) on a package that has no obvious reason to run code during installation.

• Install commands in generated docs, READMEs, or skills that name a package missing from the project’s lockfile.

• An install that fails with “not found.” That’s a hallucinated name nobody has squatted yet, and it’s the cheapest moment to catch one.

How It Plays Out

Aikido researcher Charlie Eriksen found a package name, react-codeshift, that no one had ever published. A model had blended jscodeshift and react-codemod into it, and the name first appeared in a single commit containing 47 model-generated agent skills. By the time Eriksen found it, the instruction had spread through forks to 237 repositories. He registered the name himself in January 2026 so an attacker couldn’t. Afterward it kept drawing a couple of downloads a day, which Aikido attributes to agents still following those skills. No attacker was involved this time. Had one registered the name first, every agent following those skills would have run their code.

A platform team lets its coding agent add dependencies, but only through a gate. Any install of a package not already in the lockfile goes to a Permission Classifier, which checks the registry record before deciding. Midway through a PDF-export feature, the agent tries to install a package whose name combines two well-known PDF libraries. The registry says it was first published nine days ago, has one version, no linked repository, and a postinstall script. The classifier blocks the install and asks the developer, who searches for the name, finds no project behind it, and points the agent at the real library. The whole detour costs four minutes. Without the gate, the script would have run inside a container holding the team’s deployment token.

Warning: A green build proves nothing here. A slopsquatted package installs cleanly, imports cleanly, and may even contain working code copied from the real library it imitates. The payload runs at install time, before any test does.

Consequences

Naming slopsquatting changes how you treat a package install. It stops being a routine build step and becomes a privileged action that crosses a Trust Boundary, with defenses to match:

• Verify before adding. Before a new dependency enters the manifest, check that it exists, who published it, when it was registered, and whether it links to a real source repository. The Cloud Security Alliance suggests flagging anything registered in the prior 30 to 90 days for a human look.

• Pin and hash. Commit the lockfile, install from it (npm ci, pip install --require-hashes), and treat any change to it as a reviewable event. Pinning keeps an agent from quietly resolving a name nobody approved.

• Gate new dependencies. Put “add a package not on the allowlist” under the Approval Policy so it pauses for a person, or route it through a classifier that checks the registry record.

• Install in isolation. Run installs in a Sandbox that holds no production credentials, with install scripts disabled by default where the ecosystem allows it, and give the agent only the access its task needs under Least Privilege.

• Review the manifest separately. In Code Review, read dependency changes as their own item, not as noise around the code diff.

• Scan generated text. Check docs, READMEs, and skills that agents write for install commands, since that’s how one hallucination becomes hundreds of installs.

Every one of these controls sits outside the model, for good reason. A smarter agent narrows the gap without closing it. In tests published in June 2025, Sean Park of Trend Micro found that reasoning and live web search roughly halved how often coding agents invented packages, and that an agent checking each candidate dependency against live documentation and search tools still let a few invented names through on the hardest prompts.

These controls cost something. Registry checks slow down the agent and produce false alarms on genuinely new, legitimate packages. Allowlists need someone to maintain them. Private mirrors and hash-pinned installs take engineering time to set up, and they annoy developers who want to try a library quickly. Defensive registration of invented names doesn’t scale either: Spracklen’s study alone found more than 200,000 of them.

There’s also a limit to what any one team can see. Larson has said that counting the installs hallucinations cause is difficult, and likely impossible, without more transparency from the model providers. The open question is how much of the fix belongs to registries and model vendors rather than to the people running agents. Until that’s settled, the install step in your own harness is the place you control.

Depends on: Attack Surface — Every registry an agent can install from, and every generated doc or skill that tells it what to install, is part of the attack surface.

Depends on: Dependency — Slopsquatting strikes at the moment a project takes on a new dependency, before anyone has checked that the dependency is real.

Depends on: Smell (AI Smell) — A hallucinated package name is the fabricated-reference smell; slopsquatting is what an attacker does with it when nobody checks.

Depends on: Trust Boundary — The public package registry sits outside your trust boundary, and an agent's install command crosses it without a pause.

Informs: Threat Model — Any agent that can run a package manager needs invented dependencies in its threat model.

Mitigated by: Approval Policy — Treating a new dependency as an action that needs human confirmation puts a person back at the step slopsquatting relies on nobody watching.

Mitigated by: Build Provenance — Provenance records let you check who published a package and from which repository before trusting it.

Mitigated by: Code Review — Reviewing changes to dependency manifests as their own item is where a reviewer catches a package they've never heard of.

Mitigated by: Hook — A pre-install hook can check each new package's registry age, publisher, and repository link before the install runs.

Mitigated by: Least Privilege — An agent that holds only the credentials its task needs gives a slopsquatted package less to steal.

Mitigated by: Permission Classifier — A classifier can route install commands for packages outside the lockfile or allowlist to a human instead of letting them run.

Mitigated by: Pinning — A committed lockfile with hash verification keeps an install from silently picking up a name or version nobody reviewed.

Mitigated by: Sandbox — Running installs in a sandbox without production credentials limits what a malicious install script can reach.

Sources

Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala measured the underlying behavior in We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025), establishing how often code models invent packages and that many invented names recur across runs.

Bar Lanyado demonstrated that hallucinated names are exploitable in Diving Deeper into AI Package Hallucinations (Lasso Security, March 2024), where an empty placeholder under a model-invented name drew more than 30,000 real downloads.

Seth Larson of the Python Software Foundation coined the term slopsquatting in April 2025. Thomas Claburn’s LLMs Can’t Stop Making Up Software Dependencies and Sabotaging Everything (The Register, April 2025) reports the coinage and Larson’s view that hallucination-driven installs can’t be counted without data from model providers. Andrew Nesbitt’s Package Security Problems for AI Agents (April 2026) places it among the other package risks agents introduce, including lockfile regeneration and install-time execution.

Dania Durnas documented the react-codeshift, unused-imports, and huggingface-cli cases in Slopsquatting: AI Package Hallucination Attacks (Aikido Security, February 2026), including Charlie Eriksen’s defensive registration of a name that agent skills had spread to 237 repositories.

Sean Park tested whether agent tooling closes the gap in Slopsquatting: When AI Agents Hallucinate Malicious Packages (Trend Micro, June 2025), finding that reasoning, web search, and real-time validation reduce invented dependencies without eliminating them.

The Cloud Security Alliance’s AI Safety Initiative set out the agentic amplification and a layered defense in Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks (April 2026): registry verification, hash-verified lockfiles, install allowlists, recency flags, and scanning documentation for unverified install commands.