The AI that writes your code is also writing attack vectors
A coding assistant tells you to install jwt-secure-validator. Sounds reasonable. Professional name, does exactly what you need. You paste the import, run pip install, and move on with your day.
Except that package never existed until an attacker read the same AI output you did and registered the name on PyPI first.
That's slopsquatting. And it's one of the most deceptively simple AI cybersecurity threats to emerge from the generative AI wave — not because it requires sophisticated tooling, but because it exploits something we can't easily engineer away: developer trust in the tools we use every day.
How slopsquatting works
The term was coined by Seth Larson, a security developer-in-residence at the Python Software Foundation, as a deliberate riff on typosquatting. Classic typosquatting bets on your fat fingers — you type reqeusts instead of requests, and the attacker's package catches you mid-keystroke.
Slopsquatting is different. It doesn't need you to make a mistake. The AI makes the mistake for you.
Here's the full chain:
- An LLM hallucinates a package name that sounds plausible but doesn't exist on any registry
- A developer trusts the suggestion without verifying
- An attacker observes which names models hallucinate repeatedly
- The attacker registers that name on PyPI or npm
- The next developer who follows the same AI suggestion installs malware
The attack doesn't require the developer to do anything wrong. The AI confidently recommends a non-existent dependency, and that's enough.
What the research actually shows
A research paper published in March 2025 by teams from the University of Texas at San Antonio, Virginia Tech, and the University of Oklahoma examined 16 code-generation models and analyzed 576,000 generated Python and JavaScript code samples. The headline finding: roughly 20% of recommended packages simply didn't exist.
That number gets worse for open-source models like CodeLlama, DeepSeek, WizardCoder, and Mistral. Commercial tools do better but still fail — ChatGPT-4 hallucinated package names at around 5%. Five percent sounds low until you multiply it across millions of developers shipping code every day.
The Socket security team, which analyzed the same research, found something more troubling than the raw rate. Hallucinated package names aren't random noise. They're repeatable. In their analysis, 58% of hallucinated packages appeared more than once across ten runs of the same prompt.
"That repeatability increases their value to attackers, making it easier to identify viable slopsquatting targets by observing just a small number of model outputs," the Socket researchers explained.
Break down where the hallucinations come from: 49% appeared inspired by real packages (plausible-sounding names adjacent to legitimate libraries), 13% were typos the model produced, and 51% were completely fabricated from scratch. That last group is the scariest — there's no real package to compare against, no obvious sign something's off.
Why this is a complete supply chain problem
The architecture makes this worse than it looks. Python's PyPI and JavaScript's npm are centralized registries. First-come, first-served naming. If a name is available, anyone can claim it.
The reliance of these ecosystems on open-source packages combined with code-generating LLMs creates what the academic team called "a new type of threat to the software supply chain." The attack surface is enormous and growing every day developers adopt AI coding assistants.
What makes slopsquatting particularly insidious isn't technical complexity. It's psychological. We naturally trust AI suggestions, especially when the output looks professional and solves our immediate problem. Attackers who create malicious packages in this space know this. They build packages that include functional code alongside malicious payloads — the library actually works, which defeats any casual inspection you might do after installation.
There's currently no public evidence that attackers have weaponized this technique at scale yet. But the Socket researchers are blunt about the trajectory: "If a single hallucinated package becomes widely recommended by AI tools, and an attacker has registered that name, the potential for widespread compromise is real. And given that many developers trust the output of AI tools without rigorous validation, the window of opportunity is wide open."
Securing your development practices against AI-assisted attacks
You can't stop LLMs from hallucinating package names. What you can do is build guardrails between AI output and your production systems. Here's a practical defense-in-depth approach for 2026.
Verify every package name manually. This is the single most effective control. If an AI tool suggests a dependency, search the registry yourself. Check the publisher. Look at download counts. Look at when it was created — a package that appeared last week with a name that sounds too perfect for your use case deserves scrutiny.
Lower your AI temperature settings. The research found that reducing randomness in model output reduces hallucinations. If you're doing AI-assisted development, this is a one-line configuration change with meaningful security impact.
Pin everything with lockfiles and hash verification. Lockfiles pin packages to exact versions. Hash verification ensures the package you install matches the package you expected. These aren't new ideas, but they matter more now that your "source of truth" might be an LLM's confident fabrication.
Use dependency scanners. Tools like Socket, Snyk, and others have started building detection capabilities specifically for suspicious package characteristics — recent creation dates, minimal download counts, names that closely mirror commonly hallucinated patterns.
Test in isolated environments first. Never run AI-generated code directly in production or on a machine with access to credentials and secrets. Run it somewhere safe first.
The organizational layer
Individual practices aren't enough. Security teams need to update their threat models to account for AI-generated code as an input vector. That means automated policies flagging packages with suspicious characteristics, regular dependency audits that don't assume every dependency was intentionally chosen by a human, and security training that explicitly covers AI-assisted risks.
Platforms like GitHub and PyPI have started adding time-based defenses — delays between package publication and availability for download, which creates a window where detection systems can flag suspicious new packages before developers can install them.
The npm ecosystem already sees its share of supply chain attacks; Amazon's analysis of npm supply chain threats shows how quickly attackers adapt to new vectors. Slopsquatting is just the latest adaptation.
The real threat
What keeps me up about slopsquatting isn't the attack technique itself. It's that it inverts our assumptions about tooling. For years, we've treated developer tools as trusted inputs — the IDE, the package manager, the documentation. AI assistants are trusted tools now. Billions of lines of AI-generated code flow into repositories every month.
When a trusted tool confidently recommends something that doesn't exist, and an attacker fills that void with something malicious, we've built a supply chain attack into the development workflow itself. No phishing email. No social engineering call. Just a developer copying code from a tool they trust, following instructions from a tool they trust, and landing on a package name that only existed because a model made it up.
The defenses exist. They're straightforward. Most organizations haven't deployed them. That gap between known and done is where the real risk lives.
