Slopsquatting: The Security Injection Attack That Exploits Hallucinations in AI Code Assistants

In January 2026, security researcher Charlie Eriksen of Aikido Security registered the react-codeshift package on npm—a name he hadn’t created and that had never been published before. This package was a figment of the imagination created by merging two real libraries, jscodeshift and react-codemod, and then spread to 237 GitHub repositories via instruction files (Agent Skills) generated by language models. After it was registered, automated agents began attempting to install it on a regular basis, demonstrating that a package name invented by AI could quickly make its way into real-world environments.  

This episode illustrates “slopsquatting,” a supply chain attack in which a malicious actor registers nonexistent packages—often suggested by AI tools—in order to trick developers or IT staff into installing them.

Attack Mechanism: A Cybersecurity Risk That Exploits the Predictability of LLMs

A language model does not systematically check whether a dependency exists in a registry such as npm or PyPI before recommending it: it generates a probabilistic response and can thus produce a plausible but nonexistent package name. This error becomes particularly exploitable when it recurs. In their study, Joseph Spracklen and his co-authors reran 500 prompts—each of which had previously led to package hallucinations—ten times: 43% of the invented names reappeared in every run, and 58% appeared at least twice.  

This persistence means that an attacker does not need to guess a random name: they can probe a model, identify the fictitious dependencies that appear regularly, and then register them in a public registry before a developer or deployment agent attempts to install them.

Extent of the Problem and Hallucination Rates According to LLM Models (Claude, GPT, Gemini, DeepSeek)

The landmark study by Spracklen et al., presented at USENIX Security 2025, reveals some particularly striking figures. By analyzing 576,000 code samples generated by 16 models, the researchers found that nearly 20% of the recommended dependencies did not exist—that is, more than 440,000 names out of 2.23 million.

The trend is even more pronounced in the open-source sector, with an average rate of 21.7 percent, compared with 5.2 percent for commercial models.

A replication published in 2026 by Aleksandr Churilov’s study, which examines several recent models (Claude, GPT, Gemini, DeepSeek), shows a relative improvement: the observed rates range from 4.62% to 6.10%. The gap between models has thus narrowed, but the problem remains significant. On a large scale, even a few percentage points represent a significant volume of fictitious dependencies.

The initial study also highlights another risk: confusion between ecosystems. Approximately 8.7% of the “hallucinated” Python packages actually correspond to existing packages on npm. In practice, a developer might be redirected to a dependency for another language or, worse, to a malicious package uploaded by an attacker under the same name.

Real-world cases and documented vulnerabilities: from malicious npm/PyPI packages to HalluSquatting

A telling example, documented by Bar Lanyado (Lasso Security), illustrates the problem well: several language templates recommended installing a Python package named huggingface-cli. Problem: this package did not exist. The official method actually relied on  huggingface_hub, which provides the CLI (now accessible via the command hf).

To measure the actual impact of this error, the researcher released an empty package named huggingface-cli on PyPI. The result: more than 30,000 downloads in three months, with no malicious content. His analysis then showed that this incorrect recommendation had been copied into the documentation for a public research project linked to Alibaba (GraphTranslator). In other words, an AI hallucination can end up in real code and be executed by developers.

A more recent case illustrates a worrying escalation. A malicious npm package named unused-imports, suggested by algorithms in place of the legitimate package eslint-plugin-unused-imports, continued to be downloaded despite a security block, with approximately 233 weekly installations in early 2026 (Cloud Security Alliance).

This type of attack is part of a technique known as HalluSquatting. The concept: exploiting AI’s predictable hallucinations to create booby-trapped packets or resources. In agent-based environments, the risk is even higher: an agent can retrieve these resources and execute malicious instructions, paving the way for compromises or even remote code execution.

Mitigating Slopsquatting: A Rigorous Chain of Trust, Not Blind Automation

• Always verify packages before installation: never run an installation command suggested by an AI without confirming that the package actually exists in the target registry (PyPI, npm, crates.io, etc.). In particular, you should verify the maintainer, release date, version history, and, when relevant, download statistics. This verification can be automated in CI/CD pipelines to block builds when a dependency is unknown, newly released, or does not comply with security policies.
• Require human approval for new dependencies: When an autonomous code agent proposes or adds a library, its installation should not be executed automatically. Human approval is necessary to verify that the dependency actually meets the need and that it is the correct package. An explicit step to review dependencies in pull requests can, in particular, help identify package names that are plausible but nonexistent or suspicious.  
• Monitor recently published packages: An unknown dependency within the organization that was recently registered warrants special attention before it is integrated into production. Checks can flag very recent packages, those with few downloads, or those associated with maintainers who lack an established track record. Their owner, version history, documentation, and source repository must then be verified before approval.  
• Prioritize a whitelist for critical projects: rather than allowing any dependency suggested by a code assistant by default, organizations can maintain an internal catalog of approved packages and versions. For sensitive environments, direct access to public registries can be restricted in favor of an internal repository serving as a control point. Any new dependency must then be validated before it can be used by a developer or AI agent.  

To learn more, see our guide to AI architectures and risk vectors to understand how this risk vector fits into the supply chain risks specific to AI.

FAQ: AI Security and Development Agents

AI Audits and Penetration Testing: Securing Your DevSecOps Software Supply Chain

Our experts assess the vulnerability of your development pipelines to phantom dependencies and test the resilience of your code agents as part of our AI-powered penetration testing service. Would you like to discuss your project or assess your needs? Contact our experts.