If you use Cursor, GitHub Copilot, Windsurf, or any of the current crop of AI coding agents that can run shell commands, the way your assistant resolves a repository name is a security boundary. It should not be. A new attack called HalluSquatting, published July 8, 2026, by researchers at Tel Aviv University, Technion, and Intuit, exploits the fact that large language models routinely fabricate the exact identifiers for repositories and "skills" they are asked to fetch, hallucinating the correct location up to 85 percent of the time for popular repos and 92.4 percent for those published in 2025. Attackers can predict those fabricated names, register them, seed them with malicious instructions, and wait for agents to pull them down and execute the payload with terminal privileges. The result is the first prompt-injection technique that scales to mass botnet assembly, distributed denial-of-service, and ransomware deployment without individually targeting a single victim.
Coding agents that run shell commands are now an attack surface for distributed botnets.
What is HalluSquatting and how does the attack chain work?
HalluSquatting, short for adversarial hallucination squatting, is a pull-based prompt-injection attack. The researchers, Aya Spira, Elad Feldman, Avishai Wool, and Ben Nassi of Tel Aviv University, Stav Cohen of Technion, and Ron Bitton of Intuit, published their findings in a paper on July 8, 2026. The attack exploits a fundamental flaw in how LLMs resolve resource identifiers, the exact paths and slugs for repositories and agent "skills" they are told to clone or install.
The attack chain works in four steps. First, the attacker identifies trending repositories or skills that are newly popular and therefore absent from the LLM's training data. Second, they predict the fabricated identifier the LLM will produce when a user asks for the resource, using predictable hallucination patterns common across all major models. Third, they register that predicted name on the relevant platform and upload a package or repository containing a malicious payload, such as a reverse shell installer hidden in a readme file or script. Fourth, they wait. When any developer using a susceptible coding agent asks their assistant to clone the trending repo or install the skill, the LLM hallucinates the fabricated slug, pulls the attacker's version, and the agent executes the payload using its integrated terminal access.
The researchers confirmed the attack works against nine popular AI coding tools: Cursor, Cursor CLI, Gemini CLI, Windsurf, GitHub Copilot, Cline, OpenClaw, ZeroClaw, and NanoClaw. The common denominator is that all of them grant the LLM access to a command line where third-party code can run. As the researchers wrote in their paper, "By exploiting integrated shells and terminals of agentic applications to run scripts and code, attackers can effectively 'infect' many independent agentic applications by embedding instructions to install reverse shells in the resources the attackers register."
The technique is a pull-based attack, meaning the attacker does not push a malicious email or calendar invite to a specific target. Instead, the attacker plants the payload at a predicted location and waits for LLM agents to pull it down themselves. This is what makes it scale. Previous prompt-injection attacks required per-victim targeting, limiting their reach. HalluSquatting requires only that a developer, somewhere, asks their coding agent to fetch a trending resource.
How often do LLMs hallucinate repository names, and is it predictable?
This is the part that should make you stop shipping coding agents without guardrails. The researchers tested six major LLMs: Gemini-2.5-flash, Gemini-2.5-pro, GPT-5.1, GPT-5.2, Sonnet-4.5, and Opus-4.5. Every single one hallucinated repository identifiers at high rates for trending resources. For cloning a popular repository, the LLM hallucinates its correct location up to 85 percent of the time. For cloning a trending skill, hallucinations occur 100 percent of the time.
The chart above shows the hallucination rate broken down by repository age. For repositories published before 2019, the six models correctly resolved the identifier with a low mean hallucination rate of just 0.9 percent. Those repos are in the training data. For repositories published in 2025, the mean hallucination rate jumps to 92.4 percent, because the LLM has never seen them and is guessing.
Critically, the hallucinations are predictable. All six models follow common patterns when resolving a repository or skill name. The specific pattern HalluSquatting exploits is described as self-referential: the models produce slugs in the format repo-name/repo-name, treating the repository name as if it were the owner. This pattern requires no model probing. An attacker can compute the likely hallucinated slug for any trending repo, register it, and seed it with a payload before the first developer asks their agent to clone it.
The researchers also note that the hallucination problem is foundational. It arises from training biases and from misinterpretations of instructions within the current context window. There is no patch that makes an LLM reliably say "I don't know" when asked for a repository slug it has never seen. The models are built to produce a confident answer, and that answer is frequently wrong.
Why does this turn prompt injection into a botnet problem?
Until HalluSquatting, prompt injection was a targeted attack. The most common class, known as push-based injection, requires the adversary to send a malicious prompt to each individual victim, via email, calendar invite, or document. The scale is limited by the number of targets the attacker can reach. Pull-based attacks, where the LLM seeks out adversarial prompts planted on websites, existed but had no efficient mechanism to lure large numbers of agents to a malicious site.
HalluSquatting changes the math. The attacker does not need to target anyone. They register a predicted hallucinated name, seed it, and wait for the global population of coding agents to pull it down. Every developer who asks Cursor or Copilot to "clone that trending repo" becomes a potential infection point, without the attacker knowing or caring who they are.
The researchers spelled out the downstream consequences in their paper: "Gaining access to distributed computational resources under attacker control opens the door to several high impact outcomes allowing attackers to achieve various goals. For example, having the ability to compromise LLM applications with terminals allows the attacker to scale the number of ransomware attacks on different networks to maximize financial gain. Alternatively, attackers can aggregate compromised machines into a botnet and use it for tasks that rely on substantial computing power, including (1) large-scale cryptocurrency mining (e.g., Smominru, WannaMine) or (2) performing distributed denial of service (DDoS) attacks against victims (e.g., Mirai)."
This is the first prompt-injection technique with a credible path to indiscriminate mass infection. The bottleneck was never the payload, it was the delivery mechanism. HalluSquatting solves the delivery problem by turning the LLM's own confidence into the delivery vector.
Which nine coding agents are vulnerable, and what is the common denominator?
The researchers confirmed susceptibility in nine tools: Cursor, Cursor CLI, Gemini CLI, Windsurf, GitHub Copilot, Cline, OpenClaw, ZeroClaw, and NanoClaw. The full list and attack methodology are documented in the HalluSquatting paper and covered in detail by Ars Technica.
The common denominator is terminal access. Every one of these tools grants the LLM the ability to execute shell commands. That is the feature that makes them useful, the ability to clone, install, build, and run. It is also the feature that makes them dangerous when the LLM pulls from the wrong source.
| Agent | Shell Access | Vulnerable to HalluSquatting |
|---|---|---|
| Cursor | Yes | Yes |
| Cursor CLI | Yes | Yes |
| Gemini CLI | Yes | Yes |
| Windsurf | Yes | Yes |
| GitHub Copilot | Yes | Yes |
| Cline | Yes | Yes |
| OpenClaw | Yes | Yes |
| ZeroClaw | Yes | Yes |
| NanoClaw | Yes | Yes |
The fix is not trivial. You could remove shell access, but then the agent cannot do its job. You could restrict the agent to a whitelist of trusted repositories, but that breaks the workflow of cloning a new trending repo that is not yet on the list. The fundamental issue is that the LLM cannot reliably distinguish between the correct resource and a hallucinated one, and the agent has no independent verification layer.
Independent researcher Johann Rehberger, who reviewed the research, wrote: "What's interesting is that it shows that LLM resource resolution can become an attack path and an attacker can first probe models to find high-probability hallucinated candidates (like repo names, skill identifiers, etc) to squat and wait for agents to resolve and use them."
Michael Bargury, CTO of security firm Zenity, called the threat "very real" and added: "Like typosquatting, it's a problem that's not going away. At the end of the day, it's about the level of agency we allow our agents. They are going to get fooled one way or the other. That should be our assumption, and we should be resilient to that."
What does this mean for your codebase, your CI/CD, and your security posture?
If you are building or running AI coding agents in your engineering org, HalluSquatting changes your threat model in three concrete ways.
- Your agent's shell access is now a supply-chain attack vector. Every time your agent clones a repo or installs a skill, there is a chance the LLM fabricated the identifier and pulled an attacker-controlled version. If your agent runs with the developer's permissions, the attacker now has those permissions.
- CI/CD pipelines that invoke coding agents are especially exposed. If your pipeline uses an agent to fetch dependencies or resolve repositories without pinning exact URLs or hashes, a hallucinated slug can inject a reverse shell into your build environment. The blast radius is the pipeline's service account, not a single laptop.
- The attack scales without targeting you. Previous supply-chain attacks required the attacker to get you to install a specific malicious package. HalluSquatting requires only that your agent tries to fetch a trending resource the LLM has never seen. You do not need to be the target to be the victim.
This connects to a broader pattern we have been tracking. If you read our earlier analysis on vibe coding's security publish gate, the concern was that AI-assisted coding was shipping code without sufficient review. HalluSquatting raises the stakes: the problem is not just what the LLM writes, it is what the LLM fetches.
The practical implications for a builder right now:
- Pin your dependencies and repositories by exact URL and commit hash. Do not let the agent resolve names by guessing. If the agent cannot find the exact resource, it should fail, not fabricate a path.
- Run coding agents with minimal privileges. If the agent does not need network access or write permissions for a task, do not grant them. Treat the agent's terminal like any other untrusted code execution environment: sandboxed, ephemeral, and scoped.
- Audit which agents in your org have shell access. The nine tools listed in the paper are the ones tested. Any agent with a similar architecture, an LLM resolving resource names and executing commands, is likely vulnerable.
Should you pull shell access from your coding agents today?
The honest answer is: not yet, but you should change how you grant it.
Removing shell access from coding agents guts their utility. The entire value proposition of Cursor, Copilot, and their peers is that they can clone, build, run, and debug in a terminal. If you take that away, you have a chatbot that suggests code snippets. The productivity gain collapses.
But you can and should restructure the trust. The researchers did not release a proof-of-concept tool, but the attack methodology is fully described in the paper and reproducible by anyone who can register a GitHub repository or publish to a package registry. The window between "trending repo appears" and "attacker registers the hallucinated slug" is short. Your defense cannot be "we hope the attacker did not get there first."
The strongest immediate mitigation is a verification layer between the LLM's output and the shell. When the LLM produces a repository identifier, the agent should resolve it against an allowlist or a verified registry before executing a clone or install command. If the identifier is not found or does not match the expected pattern, the agent should prompt the user for confirmation, not guess.
Longer term, the fix has to come from the model layer. The researchers note that the hallucination problem is foundational across all six major LLMs they tested. No amount of agent-level guardrails fully solves a model that confidently fabricates identifiers 92.4 percent of the time for recent repos. The models need a reliable "I don't know" response for resource resolution, and the agents need to treat that response as a hard stop, not a prompt to guess.
Until that happens, treat every resource fetch by a coding agent as untrusted input. If you would not let a random script from the internet run in your terminal with your permissions, you should not let an LLM do it either.
The real cost of agentic convenience
HalluSquatting is a reminder that every productivity gain from AI coding agents carries a security tax. The same shell access that lets Cursor clone a repo and run a build is what lets a hallucinated slug install a reverse shell. The attack does not require a zero-day or a sophisticated social engineering campaign. It requires an LLM that cannot say "I don't know" and an agent that trusts it implicitly.
The researchers have drawn the blueprint. The question for every team shipping AI-assisted code is whether they have a verification layer between the model's confidence and the terminal's execution. If they do not, the next trending repo your agent clones might not be the one you asked for.
