HalluSquatting: When AI Hallucinations Become a Supply Chain Attack
The next supply chain attack may start with a name your AI invented.
HalluSquatting turns a familiar weakness, hallucinated package and repository names, into a scalable attack path against tool-using agents. The attacker does not need to breach your registry, compromise a maintainer, or send a malicious email. They can register the resource your agent is likely to hallucinate, hide instructions inside it, and wait for the agent to pull the trap into its own context.
Security teams have spent the last year learning that prompt injection is not only a chat problem. It is a workflow problem.
HalluSquatting, disclosed in July 2026 by researchers from Tel Aviv University, Technion, and Intuit, pushes that lesson further. It shows that an attacker can poison an agent without ever reaching the user directly. The agent does the reach-out itself.
That is the uncomfortable part. The user asks for a legitimate project. The model guesses the wrong owner, repository, package, or skill name. The attacker has already claimed that fake resource. The agent retrieves it, reads the embedded instructions, and uses its own tools to execute the next step.
This is not merely “AI makes mistakes”. This is AI turns uncertainty into an unauthenticated supply chain lookup.
What HalluSquatting Changes
Traditional squatting attacks exploit human typo patterns. Typosquatting waits for a developer to mistype a package name. Dependency confusion waits for a resolver to choose the wrong namespace. Slopsquatting waits for generated code to include a fake package.
HalluSquatting is aimed at the agent’s resolution behavior.
The research found that hallucinated resource identifiers are often predictable and transferable. In repository cloning experiments, hallucination reached up to 85 percent. In skill installation scenarios, it reached up to 100 percent. The same wrong names appeared across prompts, models, and application layers often enough that an attacker could rank candidates, claim the best one, and wait.
The attack becomes more dangerous when the assistant can fetch resources, read their contents, run shell commands, install dependencies, or invoke local tools. That is exactly the permission set many coding agents and personal assistants now request.
Why Search Is a Control, Not a Convenience
One of the most useful findings in the paper is brutally practical: verification behavior changed outcomes.
When an agent searched the web before cloning, the correct outcome rate was much higher. When it skipped search, hallucination dominated. In one aggregate Cursor CLI experiment, searched clone attempts were correct 93.4 percent of the time, while attempts without search were hallucinated 99.1 percent of the time.
This does not make web search a complete defense. Search can be poisoned, results can be ambiguous, and attackers can create convincing landing pages. But it reframes “look it up first” as a security control. Agents that resolve external resources from memory are not being efficient. They are bypassing provenance.
An agent should never convert a guessed name into an executable fetch. Resource resolution needs the same treatment as identity resolution: verify the canonical source, bind it to a stable namespace, and require explicit approval before crossing into execution.
The Hidden Boundary Is “Name To Capability”
Most teams already understand that code execution is sensitive. Fewer treat resource naming as sensitive.
In agentic systems, a name is not a label. It is a route to capability. A guessed GitHub slug can become a cloned repository. A guessed skill name can become an installed tool. A guessed package name can become postinstall execution. A guessed URL can become retrieved instructions. Once that content enters the context window, the model may treat it as operational guidance.
That means the trust boundary is not “before terminal access”. It is earlier:
Name resolution
Is this the canonical resource the user intended, or merely a plausible identifier produced by the model?
Content ingestion
Will README text, skill metadata, package scripts, or install output be treated as data or as instructions?
Tool authority
Can fetched content cause shell, file, network, browser, or credential actions through the assistant’s tools?
Execution continuity
Does the agent keep working after a suspicious fetch, or does it stop and ask for a human decision?
The old review model fails here because the human may never see the moment that matters. A developer asks for “the repo”. The agent clones something plausible. The terminal scrolls. The task continues. The compromise looks like progress.
OWASP Agentic Top 10 Mapping
HalluSquatting is not one OWASP bucket. It is a chain that touches several categories in the OWASP Agentic Top 10 (2026).
| OWASP category | How it shows up | Control that matters |
|---|---|---|
| ASI04 | The attacker claims a hallucinated repository, package, plugin, or skill name and turns the agent ecosystem into the distribution channel. | Use allowlisted registries, pinned source identities, signed releases plus behavioral inspection, and deny unknown namespaces by default. |
| ASI02 | The agent misuses built-in tools after reading attacker-controlled instructions from fetched content. | Bind tool calls to policy, require step-up approval for terminal or install actions, and separate content from instructions. |
| ASI05 | Promptware can move from text to command execution when the assistant has shell access or package install privileges. | Run agents in isolated workspaces with network and filesystem limits, egress controls, and rollback for generated changes. |
| ASI06 | Fetched README files, skill descriptions, install logs, and documentation can poison the context that drives future actions. | Label fetched content as untrusted, strip executable instructions from data channels, and monitor instruction drift across the workflow. |
What Security Teams Should Change This Week
First, stop allowing agents to resolve unknown resources from memory. If the user supplies a name without a canonical URL or package coordinate, the agent should verify it through an independent source before fetching it. “Looks right” is not enough.
Second, treat every fetched artifact as untrusted input until it passes policy. That includes README files, install scripts, package metadata, marketplace descriptions, examples, issue comments, and generated setup instructions.
Third, split fetch from execute. An agent may be allowed to download or inspect a resource without being allowed to run it. Installing a package, executing a shell command, adding a skill, or granting a tool permission should be a separate decision with a different threshold.
Fourth, log the resolution chain. Security teams need to know what the user asked for, what identifier the agent resolved, whether search or registry lookup was used, what content entered context, and which tool calls followed.
Fifth, build a deny path that feels normal. If the agent cannot prove the source, it should stop cleanly. Security cannot depend on heroic humans noticing a subtly wrong repository name in a fast terminal session.
The Takeaway
HalluSquatting matters because it converts model uncertainty into an attacker-controlled routing layer.
The fix is not “make models hallucinate less”. Models will still be uncertain about new projects, renamed repositories, niche tools, fresh packages, and ambiguous instructions. The fix is to stop treating uncertainty as permission to guess.
Agent security needs a boring rule: when names unlock capabilities, names require verification.
- Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting
- The Hacker News: New HalluSquatting Attack Could Trick AI Coding Assistants Into Installing Botnet Malware
- DevOps.com: HalluSquatting Compromises AI Coding Agents to Install Malware, Create Botnets
- OWASP Top 10 for Agentic Applications 2026