The rise of AI-assisted coding has introduced a novel and insidious threat to software supply chains: slopsquatting. This attack vector exploits the tendency of large language models (LLMs) to hallucinate fictitious software package names, which malicious actors can then register and populate with malware. By targeting the very tools developers trust to boost productivity, slopsquatting enables cybercriminals to inject malicious code directly into development workflows from the outset, often without detection.
What is slopsquatting and how does it work
Slopsquatting combines the concepts of “AI slop”—low-quality, hallucinated outputs—and “typosquatting,” the long-standing practice of registering misspelled domain names to deceive users. In this new variant, attackers exploit LLMs’ tendency to generate plausible but non-existent software package names during code generation. When a developer’s AI assistant recommends a package that does not actually exist, a threat actor can register that name on a public registry and fill it with malicious code. If the developer installs the package without verification, the malware becomes part of the codebase, compromising the entire supply chain.
Traditional typosquatting relies on simple misspellings of popular packages, and registries have built defenses against these obvious deceptions. Slopsquatting bypasses these protections because the hallucinated names are not typo variants of known libraries. For instance, while a registry may block an attempt to publish “crossenv” as a squat of the legitimate “cross-env” package, it would not flag “cross-env-extended” or “mpn install cross-env file” as threats, even though these names originate from an AI’s hallucination.
Why AI hallucinations create a supply chain vulnerability
AI safety risks have traditionally centered on hallucinations producing misinformation that misleads users. Slopsquatting transforms that reliability problem into a security liability. When an LLM recommends a package that sounds plausible but does not exist, it opens a door that attackers can walk through.
Because hallucinated packages are not simple misspellings, existing registry protections offer little defense. Attackers can study which packages popular models tend to invent, register those names, and publish malware-filled versions. The models, believing they are referencing real dependencies, often repeat the same hallucinated names, creating a predictable attack surface that can be exploited at scale.
Hallucination rates remain alarmingly high
Hallucinations are not rare anomalies. One study found hallucination rates ranging from 50 percent to 82 percent depending on the model and prompting method. Even GPT-4o, the best-performing model evaluated, achieved no lower than a 23 percent hallucination rate with prompt-based mitigation. This means that even the most reliable models still fabricate package names a significant portion of the time, providing ample opportunity for attackers.
Research analyzing 31,267 vulnerabilities across 14,675 packages in ten programming languages found that reported vulnerabilities are increasing at an annual rate of 98 percent, far outpacing the 25 percent annual growth in the number of open-source packages. The same study observed an 85 percent increase in the average lifespan of vulnerabilities, indicating that security is declining even as the ecosystem expands.
Which LLMs are most vulnerable to slopsquatting
Not all models pose the same level of risk. Proprietary models are approximately four times less likely to generate hallucinated packages compared to open-source models. In a large-scale study involving 576,000 code samples and 2.23 million generated packages across 30 systems, 19.7 percent of all package recommendations were hallucinations. GPT-4 Turbo had a hallucination rate of 3.59 percent, while DeepSeek 1B, the best-performing open-source model tested, reached 13.63 percent.
This disparity means that organizations relying on open-source AI tools for code generation are roughly four times more exposed to slopsquatting attacks. However, that gap may not persist. As attackers become aware of the relative trust placed in proprietary models, they may shift tactics toward manipulating those models through adversarial hallucination techniques, such as token-level manipulation or retrieval poisoning, to force hallucinations that favor their malicious packages.
Vibe coding and the expanding attack surface
The rise of “vibe coding”—the practice of generating code through AI assistants with minimal manual oversight—amplifies the slopsquatting threat. Software developers who use AI tools estimate that over 40 percent of the code they commit includes AI assistance, and that percentage is expected to grow considerably. Already, 72 percent of developers who have tried AI coding tools use them daily.
As more developers integrate AI into their workflows without implementing rigorous verification processes, the attack surface for slopsquatting expands. The issue is compounded by the fact that hallucinated package names often appear legitimate. They may differ from real libraries by a single character, resemble reasonable extensions of existing tools, or include fully fabricated names that the AI presents with enough contextual authority to evade suspicion. Developers trust their assistants, and that trust is precisely what makes the attack effective.
How slopsquatting attacks actually manifest
In a typical slopsquatting scenario, a developer asks an AI assistant to recommend a package for a specific task. The model generates a name that sounds authoritative and relevant. The developer, working under time pressure and trusting the tool, runs the installation command without verifying that the package exists in an official registry. The attacker has already registered that name and populated it with malware, which is now installed in the developer’s environment.
Because the attack does not rely on misspelling a known package, it evades the automated safeguards that registries have built against typosquatting. Malicious packages can remain undetected in production for months or even years, allowing threat actors to maintain persistent access across countless environments. The damage is not limited to the developer’s machine—it propagates through the entire supply chain to end users.
Defending against slopsquatting in AI-assisted development
Developers and organizations can take practical steps to reduce their exposure to slopsquatting attacks. The most fundamental defense is verification: any package recommended by an AI assistant should be checked against official repositories before installation. This simple step catches the vast majority of hallucinated packages.
Security teams should implement automated checks that validate package names against known registries as part of the CI/CD pipeline. Monitoring for unusual package installations and maintaining up-to-date threat intelligence on known slopsquatting campaigns provides an additional layer of defense. Organizations should also evaluate the hallucination rates of the models their developers use and consider whether the productivity gains of open-source models outweigh the increased security risk.
What this means for developers and security teams
Slopsquatting represents a convergence of AI reliability failures and supply chain security threats that is only beginning to receive attention. As AI coding assistants become more deeply embedded in development workflows, the attack surface will continue to grow. Developers who treat AI recommendations as authoritative without verification are the primary vector for these attacks, and changing that behavior is the single most effective mitigation.
The forward-looking implication for security teams is clear: AI-assisted code generation requires human oversight and automated validation, not blind trust. Organizations that treat AI outputs as unverified suggestions rather than final answers will be significantly more resilient to slopsquatting and similar hallucination-based attacks. The technology is not going to become less prone to hallucination overnight, so the responsibility falls on developers and security teams to adapt their practices accordingly.
