HalluSquatting: How Attackers Turn AI Coding Assistant Hallucinations Into Botnets

Package hallucination has been a known risk for a couple of years: ask an AI coding assistant for help and it sometimes invents a plausible-looking package name that doesn’t exist. The response so far has mostly been “double-check what it suggests.” New research from Tel Aviv University, Technion, and Intuit shows that response undersells the problem, because those hallucinations aren’t random. They’re consistent enough, across sessions and across different foundation models, to predict in advance and turn into an actual attack chain the researchers call HalluSquatting.

The core insight: hallucinations aren’t noise, they’re a pattern

Ask five different people to imagine a plausible npm package name for “a lightweight retry wrapper,” and you’ll get five different answers. Ask five different LLM-backed coding agents the equivalent question in a similar context, and you get something much closer to the same answer, repeatedly. That’s the finding that makes HalluSquatting work: AI hallucinations of resource names, packages, repositories, agent “skills”, cluster around a predictable set of options rather than spreading randomly across the space of possible names.

That predictability is what lets an attacker skip straight past the hard part of most supply-chain attacks. You don’t need to compromise a maintainer’s account or slip a malicious commit past code review. You need to run the same kind of prompts a real coding agent would see, note which names it hallucinates, and register those names first on a real package registry or code host.

How the attack chain actually works

The researchers describe a structured sequence: reconnaissance, where attackers query LLMs with prompts similar to what real developers or agents would use, to see which repository or package names get hallucinated; registration, where attackers claim those exact names on GitHub, npm, PyPI, or wherever the hallucination pointed; and payload delivery, where the registered resource contains code that executes once an agent installs or clones it.

What separates this from a typical prompt injection attack is the delivery mechanism. A classic prompt injection needs a channel into the target, a poisoned email, a malicious calendar invite, a compromised webpage the agent visits. HalluSquatting needs none of that. The victim’s own agent generates the malicious reference itself, during completely normal operation, and then pulls the poisoned resource because it believes its own hallucination. The researchers describe this as untargeted and pull-based, which is precisely the property that lets it scale like a botnet rather than function as a one-target-at-a-time compromise. Anyone whose agent hallucinates the same name is a potential victim, without the attacker doing anything specific to reach them.

How bad is it, in measured terms

The research team tested this against several widely used AI coding tools: Cursor, GitHub Copilot, Gemini CLI, and OpenClaw. Every one of them was vulnerable to some degree.

Scenario	Measured hallucination rate
Installing an AI agent “skill”	Up to 100%
Cloning a code repository	Up to 85%

A 100% rate in the skill-installation scenario means the attacker’s prediction was right essentially every time the researchers ran that test. That’s not a rare edge case worth a footnote, that’s a reliable exploitation surface across some of the most widely used AI coding tools on the market right now.

Why this matters even if you’re careful

The instinctive response is “I always review what gets installed before running it.” That’s the right instinct, but it doesn’t fully cover the risk surface here. Agentic coding workflows are specifically designed to reduce that friction: the whole value proposition is letting the agent install a dependency, run a script, or clone a repo without a human approving every single step. The more autonomy you grant an agent to move fast, the more this specific attack benefits from that same autonomy.

This connects to a broader pattern we’ve covered before around prompt injection and the trust boundary between AI suggestion and execution: the risk isn’t the AI being wrong occasionally, it’s systems built to act on AI output without a verification step in the loop, at exactly the moment that output touches your filesystem or network. A related case, an AI coding agent tricked by a poisoned repository, shows the same trust boundary failing from the opposite direction.

What to actually do about it

1. Pin dependencies to specific, known-good sources and versions in any environment where an agent runs with real privileges, rather than letting it resolve package or repo names dynamically at runtime.
2. Add a human review step before agent-suggested installs run outside a sandbox. This doesn’t mean reviewing every keystroke, it means the specific moment a new external resource gets pulled in gets a second look.
3. Run agentic coding sessions that need network access inside a sandbox you can audit afterward, so if something did get pulled and executed, you have a record of what happened rather than a black box.
4. Treat this as a supply chain risk, not an AI-specific novelty. The mitigations are the same ones that already apply to any unreviewed dependency: least privilege, provenance checks, and no blind trust in a name just because it looks plausible.

AI coding assistants aren’t going away, and they shouldn’t. But the moment you let one auto-execute code it invented itself, you’ve quietly removed the one check that used to catch this class of attack: a human noticing the name looks wrong.