HalluSquatting: How an AI Hallucination Can Turn Coding Agents Into a Botnet

TL;DR: HalluSquatting weaponizes a familiar AI failure: making up a plausible-looking name. An attacker registers a repository or agent skill that an LLM is likely to hallucinate, fills it with hostile instructions, and waits for an AI agent to fetch it. Researchers demonstrated the chain against nine agentic tools, including popular coding assistants. There is no public evidence of exploitation in the wild, but developers should verify every repository and skill before an agent downloads or runs it.

The dangerous upgrade from “wrong answer” to “wrong action”

An AI chatbot inventing a book title is annoying. An AI coding agent inventing a GitHub address is different: the agent may have a terminal, network access, local credentials, and permission to execute what it retrieves.

That difference is the foundation of HalluSquatting, short for adversarial hallucination squatting. In a paper submitted on July 8, 2026, researchers from Tel Aviv University, Technion, and Intuit showed how predictable hallucinations of repository and skill names can become a scalable delivery channel for malicious instructions. Read the HalluSquatting paper on arXiv

The attacker does not need to email a specific victim, compromise a famous project, or know which developer will be hit. Instead, the attacker registers a fake resource that many models are likely to invent and lets agents come to it.

That is what makes this research timely. The industry spent years treating hallucinations as a quality problem. Once models can clone repositories, install skills, and run commands, the same error becomes a security boundary failure.

HalluSquatting in plain English

Suppose a new open-source tool becomes popular. A developer asks an agent:

Clone the repository for PopularTool and set it up.

The model recognizes the project name but does not reliably know its exact owner and URL. Instead of searching and confirming the official location, it confidently constructs a plausible address:

github.com/plausible-owner/popular-tool

The address looks right, but it is wrong. An attacker has already measured which wrong address models tend to produce, registered it, and placed prompt-injection instructions inside its README or agent configuration.

When the coding agent clones and reads that repository, the hostile text enters the agent’s context. If the agent treats external instructions as trusted and has powerful tools, it may run attacker-controlled commands or expose data.

The research applies the same idea to agent skills. A user asks an assistant to install a skill by name; the model guesses a nonexistent marketplace identifier; the attacker owns that guessed identifier; the assistant downloads the poisoned skill.

The model’s mistake becomes the attacker’s distribution system.

The seven-step attack chain

1. Find a trending target. The attacker watches popular repositories, tools, and agent skills that users are likely to request.
2. Map predictable hallucinations. The attacker repeatedly asks models for the resource location and records the wrong names they generate most often.
3. Register the best candidate. A still-available repository or skill name is claimed by the attacker.
4. Wait for an ordinary request. A developer asks an agent to clone or install the real resource.
5. Let the model guess. Instead of resolving the name through a trusted search or registry, the model generates the attacker-owned identifier.
6. Poison the context. The agent fetches the fake resource and reads adversarial instructions embedded in it.
7. Abuse the tools. The injected instructions attempt to trigger terminal commands, data access, credential theft, persistence, or enrollment into a botnet.

This is a pull-based, untargeted attack. The attacker publishes one trap; unrelated agents can pull it into many different environments.

What the researchers actually found

The headline numbers are alarming, but they need context.

Across the researchers’ experiments, hallucinated resources appeared at rates of up to 85% for repository-cloning scenarios and up to 100% for skill installation. Newer resources were especially difficult because models had less reliable knowledge of their canonical location.

The team tested five coding assistants—Cursor, Cursor CLI, Windsurf, GitHub Copilot, and Cline—plus Gemini CLI and three personal assistants: OpenClaw, ZeroClaw, and NanoClaw. Depending on the tested product, model, version, and scenario, the end-to-end experiments achieved either tool invocation or remote code execution. The researchers report RCE success rates of 20% to 65% for coding-agent scenarios and 40% to 100% for the personal-assistant scenarios they evaluated. See the researchers’ project page and methodology

Those results do not mean every current installation of those products is automatically compromised. The study tested specific versions with controlled prompts and small per-configuration samples. Vendors and marketplace operators were notified before publication, implementation details were redacted, and product behavior may have changed.

It also remains a demonstrated attack technique, not a confirmed mass campaign. At the time of writing, the researchers have not presented evidence that HalluSquatting has been used to create a real botnet in the wild.

The defensible conclusion is narrower and still important: agents across several architectures fetched hallucinated attacker-controlled resources, and some followed the instructions far enough to execute code.

HalluSquatting is not just slopsquatting with a new name

The terms overlap, but the target and execution path are different.

Slopsquatting usually compromises the software supply chain through a fake dependency. HalluSquatting targets the live agent at inference time. The hostile resource does not need to contain a traditional malicious binary; natural-language instructions can be the payload because the agent is both reader and executor.

It also complements prompt injection rather than replacing it. HalluSquatting solves the attacker’s distribution problem: how to get poisoned content into many agents without contacting each victim.

What developers should do today

1. Never let the model invent a clone URL

Open the project’s official website or verified organization page and copy the repository URL from there. GitHub’s own guidance recommends copying the clone URL from the repository page rather than reconstructing it from memory. GitHub: troubleshooting cloning errors

For an existing checkout, inspect the source before asking an agent to run setup:

git remote get-url origin
git log -1 --format='%h %ad %an %s' --date=short

Check the owner, project history, release links, and whether the repository is referenced by the project’s official domain. Stars and a familiar-looking README are weak signals; both can be copied or manipulated.

2. Treat skills like executable dependencies

An agent skill is not merely a prompt template. It may direct shell commands, tool calls, network requests, and access to local files. Install it only from a canonical marketplace or a link published by the maintainer, then read its instructions before enabling it.

Do not approve a skill because the name looks close enough. In this attack, “close enough” is exactly what the adversary is counting on.

3. Separate discovery from execution

Ask the agent to find and show the canonical resource first. Confirm it yourself. Only then authorize a separate clone or installation step.

A safe workflow has a visible boundary:

Search → show source and owner → human verifies → fetch → inspect → execute

Avoid prompts such as “find it, install it, and follow every setup instruction” when the source is unfamiliar.

4. Isolate untrusted setup work

Run unfamiliar repositories and skills in a disposable container, virtual machine, remote development environment, or tightly scoped sandbox. Remove production credentials, personal SSH keys, cloud tokens, signing keys, and sensitive environment variables from that environment.

Restrict outbound network access where practical. A poisoned resource is much less useful if the agent cannot reach arbitrary hosts or send secrets away.

5. Require approval for high-impact tool calls

Cloning is not the final risk; what happens after cloning is. Require explicit approval for shell execution, package installation, credential access, writes outside the workspace, and network calls to new domains.

OWASP recommends least-privilege access, human approval for high-risk actions, and separating untrusted external content from trusted instructions as core prompt-injection defenses. OWASP LLM01: Prompt Injection

6. Verify package provenance when available

For npm projects, provenance can link a published package to its source repository and build workflow. It is not proof that the code is harmless, but it gives you evidence that you are looking at the intended source. The npm CLI can verify registry signatures and attestations:

npm audit signatures

npm documentation on viewing package provenance

What agent and marketplace builders need to change

Individual caution cannot solve a platform-level problem. Agent systems should:

• Resolve repositories and skills through authoritative search APIs instead of free-form URL generation.
• Refuse to fetch a resource when identity or ownership cannot be established.
• Mark all retrieved content as untrusted data, never as higher-priority instructions.
• Show the exact owner, URL, creation history, and requested tool effects before approval.
• Separate fetching, reading, and execution into independently authorized steps.
• Run third-party skills with least privilege, restricted credentials, and network allowlists.
• Detect newly registered lookalike resources around trending projects.
• Preserve logs that connect the user request, resolved resource, retrieved content, approval, and resulting tool calls.

The crucial design rule is simple: a language model should not be the source of truth for resource identity.

The bigger lesson: grounding is now a security control

For a chatbot, grounding improves factual accuracy. For an agent, grounding decides which code enters your machine and which instructions receive authority.

HalluSquatting works because three weaknesses line up:

1. The model invents a plausible identifier.
2. The application retrieves it without authoritative verification.
3. The agent treats retrieved text as instructions and has enough power to act.

Breaking any one of those links reduces the risk. Breaking all three—verified resolution, untrusted-content boundaries, and least-privilege execution—is the durable answer.

AI agents are becoming faster and more autonomous. That makes “I think this is the right repository” an unacceptable security decision. Before an agent pulls code, installs a skill, or follows a README, identity must be verified by something more reliable than the model’s next-token prediction.