HalluSquatting Attack Can Trick AI Coding Assistants Into Installing Malware

Security researchers have disclosed a new attack technique called HalluSquatting that abuses AI hallucinations to poison coding assistants into fetching attacker-controlled resources.

The technique was detailed in the research paper Beware of Agentic Botnets, written by Aya Spira, Stav Cohen, Elad Feldman, Ron Bitton, Avishai Wool, and Ben Nassi.

The risk applies to agentic AI coding tools that can search for repositories, install skills, clone resources, open terminals, or run commands with limited human review. In tested scenarios, researchers achieved remote tool execution and remote code execution.

What is HalluSquatting?

HalluSquatting is a supply chain attack that targets the names AI systems invent when they do not know the correct resource identifier.

Instead of guessing a human typo, the attacker studies which fake names a model repeatedly hallucinates. The attacker then registers one of those names on a platform such as a code repository, package registry, or skill marketplace.

When a developer later asks an AI assistant to fetch or install a popular resource, the assistant may hallucinate the same fake name and retrieve the attacker’s version.

Attack type	What attackers exploit	Typical target
Typosquatting	Human typing mistakes	Misspelled package or domain names
Dependency confusion	Internal package naming gaps	Private package names published publicly
Slopsquatting	AI hallucinated package names	Nonexistent dependencies suggested by AI
HalluSquatting	AI hallucinated resource identifiers	Repositories, skills, plugins, packages, or tools fetched by agents

How the attack works

The attack begins with trending resources. Attackers identify repositories, skills, plugins, tools, or libraries that many developers are likely to ask AI assistants to fetch.

They then prompt AI systems repeatedly to learn which wrong names the models produce most often. If a hallucinated name appears consistently, the attacker registers it first and places malicious instructions or payloads inside.

The Hacker News report describes the attack as a chain that combines hallucination with indirect prompt injection. The assistant fetches the poisoned resource, reads the attacker’s instructions, and may execute commands through its own tools.

1. The attacker selects a trending resource that developers may request.
2. The attacker tests multiple AI models and prompts to find repeat hallucinated names.
3. The attacker registers the fake name before anyone else does.
4. The attacker inserts malicious instructions or payloads into the registered resource.
5. A user asks an AI assistant to fetch the original resource.
6. The assistant hallucinates the attacker-controlled name and retrieves it.
7. The poisoned content influences the agent and can trigger tool or code execution.

Why AI coding assistants are exposed

Modern AI coding assistants can do far more than generate code. Many can clone repositories, install dependencies, read documentation, open files, run terminal commands, and execute test workflows.

Those capabilities create value for developers, but they also create a security boundary problem. If the assistant trusts a hallucinated resource, then the agent may pull malicious instructions into a trusted workflow.

The problem grows when users approve commands quickly or let the agent run in autonomous mode. A short instruction such as “install this tool” can become dangerous when the assistant chooses the wrong source.

What the researchers found

The paper reports high hallucination rates in some tested scenarios. Researchers observed hallucinated resource generation rates of up to 85 percent in repository cloning tasks and up to 100 percent in certain skill installation scenarios.

The HalluSquatting research also found that hallucinations can transfer across foundation models and application layers. That means one hallucinated identifier may work across different prompts or tools.

The researchers demonstrated the attack against production LLM applications with integrated terminals. Their experiments used controlled payloads and withheld sensitive implementation details to reduce abuse risk.

Finding	Reported result	Why it matters
Repository hallucinations	Up to 85 percent in tested cloning scenarios	AI assistants may repeatedly invent the same fake repository names
Skill hallucinations	Up to 100 percent in certain tested scenarios	Skill-based agents may fetch nonexistent capabilities with high confidence
Transferability	Observed across models and prompts	One registered fake name may affect more than one tool
Execution impact	Remote tool execution and remote code execution demonstrated	Poisoned resources can lead to commands running on the user’s machine
Botnet potential	Demonstrated as a scalable attack path	Many users asking for the same resource could pull the same malicious trap

How this differs from slopsquatting

Slopsquatting already showed that AI coding tools can invent package names and cause developers to install malicious packages registered by attackers.

A TrendAI Security analysis describes slopsquatting as a software supply chain threat where coding agents generate plausible but nonexistent package names that attackers can register.

HalluSquatting expands that idea beyond packages. It targets any external resource an agent may fetch, including repositories, skills, plugins, tools, documentation links, or registry entries.

• Slopsquatting focuses mainly on hallucinated dependencies.
• HalluSquatting focuses on hallucinated external resources more broadly.
• Slopsquatting often depends on package installation.
• HalluSquatting can also poison repository cloning or agent skill installation.
• Both attacks rely on AI confidence in names that do not actually exist.

Why promptware makes the attack more dangerous

The researchers describe the malicious content as promptware. In this context, promptware means instructions hidden in external resources that manipulate an AI agent after it retrieves them.

This is different from ordinary malware that executes immediately when downloaded. The attacker’s resource may first act as text, documentation, configuration, or an agent skill that changes the assistant’s behavior.

Once the agent treats the content as trusted context, it may follow hidden instructions, run terminal commands, install files, or connect to attacker infrastructure.

Which tools are at risk?

The risk depends on tool design, permissions, user approval settings, resource validation, and execution safeguards. A simple chatbot that only answers questions faces less risk than an agent with shell access and automatic install permissions.

The Hacker News coverage says the researchers tested tools including Cursor, Windsurf, GitHub Copilot, Cline, Google’s Gemini CLI, and OpenClaw-family assistants.

The important factor is not the brand name alone. The dangerous pattern is an assistant that can fetch an external resource, treat its content as instructions, and run commands without strong validation.

Tool capability	Risk level	Reason
Text-only coding suggestions	Lower	The user still controls resource fetching and execution
Package installation suggestions	Medium	The user may copy and run hallucinated install commands
Autonomous repository cloning	Higher	The assistant may fetch an attacker-controlled repository
Agent skill installation	Higher	The assistant may load malicious instructions as capabilities
Terminal access with limited approval	Highest	The assistant can turn poisoned context into real commands

Why this could scale into botnets

The botnet risk comes from repetition. If many developers ask AI tools for the same trending resource, and the model often hallucinates the same wrong name, one malicious registration can reach many machines.

The researchers argue that this changes the economics of supply chain attacks. Attackers no longer need to compromise a popular project or wait for users to mistype a name. They can target the names AI systems predictably invent.

In a real attack, the poisoned resource could instruct the assistant to install a bot client, create persistence, exfiltrate tokens, or connect to a command server. The researchers used safe demonstrations rather than live botnet malware.

Connection to broader LLM security risks

HalluSquatting combines several known AI security problems: hallucination, indirect prompt injection, insecure tool use, and supply chain trust.

The OWASP Top 10 for LLM Applications lists prompt injection and supply chain vulnerabilities among the major risks for LLM-based systems. HalluSquatting sits at the intersection of both.

It also shows why grounding matters. AI systems should verify that a package, repository, plugin, or skill exists through an authoritative source before they fetch or execute it.

Recommended defenses for developers

Developers should not let AI agents install packages, clone repositories, or load skills without checking the source first. The assistant may sound confident even when it invents a name.

Before accepting an AI-generated install command, developers should verify the package or repository through the official project website, trusted registry page, known GitHub organization, or vendor documentation.

The TrendAI guidance on slopsquatting recommends layered defenses such as provenance tracking, automated scanning, sandboxed installs, real-time validation, and human oversight.

1. Require agents to search and verify resources before fetching them.
2. Do not allow automatic installation of packages, plugins, or skills from unknown sources.
3. Check package age, maintainers, repository links, download history, and official documentation.
4. Run AI-generated install commands inside a sandbox or disposable development environment.
5. Use dependency allowlists for production repositories and CI/CD systems.
6. Block newly created or low-reputation packages unless reviewed.
7. Review every command an agent wants to run before approving it.

Recommended defenses for AI tool vendors

AI coding tool vendors need stronger validation layers around resource fetching. The assistant should not treat a hallucinated name as real just because it sounds plausible.

Tools should require source verification, show users where a resource came from, flag newly registered names, and separate untrusted fetched content from trusted system instructions.

The OWASP LLM guidance also reinforces the need to control prompt injection risk, excessive agency, insecure output handling, and supply chain exposure in systems that connect LLMs to external tools.

• Verify repositories, packages, plugins, and skills against authoritative registries.
• Warn when a resource is newly created, low reputation, or not linked from the official project.
• Require explicit user approval before executing commands from fetched content.
• Sandbox resource installation and command execution by default.
• Prevent external documentation or skill files from overriding system rules.
• Log every fetched resource, command, and approval decision.
• Separate “read this file” context from “follow these instructions” context.

What security teams should monitor

Organizations using AI-assisted development tools should track what agents install, clone, and execute. AI activity should appear in security logs, not remain hidden inside developer workflows.

Security teams should watch for newly registered dependencies, unexpected GitHub clones, unknown skill installations, unusual terminal activity launched by AI tools, and outbound connections from developer machines after agent actions.

They should also review CI/CD environments where agents may have access to tokens, package publishing rights, cloud credentials, or source code repositories.

Area to monitor	Signal to watch	Why it matters
Package managers	New or low-reputation packages added by AI workflows	Could indicate slopsquatting or HalluSquatting
Git activity	Unexpected repository clones from unfamiliar owners	Could indicate hallucinated repository fetching
Agent skills	New skills or plugins installed from community marketplaces	Could bring hidden promptware into the environment
Endpoint activity	Shell commands launched by AI tools	Could show poisoned context turning into execution
Network traffic	Connections to unknown command servers after agent activity	Could indicate malware installation or data exfiltration

The bottom line

HalluSquatting shows how AI hallucinations can become a real software supply chain attack when coding assistants have permission to fetch resources and run commands.

The attack does not require direct access to the victim. Attackers can register names that AI tools are likely to invent, wait for users to request a legitimate resource, and let the assistant retrieve the poisoned version.

The safest approach is to treat AI-generated resource names as untrusted until verified. Developers should keep human approval in the loop, and AI tool vendors should make resource validation a default security feature.

FAQ