In 2023, a security researcher named Bar Lanyado ran a quiet experiment. He noticed that AI coding assistants kept recommending a Python package called huggingface-cli, a package that did not exist. So he created it: an empty placeholder, uploaded under the exact name the models were inventing. He added no functionality and no payload. He just waited.
Within three months, the package had been downloaded more than 30,000 times. The hallucinated install command had even found its way into a public repository README belonging to a major technology company. Lanyado’s package was harmless. But the experiment proved something unsettling: an attacker can predict what an AI will invent, register it first, and let developers install it themselves. That technique now has a name, slopsquatting, and it’s one of the fastest-growing threats in the software supply chain.
What is slopsquatting?
Slopsquatting is a supply chain attack in which an attacker registers a malicious software package under a name that AI coding assistants predictably hallucinate. When a developer asks an AI tool for help and it suggests installing a plausible-sounding but non-existent dependency, the attacker has already claimed that name in the public registry, so the “helpful” suggestion installs malware instead of nothing.
The term was coined in April 2025 by Seth Larson, security developer-in-residence at the Python Software Foundation. It’s a play on typosquatting, the older attack where criminals register misspellings of popular packages (reqeusts instead of requests). The difference is the source of the mistake: typosquatting exploits human typos, while slopsquatting exploits AI “slop”: the confident, fluent, wrong output that large language models produce.
Why slopsquatting actually works
You might assume AI hallucinations are random noise: a different fake name every time, impossible to weaponize. The research says otherwise, and that’s the whole point.
A peer-reviewed study presented at USENIX Security 2025 (Spracklen et al.) tested 16 large language models across 576,000 generated code samples. It found that 19.7% of recommended packages did not exist: 205,474 unique hallucinated names in total. Critically, those hallucinations were repeatable: 43% of fake names reappeared across repeated prompts, and 58% recurred across ten runs of the same query. Open-source models hallucinated packages 21.7% of the time; even commercial models like GPT-4 did so 5.2% of the time: one in twenty.
Repeatability is what turns a quirk into an attack. An attacker doesn’t need to guess. They can run popular prompts, record which non-existent packages the models keep suggesting, and register those names as malware. The AI does the targeting for them.
How a slopsquatting attack unfolds
The attack chain is short, which is part of why it’s dangerous:
- Observe. The attacker prompts AI coding assistants with common development tasks and logs the package names those tools invent but that don’t exist in the registry.
- Register. They publish a malicious package under one of those hallucinated names, with a clean README, plausible metadata, and a payload hidden in an install script.
- Wait. A developer (or an autonomous coding agent) asks an AI tool a similar question, receives the same hallucinated recommendation, and runs install.
- Execute. The package’s install hook fires, exfiltrating secrets, opening a reverse shell, or planting a backdoor, and the compromise flows downstream into builds and production.
Autonomous coding agents make step 3 far more likely. An agent that installs dependencies without human review removes the one checkpoint where a developer might have paused and thought, “I’ve never heard of that package.”
How bad is it, really?
Getting worse, not better. The USENIX study tested 16 models and still found nearly one in five recommended packages didn’t exist, so this isn’t a problem confined to older or weaker tools. And a coding assistant working from training data alone has no way to know whether the package name it just suggested is safe, hallucinated, or already flagged as malware: it has no real-time view of the registry. That’s not a lab curiosity. It’s the exact behavior developers now rely on dozens of times a day.
Slopsquatting also scales with the broader collapse in supply chain hygiene. In 2025, high-volume malicious-package campaigns became the baseline operating model for supply chain attacks, as Xygeni’s New AppSec Attack Trends for 2026 documents: attackers publish at volume, accept fast takedowns, and rely on probability, and AI hallucinations hand them a steady supply of high-conversion names to register.
How to defend against slopsquatting
The uncomfortable truth is that signature-based tools can’t catch this. A slopsquatted package is brand new; no CVE exists, no signature exists, and it may be live for only hours before takedown, long enough to rack up thousands of installs. Effective defense rests on four practices:
- Never install a package an AI suggests without verifying it exists and is legitimate. Check the real download history, maintainer, and repository, not just that the name sounds right.
- Detect malware by behavior, not signatures. Score a package at publish time on its install-time actions, network calls, and obfuscation patterns, so a malicious package is flagged the moment it appears rather than after it’s already known.
- Put a dependency firewall between developers and the registry. Quarantine suspicious or brand-new packages automatically before they reach a build, instead of trusting the public registry by default.
- Inventory what AI is running in your pipeline. Coding assistants and autonomous agents that install dependencies are part of your attack surface. An AI Bill of Materials (AI-BOM) makes that visible.
Slopsquatting is one symptom of a bigger shift
Slopsquatting is the sharpest example of a broader pattern: AI is now both the thing writing your code and the thing attackers point at in your supply chain. Defending against it in isolation isn’t enough; it belongs inside a wider strategy. For the full picture, see our guide to AI supply chain security, which covers malicious packages, MCP risks, and AI-generated code alongside the defenses that address them.
Stop slopsquatting before it reaches your build
The most effective place to stop a slopsquatted package is the moment a developer tries to install it, before the install script ever runs. That’s what Xygeni Shield does. Shield is a lightweight agent on the developer’s endpoint that blocks malicious packages at install time, using Malware Early Warning (MEW) verdicts that work before any signature exists. When an AI assistant suggests a hallucinated dependency and the developer runs install, Shield evaluates the package as it’s fetched and blocks it: the malicious post-install script never executes, and the security team sees the attempt with full context.
Because MEW scores a package’s behavior the moment it’s published (install-time actions, network calls, obfuscation patterns), Shield catches exactly the brand-new, no-signature-yet packages that slopsquatting depends on, along with typosquatting, dependency confusion, and maintainer compromise. Every block flows into the same Xygeni console as your code, build, and runtime findings, so there’s no new dashboard and no new vendor relationship, and Shield runs alongside your existing EDR, not against it.
Start free. Xygeni’s Developer plan is €0: 10 repositories, 200 scans a month, up to 5 contributors, no credit card. Sign up with GitHub, GitLab, or Google and run your first scan in under 10 minutes; Shield endpoint protection is coming to the Developer plan soon.
FAQ
Is slopsquatting a real threat or just theoretical?
It’s real. A 2023 proof of concept by researcher Bar Lanyado saw a placeholder package under a hallucinated name (huggingface-cli) downloaded more than 30,000 times in three months. A USENIX Security 2025 study found that 19.7% of AI-recommended packages don’t exist, and 43% of those hallucinated names repeat across prompts, meaning attackers can predict and register them.
What’s the difference between slopsquatting and typosquatting?
Typosquatting exploits human typos by registering misspellings of popular packages (reqeusts for requests). Slopsquatting exploits AI hallucinations by registering the confident but wrong package names that large language models invent. Both aim to trick a developer into installing a malicious package, but the mistake they weaponize is different.
Can I trust AI coding assistants to suggest dependencies?
Not without verification. Even leading commercial models hallucinate packages that don’t exist around 5% of the time, and newer analysis found nearly 28% of dependency-upgrade suggestions from a current model were hallucinated. Always confirm a suggested package genuinely exists and is legitimate before installing it.
How do I protect my codebase from slopsquatting?
Verify AI-suggested packages before installing, detect malware by behavior at publish time rather than waiting for a signature, put a dependency firewall between developers and public registries, and maintain an AI-BOM inventory of the AI tools and agents running in your pipeline.
