A new attack class called HalluSquatting turns AI coding assistants into botnet recruits

An attacker can predict the package names an AI coding assistant is most likely to invent, register those names, seed them with malicious code, and wait for the assistant to pull the trap on its own. The assistant, not the attacker, initiates the connection. That switch from pushed lures to pulled dependencies is what turns a clever prompt trick into a mass-recruitment problem.

Researchers call the technique HalluSquatting, and a write-up at Ars Technica walks through how the project team recruited nine widely used AI and coding tools into coordinated botnet-style behavior. Prompt injection has been the dominant AI security story for two years, but most of those attacks are push-based: a poisoned email or calendar invite is delivered to a single victim, who is persuaded to run the assistant on it. The attack works one user at a time.

HalluSquatting is pull-based. The attacker never contacts the victim. Instead, they exploit a quality bug that the industry has long treated as harmless: large language models regularly hallucinate plausible-looking package, library, or resource names that do not exist. Attackers harvest those names at scale, register the ones most likely to be requested, and publish malicious code under them. When a developer later asks an AI coding assistant to scaffold a project, fix a bug, or run a build, the assistant reaches for what looks like the right package, finds a registered name, and pulls the malicious version in. The trap is sprung inside the developer's own terminal, with whatever shell privileges the assistant has been granted.

That pull path is what makes the attack untargeted. The attacker does not need to know who the victim is, where they work, or what they are building. They only need the assistant to ask for a name that looks plausible, and the malicious code rides back. The team behind the Agentic Botnets project describes this as a way to recruit AI coding tools into "botnet-style" coordination, with the agent acting as both the recruiter and the executor: one tool that pulls from a malicious source can be instructed, in turn, to recruit other tools on the same network.

Once a coding assistant runs attacker-supplied code, it can launch distributed denial-of-service attacks, mass-scan networks, mine cryptocurrency, or download additional payloads. The Ars Technica write-up describes the impact as botnet assembly, large-scale DDoS, and mass device infection, with high-privilege command-line execution as the multiplier. The same primitives could also be used for quieter goals, such as stealing source code, tokens, or cloud credentials, but the project page focuses on the louder failure mode.

HalluSquatting succeeds because the LLM cannot tell the difference between a trusted instruction from the developer and an untrusted instruction embedded in third-party content such as a package description, a README, or a code comment. The trusted/untrusted instruction boundary is not a configurable setting; it is a structural property of how current models are built, and it has not been solved at the architecture level. Today's mitigations for prompt injection are guardrails around the result: input filtering, sandboxing, output review, and human-in-the-loop checkpoints. Those reduce the impact of a single push-based attack but do not address the underlying problem.

Defenders can act on the parts that are not architectural. Registry and identifier hygiene is the first lever: package registries can flag names that are statistically likely to be hallucinated, slow down new registrations, and require additional verification for lookalikes. Coding assistants can be told to verify unfamiliar package names against multiple sources, prefer vendored or pinned dependencies, and run shell commands in scoped sandboxes without network access. Some of this is already standard practice for security-conscious teams; HalluSquatting makes the case for treating it as default.

The industry treated LLM hallucination as a quality bug, not a security boundary, until this class of attack made the cost concrete. Vendors can choose to surface hallucination risk in their output, refuse to install packages with no download history, and warn developers when an assistant reaches for an unverified dependency. Package registries, which sit on the supply side, can refuse to host lookalike names that appear too quickly after a popular model update. None of these moves close the underlying hole, but they raise the cost of running the scam.

The Agentic Botnets project page is the live reference for which tools are confirmed vulnerable, which versions ship fixes, and whether any vendor has published a response. As of the project's public write-up, no vendor patch closes the architectural problem, and the same page treats HalluSquatting as a category, not a single bug. The next milestone to track is whether any major coding assistant ships a model change that surfaces hallucination risk in package selection, rather than relying on guardrails around the result.