Slopsquatting Is the AI Software Supply Chain Threat Developers Cannot Ignore
Slopsquatting represents an emerging supply chain threat made possible by AI hallucinations. As developers increasingly rely on AI coding assistants, they unknowingly grant cybercriminals access to their software from day one. AI coding tools can write functions, fix bugs and suggest software dependencies in seconds. However, they can also invent packages that do not exist.
That mistake has created an opening for a new software supply chain threat known as slopsquatting. Unlike typosquatting, slopsquatting does not wait for a developer to misspell a legitimate package name. Instead, an attacker registers a convincing package name that an AI model has hallucinated.
If the AI suggests that name again, a developer or autonomous coding agent may install the attacker-controlled package. As a result, one false recommendation could expose source code, API keys, cloud credentials or CI/CD secrets.
Understanding what slopsquatting is
Slopsquatting is a new software supply chain threat that takes advantage of mistakes made by large language models. When an AI coding tool invents a package name that does not exist, an attacker may register that name and fill it with malicious code. The term blends “AI slop” with typosquatting, a tactic where criminals create misspelled or lookalike versions of trusted names to trick users into choosing the wrong one.
When a developer follows the AI-generated installation command, the attacker’s package enters the development environment. It may run malicious installation scripts, steal credentials or download another payload.
How AI Coding Agents Hallucinate Dependencies
Large language models do not look up packages. They predict tokens that are statistically likely to follow a coding context. When the right answer is uncertain, the model fills the gap with something that looks plausible: an author name that follows naming conventions, a DOI that is well-formed, a package name that fits the ecosystem.
A March 2025 research paper measured this directly. Researchers generated 576,000 code samples using major LLMs and checked every package name against npm and PyPI. The results:
- 19.7% of suggested packages did not exist on the target registry
- Open-source models hallucinated at 21.7%
- CodeLlama hallucinated package names in over a third of its outputs
- GPT-4 Turbo was the cleanest at 3.59%
The most important number for security teams is repeatability. When the same prompt was run 10 times against the same model, 43% of the hallucinated names appeared in every single run. The hallucinations are not random noise. They are deterministic enough to be predicted, scraped, and weaponized.
A separate report from Versa Networks found that 58% of hallucinated packages appeared repeatedly across runs. With AI now writing 25% or more of new code at leading tech firms, the attack surface is large and growing.
How Does a Slopsquatting Attack Work?
The attack often begins with an ordinary coding request.
A developer may ask an AI assistant to add a feature, solve an error or recommend a library. However, instead of naming a real package, the model creates one that sounds believable.
An attacker can exploit this weakness through the following process:
- The attacker tests popular AI coding models with common prompts.
- The models generate package names that do not exist.
- The attacker identifies names that appear repeatedly.
- The attacker registers those names on npm, PyPI or another registry.
- A developer receives the same hallucinated recommendation.
- The developer or coding agent installs the package.
- Malicious code runs with the developer’s permissions.
Autonomous coding agents make the threat more serious. These agents may create code and run package-manager commands with limited human review. Therefore, a fake package can move from an AI response to a developer’s machine within seconds.
Why Slopsquatting Is Different From Typosquatting
Typosquatting relies on human mistakes. An attacker registers a misspelled package name, such as cross-evn, hoping someone types it instead of cross-env.
Slopsquatting targets AI mistakes. The attacker registers a completely new package name that an AI coding tool repeatedly invents. Because the name may not resemble any real package, standard similarity checks are less effective.
| Typosquatting | Slopsquatting |
|---|---|
| Caused by a typing error | Caused by an AI hallucination |
| Often resembles a real package | May use a completely new name |
| Easier to detect with similarity checks | Harder to detect using name matching |
For example, an AI model might combine the names or functions of two legitimate libraries. The result looks professional, follows common naming patterns and appears suitable for the task.
This makes slopsquatting harder to detect through name-similarity checks alone. In addition, researchers have found that some hallucinated package names appear repeatedly across different prompts and models. That consistency allows attackers to identify and register promising names in advance.
What Research Says About AI Package Hallucinations
A major study presented at USENIX Security 2025 tested 16 code-generating large language models. The researchers generated 576,000 Python and JavaScript code samples. During the study, they identified 205,474 unique hallucinated package names. The tested commercial models produced an average package hallucination rate of at least 5.2%. Meanwhile, the tested open-source models averaged 21.7%.
However, these numbers apply to the models, prompts and settings used in that study. They should not be treated as permanent rates for every current AI coding tool. Even so, the research shows that package hallucination is not a rare spelling mistake. It is a persistent weakness that can affect AI-assisted software development.
The huggingface-cli Case Shows the Risk
Security researcher Bar Lanyado found that AI systems were recommending a Python package called huggingface-cli. The package did not exist at the time. Therefore, Lanyado registered it as an empty and harmless package to measure what would happen.
Within three months, the package received more than 30,000 authentic downloads. The incorrect installation command also appeared in public repository documentation. This was a controlled research demonstration, not a malware campaign. Still, it proved that a package invented by AI could attract real downloads and gain credibility through public documentation.
Not every suspicious package proves intentional slopsquatting. Some cases involve research packages, accidental copying or malicious packages with unclear origins. For accurate reporting, it is important to separate confirmed malware from suspected attacker intent.
How Developers Can Prevent Slopsquatting
Developers should treat every unfamiliar AI-recommended dependency as untrusted until they verify it.
1. Confirm the exact package name
Search for the package in the correct registry. Then compare the AI-generated command with the official documentation for the project or framework. However, registry availability alone does not prove that a package is safe. An attacker may have already registered the hallucinated name.
2. Check the publisher and repository
Review the package publisher, source repository, release history, documentation and registration date. For npm packages, provenance information can show how and where a supported package was published. It may also connect the release to its source commit and build workflow.
3. Require human approval
AI coding agents should not install unknown dependencies automatically. Teams can use approved dependency lists and require a developer to review every new package before installation.
4. Review lockfile changes
Every dependency change should appear in a pull request. Developers should inspect changes to package-lock.json, requirements.txt and other dependency files. A lockfile helps track exact versions. However, it cannot stop a malicious package if the team approves it without verification.
5. Use package hashes
Python teams can use pip’s --require-hashes option to verify expected package files. Hash checking helps protect installations against remote tampering or unexpected file substitution.
6. Isolate unknown installations
Run unfamiliar installation commands in a temporary container or restricted sandbox. The environment should not contain production credentials, repository tokens or sensitive API keys. This step limits the damage if a package runs a malicious installation script.
What Should You Do After Installing a Suspicious Package?
- Do not assume that uninstalling the package removes the risk.
- Stop using the affected environment and check whether installation scripts ran. Review terminal, endpoint and CI/CD logs for unusual processes or network connections.
- Next, rotate any API keys, cloud credentials, repository tokens or package-manager tokens that the package may have accessed.
- Remove the dependency from your manifest and lockfile. Then rebuild the project in a known-clean environment and report the package to the relevant registry.
AI Makes Supply Chain Controls More Urgent
Traditional supply chain security assumed humans choose dependencies. AI coding agents broke that assumption. They generate dependencies at machine speed, with confidence, and without verification. The registries they pull from were built for a world where the attacker had to guess what humans would mistype. That world is gone.
The defenses are not new. SBOMs, signed attestations, sandboxed installs, OPA policies, and lockfile diff enforcement are the same tools mature teams already use for supply chain security. What slopsquatting changes is the urgency. AI raises the tempo at which weak controls break.
If you are running AI coding agents in any production-adjacent workflow, the question is not whether a slopsquatted package will be suggested in your environment. It is whether your pipeline catches it before it lands in a lockfile.
