Infectious Hallucinations: Slopsquatting and New Supply Chain Attacks in the Age of AI Agents

Introduction

The integration of coding agents based on large language models (LLMs) has reached a point of no return: tools like GitHub Copilot, Cursor, or Gemini CLI write code, install dependencies, and even execute commands autonomously. This very autonomy conceals a systemic vulnerability that three recent campaigns—dubbed Slopsquatting, Phantom Squatting, and HalluSquatting—have brought to light. The mechanism is as simple as it is devastating: models “hallucinate” identifiers (package names, domains, repositories), and if an attacker has registered them in advance, the agent executes malicious code without any human interaction. No phishing, no credential theft: just the statistical predictability of hallucinations.

Technical Analysis

A research team led by Ben Nassi (Tel Aviv University, Technion, Intuit) has quantitatively demonstrated the problem: repository requests generated by LLMs can be guessed up to 85% of the time, while for skill installations the rate reaches 100%. This means an attacker can anticipate the non-existent names that a Copilot or Cline will attempt to use, register them, and populate them with malicious payloads. The three attacks exploit the same principle, applying it to different surfaces:

• Slopsquatting (January 2026): the agent suggests a non-existent package to fulfill a request; the name is so “typical” that the attacker has already published it on a public registry (e.g., PyPI, npm) containing malware.
• Phantom Squatting (June 2026): the prediction concerns hallucinated domains or API endpoints; the agent contacts them, downloads scripts, and executes them, believing they are legitimate.
• HalluSquatting (July 2026): it compromises the installation of “skills” or extensions that the AI deems useful to complete the task; here too, the names are pre-computable and ready to host hostile code.

In all cases, the implicit trust in the model turns a hallucination into a deterministic attack vector. And since agents often operate with elevated privileges and within CI/CD pipelines, the damage propagates deeply. The research found that traditional security tools—antivirus, dependency scanners, digital signatures—do not intercept the threat: there is no single infected file to detect, but a workflow that dynamically integrates code from unverified sources, possibly through transitive dependencies of seemingly harmless packages.

Impact

The severity is high, and researchers warn that what has been observed represents the minimum risk level. The predictability of hallucinations allows the construction of fully automated infection chains: register future names, wait for an agent to hook them, and obtain remote code execution without needing to convince a human victim. Immediate consequences include:

• Compromise of development environments, local machines, and CI/CD servers, with access to secrets, source code, and production infrastructure.
• Creation of silent botnets, where thousands of AI agents act as nodes without classic propagation vectors.
• Cascading contamination in software supply chains: a malicious component introduced by a hallucination can be inherited by all projects that depend on that build, bypassing static control policies.
• Difficulty of detection and attribution, because the malicious event blends in with normal agent behavior and leaves no traces of traditional exploits.

Mitigation

Defense requires a paradigm shift: we can no longer blindly trust automatic suggestions, nor limit ourselves to scanning already installed packages. The countermeasures proposed by researchers and companies like ActiveState include:

1. Preventive identifier verification – Before installing, cloning, or executing any resource indicated by an LLM, verify its actual existence and ownership. Queries to official registries, domain ownership checks, and repository reputation checks must become standard operations.
2. “At-source” supply chain governance – Integrate controls that validate everything entering the build before security scans, shifting the focus from post-mortem detection to prevention.
3. Limiting AI agent privileges – Run agents in sandboxes with minimal permissions, prohibit direct access to critical systems, and introduce mandatory human authorization for any action involving code download and execution.
4. Inspection of the entire dependency tree – Often malicious code arrives through unmonitored transitive dependencies. Every branch of the tree must be analyzed, not just the first level, and suspicious changes monitored over time.
5. Early binding – Minimize delayed resolution of AI-generated identifiers. Where possible, use explicitly authorized and verified names before execution, blocking any unintended dynamic lookup attempts.
6. Predictive monitoring – Build lists of names that your models tend to hallucinate in specific contexts. These names can be pre-registered in a dummy internal registry to intercept execution attempts, or added to blacklists to prevent external requests.

FAQ

1. What exactly is slopsquatting and how does it differ from traditional typosquatting?
Slopsquatting exploits language model hallucinations instead of typos. In typosquatting, the attacker registers a name similar to a legitimate one (e.g., “googel.com”) hoping for a human error; in slopsquatting, the name is entirely invented by the model but statistically probable, and the attacker registers it before the agent looks for it, achieving execution without any human error.

2. What are the early signs an organization should monitor to detect such an attack?
Pay attention to requests to domains or package registries for non-existent names generated by AI tools; a spike in attempts toward hallucinated resources may indicate that an agent is executing unauthorized code. Anomalous changes to transitive dependencies or execution of scripts from unknown sources are also red flags.

3. Is disabling automatic execution enough to stay safe?
No, because slopsquatting and its derivatives rely on the AI’s ability to convince the user (or an automated system) to integrate the malicious resource. Even with human oversight, if the suggested name is not manually verified against official registries, a “hallucinated” package could be willingly installed. The most effective mitigation is preventive verification of every identifier, regardless of who presses the execution button.