Slopsquatting: when your AI assistant invents a package — and an attacker owns it.

Coding assistants recommend packages that don't exist — roughly one in five recommendations, across 576,000 generated code samples in the largest study to date. The names aren't random: many recur every time the same prompt is asked. Which means an attacker can farm the prompts, register the phantom names, and wait for a developer — or an autonomous coding agent — to install them. Typosquatting needed you to make a mistake. Slopsquatting only needs you to trust your tools.

What the research shows

The hallucinations are predictable. That's the problem.

The USENIX Security 2025 study "We Have a Package for You!" — researchers from UT San Antonio, Virginia Tech, and the University of Oklahoma — tested 16 code-generation models across 576,000 Python and JavaScript samples. About 19.7% of recommended packages did not exist: roughly 5% for commercial models, around 21% for open-source ones, producing 205,474 unique phantom package names. Worse, the errors are stable — about 43% of hallucinated names reappeared in every one of ten re-runs of the same prompt, and 58% recurred more than once. A repeatable error is a targetable error.

Security researcher Bar Lanyado demonstrated the exploit path: he asked models for install advice, spotted a recurring hallucinated name — huggingface-cli — and registered it on PyPI as an empty placeholder. It drew tens of thousands of downloads within months, and even appeared in the install instructions of a major company's open-source repository. His package was harmless. The next one registered from the same playbook may not be.

The term — "slopsquatting," coined in the Python security community — went mainstream in 2025, just as agentic coding tools began running pip install and npm install without a human reading the package name at all. That is the step change: the last pair of eyes between a hallucinated name and your build is disappearing.

~20%

of LLM package recommendations don't exist (16 models, 576k samples)

205,474

unique hallucinated package names generated in the study

43%

of phantom names recur on every re-run of the same prompt

10k+

downloads of a single registered phantom name in months

The OrbitalReg defence

Containment that doesn't depend on anyone reading the name.

✓Curated proxies, not open resolution

When developers and agents resolve against your OrbitalReg virtual repo instead of the public registry, a phantom package an attacker registered yesterday isn't reachable by default — it has to pass your remote-proxy policy first. The attack's core assumption, "whatever the assistant names, the resolver can fetch," stops being true.

✓Pull-gate on first contact

Artifacts entering through a proxy are scanned at upload and gated at pull — block-until-scan or optimistic quarantine, per repo. A freshly registered package with an install-time payload meets the gate on the registry, not the developer's laptop or the CI runner.

✓Failed resolutions are signal

Requests for packages that don't exist in any configured upstream land in the audit trail. A spike of misses on a name nobody published is exactly what hallucinating tools look like from the registry's side — an early-warning feed for which phantom names your own teams are being told to install.

✓Air-gap for agentic pipelines

If autonomous agents build inside your infrastructure, air-gap mode gives them a package universe you defined in advance. An agent can only install what your registry serves; a hallucinated name resolves to nothing, fails fast, and shows up in the log.

What this composes to. Slopsquatting exploits the gap between "a name was suggested" and "a name is trustworthy." Every control above narrows that gap at the registry layer, where it can be enforced — instead of at the code-review layer, where AI-speed development is steadily removing it.

For your records

Slopsquatting timeline.

2023-06

First public research on AI package hallucination as an attack vector: models recommend non-existent packages consistently enough for an attacker to pre-register them.

2024-03

Lanyado's registered phantom package huggingface-cli accumulates tens of thousands of downloads and appears in a major vendor's open-source install instructions — with no malicious payload, as a proof of concept.

2025-04

"Slopsquatting" enters the mainstream security vocabulary as preprints of the package-hallucination study circulate and agentic coding tools drive auto-installs.

2025-08

USENIX Security 2025 publishes the full study: 16 models, 576,000 samples, ~19.7% hallucination rate, 205,474 unique phantom names, 43% perfectly repeatable.

Honest caveats

Where the defence stops short.

Scanning is not omniscience. A brand-new malicious package may carry no known CVE and evade first-pass scanners. The pull-gate buys you a controlled choke point and a quarantine window — it does not guarantee that genuinely novel malware is detected on day one. Curation (allowlists, internal-first virtual repos) is the stronger control; the gate is defence in depth behind it.

The registry can't fix the model. Assistants will keep hallucinating names; the fix for that belongs to the tool vendors. What the registry changes is the blast radius: a hallucination that resolves to nothing is an annoyance, not an incident.

Related reading. Slopsquatting is the AI-era cousin of name-resolution attacks we've covered before: dependency confusion exploits ambiguity between your registries; Shai-Hulud shows what spreads when the public registry is the trust root. And for the agent capabilities themselves, our field guide to governing agent skills covers the same discipline one layer up.

Primary sources

Running AI coding tools against public registries?

Put a curated registry between your agents and the internet.

Rico, the founder, walks through what an internal-first, pull-gated package path looks like for teams adopting AI-assisted and agentic development — and what it surfaces in the audit trail on day one.