HalluSquatting: How Attackers Turn AI Coding Agents Into a Botnet Without Touching a Single Victim

Researchers reported in July 2026 that nine widely used AI coding tools, including Cursor, GitHub Copilot, Gemini CLI, and Windsurf, share a common failure mode called HalluSquatting. Attackers exploit this by predicting hallucinated package names from LLMs, pre-registering them with malicious payloads, and waiting for agents to automatically clone or install them, turning them into a botnet without targeting specific victims. The technique bypasses traditional defenses like prompt injection filtering and dependency scanning, as the malicious package becomes real only after the agent acts on it.

Researchers reported in July 2026 that nine of the most widely used AI coding tools — Cursor, GitHub Copilot, Gemini CLI, Windsurf, and others — share a common failure mode that attackers can exploit without ever phishing, socially engineering, or targeting a specific victim. The technique is called HalluSquatting , and it flips prompt injection on its head: instead of pushing malicious input at a model, attackers wait for the model to pull it. Here's the mechanism, per the report: when these coding agents are asked to clone a "trending" repository or install a skill/package, they frequently hallucinate plausible-but-nonexistent names. This isn't a new observation — LLM package hallucination has been documented for a couple of years now in the context of pip install and npm install suggestions. What's new is the scale of the exploit surface. If an attacker can predict the hallucinated names an agent is likely to generate, they can pre-register those names on GitHub or a package registry, seed them with malicious payloads — reverse shells, per the researchers — and simply wait. Every coding agent that hallucinates that name and blindly clones or installs it becomes an infected node. No spear phishing required. This is a botnet-assembly technique that scales with the popularity of the tool, not with the effort of the attacker. The chain is mechanically simple, which is what makes it dangerous: The "pull-based" framing matters. Traditional injection attacks require the attacker to get malicious content in front of a specific target. HalluSquatting requires the attacker to guess what an LLM is statistically likely to hallucinate, register that name once, and let normal agent usage do the distribution. It's asymmetric in the attacker's favor — one registered malicious package can compromise an arbitrary number of unrelated developers who happen to trigger the same hallucination. Standard defenses in this space cluster around two things: prompt injection filtering and traditional dependency scanning SCA tools, lockfile audits, known-CVE databases . Both miss HalluSquatting for the same structural reason — the malicious package is real by the time your scanner sees it. The gap is structural: nothing in the pipeline checks whether the package name the agent is about to act on actually exists in the registry, and if it does, whether it's trustworthy — before the clone/install happens. This is exactly the scenario Sentinel's SlopScan integration is built for. SlopScan runs as a dedicated service in the Sentinel stack and checks every package name extracted from LLM output against live PyPI/npm registry data — before that name is acted on by the agent. The key insight: SlopScan doesn't rely on CVE history or blocklists. It asks a more fundamental question — does this package exist, and if so, what's its trust signal? That catches both halves of the HalluSquatting attack: SUSPICIOUS not in registry , because no attacker has registered it, or the model invented a name with no registry match at all. CAUTION or SUSPICIOUS depending on trust score.If a hit crosses into DANGEROUS territory — a confirmed malicious package or known typosquat — Sentinel blocks the action outright rather than letting the agent proceed. Critically, this check is decoupled from the primary threat-scoring pipeline. A prompt can be completely clean from a prompt-injection standpoint no jailbreak language, no authority hijack and still get flagged for package risk. That's exactly the HalluSquatting case: the prompt isn't malicious, the output is. Illustrative example — request/response shape follows Sentinel's documented API, package names are for demonstration only. Suppose a developer's agent asks Sentinel-proxied Claude to "clone the trending repo for rate-limiting middleware" and the model hallucinates a plausible-sounding but nonexistent package as part of its suggested pip install command: { "request id": "f3a9e21c-88b1-4e2a-9c40-7d112abf9e01", "security": { "action taken": "clean", "threat score": 0.02, "package scan": { "action": "flagged", "hits": { "name": "fastrate-limiter-pro", "ecosystem": "pypi", "trust score": 0, "risk": "SUSPICIOUS", "flags": "not in registry" } } } } Note action taken: "clean" — nothing about the prompt itself tripped the threat scorer. The risk lives entirely in package scan . If the same package name existed in the registry but had been pre-registered by an attacker with, for example, a known-malicious install script, SlopScan's trust scoring would push it toward DANGEROUS , and Sentinel would block the action before the agent's tooling ever executed a clone or pip install . Enabling this is a dashboard toggle, not a code change: Dashboard → Settings → SlopScan Package Scanning → ON Available on Pro tier and above slopscan enabled=true on the tenant . If SlopScan is temporarily unavailable, the scrub pipeline degrades gracefully — the rest of the security pipeline keeps running, package scan is simply absent from the response rather than blocking the request. If your team runs AI coding agents that clone repos or install packages autonomously — Cursor, Copilot, Gemini CLI, Windsurf, or anything similar — assume the model will occasionally hallucinate a package name that sounds real. That's not a bug you can prompt-engineer away; it's a known property of these models. The fix isn't better prompting, it's a verification layer between "the model suggested this package" and "the agent executed against it." Concretely, today: put a package-existence and trust-score check in front of any automated clone/install step in your agentic pipeline, and don't let agents execute installs before that check runs. If you're already running requests through Sentinel, turning on SlopScan is a one-click way to close this specific gap without touching your agent's prompting logic. Try it: sentinel-proxy.skyblue-soft.com https://sentinel-proxy.skyblue-soft.com — Starter tier is free, no credit card required, and SlopScan is available starting at Pro. SlopScan: SlopScan Repo https://github.com/c0ri/SlopScan - Free to use, PR's welcome.