Investigation · Supply Chain Security
Slopsquatting: The Invisible Supply Chain Attack Hiding in Your AI Prompts
A developer pastes one innocent install command from their AI assistant. Three days later, the company's database credentials are on the dark web. No typo. No malicious script. Just a package that didn't exist until an attacker read the AI's mind.
In this article
A senior developer is facing a tight deadline to build a data integration pipeline. To save time, they turn to their trusted AI coding assistant and ask for a script.
The AI generates flawless code and confidently instructs the developer to run a simple command: npm install secure-json-validator. The developer copies the command, pastes it into their terminal, and hits enter. The package downloads, the code works perfectly, and the developer ships the feature.
Three days later, the company's private database credentials are found for sale on the dark web.
The company's antivirus didn't flag anything. The developer didn't misspell the package name. The AI assistant didn't write a malicious script. So how did the hackers get root access?
Welcome to the era of slopsquatting — a term coined by Python Software Foundation Developer-in-Residence Seth Larson — which represents a terrifying new evolution of the software supply chain attack. Hackers don't need to break into your servers. Instead, they just have to predict your AI's next hallucination.
The Evolution of the Trap: From Typos to Hallucinations
To understand the severity of this threat, we have to look at its predecessor: typosquatting. For over a decade, attackers have uploaded malware to open-source registries under misspelled names — like react-ruter instead of react-router — hoping a tired developer would make a typo.
But typosquatting relies on human error. Today's registries have built-in defenses to catch these misspellings.
Slopsquatting bypasses these defenses entirely because it relies on machine error. Large Language Models (LLMs) are probabilistic engines; they predict the next logical word in a sequence. When you ask an AI to write code for a highly specific task, it will often invent — or hallucinate — a software package that sounds like it should exist.
The AI confidently outputs pip install fastparserx. The problem? It isn't a real package. Or, at least, it wasn't until yesterday.
Typosquatting attacked humans. Slopsquatting attacks machines — and every developer who trusts them.
The Anatomy of a Slopsquatting Attack
Cybercriminals have realized that different AI models frequently hallucinate the exact same fictional package names when given similar prompts. A USENIX Security study on AI package hallucinations found that a substantial share of invented names repeat consistently across multiple runs of the same prompt — which is what makes the attack predictable enough to industrialise.
The attack unfolds in three silent phases.
Phase 1: The AI Interrogation
Attackers run thousands of automated prompts through popular AI coding assistants, asking them to solve common programming tasks. They harvest a list of phantom dependencies — fictional packages the AI reliably invents.
Phase 2: The Land Grab
The attackers rush to package registries like npm (JavaScript) or PyPI (Python) and register these hallucinated names. They fill the packages with legitimate-looking code that actually performs the function the AI described — but they also bury a malicious payload deep inside the file structure.
Phase 3: The "Vibe Coding" Exploit
A legitimate developer asks their AI assistant for help. Because developers trust their AI tools, they copy and paste the install command without verifying the library's history. The malicious package is downloaded, and the attacker gains access.
The attack does not require the AI to be wrong. It only requires the AI to be confident.
Real-World Evidence: It's Already Happening
This is not a theoretical threat. Several documented incidents show the pattern in the wild.
- The huggingface-cli experiment: A security researcher registered an AI-hallucinated package under the name
huggingface-cli, a name that AI assistants had been confidently inventing. Within three months, it received tens of thousands of authentic downloads from corporate environments — every one of them from developers who believed they were installing an official tool. - The Alibaba repository leak: Developers at Alibaba were caught blindly copy-pasting a hallucinated install command directly into the README of one of their public GitHub repositories. The command referenced a package that did not exist at the time it was published — meaning anyone who followed the instructions would install whichever package an attacker registered first.
- Malicious packages on npm: Security researchers have repeatedly identified packages on public registries that exist only because AI models suggested their names. Some are harmless typos. Others carry credential stealers, reverse shells, or telemetry beacons.
The pattern is consistent. The AI writes an install command that reads as authentic. The developer trusts it. The registry has no way to distinguish a real package from one that was registered yesterday to catch a hallucinated name.
Why Traditional Security Scanners Are Blind
If a developer installs malware, shouldn't the company's Software Composition Analysis (SCA) tool catch it?
Not necessarily.
Standard security tools look for known vulnerabilities — CVEs. Because a slopsquatted package is brand new, it has no reported vulnerabilities. To a traditional vulnerability scanner, a package registered 24 hours ago by an anonymous user looks perfectly clean, allowing the Trojan horse to march right past enterprise firewalls.
| Signal | Legitimate Package | Slopsquatted Package |
|---|---|---|
| Registration Date | Months to years old | Days or hours old |
| Source Repository | Linked GitHub/GitLab with commit history | Often missing, or a placeholder repo |
| Download Count | Organic growth over time | Artificially inflated by bots |
| CVE History | May have reported issues, publicly tracked | None — the package is too new |
| Publisher Profile | Established maintainer with multiple packages | Anonymous, single-purpose account |
| Post-Install Scripts | Minimal or none | Often present and undocumented |
Traditional SCA tools are built for a world where malicious packages have histories. Slopsquatting produces packages with no history at all — and the scanners do not know what to do with them.
How to Fortify Your Development Pipeline
Protecting your organisation from AI package hallucinations requires a fundamental shift in how you trust open-source dependencies. You cannot train an AI to stop hallucinating entirely, so you must build zero-trust verification into your workflow.
1. Treat Autonomous Installs as Privileged Operations
If you are using AI agents that can execute code autonomously — such as agentic CI pipelines or advanced AI IDEs — you have removed the human verification step. Scope the permissions of these autonomous agents so they cannot install external packages to your global environment without explicit human approval.
2. Verify the Publisher, Not the Download Count
Attackers frequently use bots to artificially inflate the download counts of their malicious packages. When reviewing an AI-suggested library, check the registry data. A package claiming to be an essential security plugin with a registration date of last Tuesday and no GitHub repository history is a massive red flag.
3. Implement Registry API Verification in CI/CD
Add a script to your CI/CD pipeline that queries registry APIs. If your lockfile contains a new package that lacks an established history, the build should pause for manual review. Example pseudo-policy:
# Enforce package age and provenance
- name: Verify new dependencies
run: |
for pkg in $(git diff --name-only HEAD~1 package-lock.json | xargs jq -r '.packages | keys[]'); do
age=$(curl -s https://registry.npmjs.org/$pkg | jq -r '.time.created')
if [ "$age" -lt "$(date -d '30 days ago' +%s)" ]; then
echo "Package $pkg is too new. Manual review required."
exit 1
fi
done4. Scan Your Full Dependency Tree
Hallucinated package names sometimes end up as nested dependencies rather than direct installs, meaning they won't easily surface in your primary package file. Use a comprehensive Software Composition Analysis (SCA) scanner to catch hidden, buried packages — and audit your transitive dependencies, not just your direct ones.
5. Prefer Curated Registries for Critical Systems
Where it is operationally feasible, route production dependencies through a curated internal registry or a vetted mirror rather than pulling directly from public npm or PyPI. This gives your security team a chance to block new, unvetted packages before they reach a developer's machine.
6. Teach Developers That "The AI Suggested It" Is Not Verification
Every developer who uses an AI coding assistant should know what slopsquatting is. The fix is not to stop using AI — it is to treat every install command the AI produces as a suggestion, not an instruction. Verification is cheap. The alternative is not.
The rise of slopsquatting marks a profound shift in software supply chain security. We are no longer just fighting hackers who exploit human mistakes; we are now defending against adversaries who have learned to weaponise the imagination of artificial intelligence.
As we increasingly outsource our coding to autonomous agents, our security posture must evolve from implicit trust to rigorous verification. If an AI suggests a shortcut, take a moment to look at the map — because an attacker might have just built the road.
The AI is not the attacker. The AI is the reconnaissance tool the attacker uses to find the names you will install tomorrow.
Frequently asked questions
Does slopsquatting only affect JavaScript and Python?
No. While npm and PyPI are the most common targets due to their massive size, slopsquatting affects all ecosystems that use public, centralised registries — including RubyGems, Go modules, and Rust's Cargo crates. Any ecosystem where an AI can generate code is at risk.
If the AI generates the code, why can't it verify the package exists?
Most standard AI coding assistants operate entirely offline during the text-generation phase. They are predicting text based on patterns in their training data, not making live internet queries to package registries. By the time the AI outputs the response, it has no mechanism to double-check whether the package is real.
Will upgrading to a better AI model fix this?
While proprietary models have a slightly lower hallucination rate than some open-source alternatives, the risk is never zero. As long as LLMs remain probabilistic, they will occasionally invent dependencies. Security must happen at the pipeline level, not just at the prompt level.
How is slopsquatting different from typosquatting?
Typosquatting relies on the developer making a spelling mistake — like typing reqeusts instead of requests. Slopsquatting relies on the AI generating a name that has never existed at all. The developer did not make a mistake; the AI did. And because the developer trusts the AI, they install whatever it suggests.
What should I do if I discover a slopsquatted package in my codebase?
Immediately remove the package from your lockfile, revoke any secrets or tokens that were accessible from the machine that installed it, and audit for outbound network connections or unusual process activity around the time of installation. Then run a full credential rotation and notify your security team. Assume the package did whatever it was designed to do.
Are AI coding assistants completely unsafe to use?
No. AI coding assistants remain genuinely useful and, for many tasks, meaningfully faster than manual coding. The problem is not the assistant — it is the assumption that everything it produces has been verified. Treat install commands the way you would treat a suggestion from an anonymous Stack Overflow answer: useful, but not authoritative.