Supply chain
Slopsquatting
Slopsquatting is a supply-chain attack where an attacker registers a package name that AI coding tools tend to invent, so that an assistant's or agent's install line resolves to the attacker's code.
What it means
Slopsquatting starts with a name nobody has published and a model keeps suggesting anyway. An attacker publishes a package under it, so the next install line that follows the suggestion pulls the attacker’s code.
The name came out of an April 2025 conversation: Seth Larson, the Python Software Foundation’s Security Developer-in-Residence, suggested it, and Andrew Nesbitt posted it on Mastodon on 8 April 2025, crediting Larson and calling it the AI brother of typosquatting.
Nesbitt later put the attack in one line: “prompt LLMs with common coding tasks, collect the hallucinated names, register them on PyPI or npm with malicious payloads, and wait.”
A hallucinated package is the model’s error; slopsquatting is what an attacker does with it.
Why it matters for AI-written code
An invented name is worth registering only if models keep producing it. In the USENIX Security 2025 study by Spracklen and colleagues, prompts that had produced a hallucination were re-run ten times each; 43% of the invented names came back in all ten runs. The paper calls a persistent hallucination more valuable to a malicious actor.
Bar Lanyado had shown the mechanism before the term existed. His 2023 research at Vulcan Cyber found ChatGPT recommending packages that did not exist; the empty package he later published at Lasso Security under huggingface-cli, a name models kept producing, was downloaded and pulled into other projects’ code.
A coding agent removes the last pause: it proposes the dependency and runs the install itself, so the registry answers before anyone reads the name. The OpenSSF guide for AI code assistant instructions cites slopsquatting as the reason to tell assistants not to add dependencies that may be hallucinated, and notes that models can often recognize their own invented names when asked.
Slopsquatting vs typosquatting
The study files package hallucinations under package confusion attacks, the family typosquatting belongs to, yet the registry rules built for typosquatting cannot see them: most hallucinated names in the study were not trivial misspellings of a real package, so a similarity check has nothing to compare them with.
| Typosquatting | Slopsquatting | |
|---|---|---|
| Who produces it | A person mistypes a real package | A model invents it; an agent repeats it |
| What it resembles | A popular package, one slip away | Nothing published; usually not a misspelling |
| Registry rule | npm blocks look-alikes at publish; PyPI flags typosquats at creation | None fits: no original to compare against |
| Control that catches it | Name rules, then install-path controls | Install-path controls only: package age, quarantine, frozen installs |
How Enji Guard helps
To the dependency hygiene audit an invented name looks like any other package. What each rerun records, as the project changes, is which controls sit between an install path and a brand-new public package. Three of them answer slopsquatting directly:
- Package-age gates. pnpm’s
minimumReleaseAgesets how many minutes must pass after publication before pnpm installs a version; its docs reason that malware is usually detected quickly, so a 24-hour delay most likely prevents a bad install. - Registry quarantine. A PyPI project marked as potentially harmful by administrators is hidden from the simple index and cannot be installed.
- Frozen or locked installs.
npm ciexits with an error when the lockfile andpackage.jsondisagree instead of resolving the difference, so a name that never reached the lockfile fails there.
The runbook records a package-age/quarantine gap on a privileged install path as a control finding, candidate type package_age_gate. When that same path can also pull fresh public packages and run their code with deterministic-install and lifecycle-script controls missing, the exposure is classified as a risk finding and rated critical.
The audit does not look names up on a registry and cannot tell an invented package from a real one. It does not stop or watch installs. It is read-only: manifests and lockfiles stay untouched; removing a package stays with the team.
Enji Guard