Nine tools, one shared blind spot
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.
How the attack actually works
The chain is mechanically simple, which is what makes it dangerous:
- A developer asks their AI coding agent to find and clone a trending repo, or install a helper skill/package for a task.
- The agent, working from training data patterns and incomplete context, generates a name that sounds like a real, popular repo or package — but doesn't exist.
- The agent (or the tooling around it) attempts to clone/install that name directly, with no human verification step in between.
- If the attacker has pre-registered that exact name with a malicious payload, the agent pulls it straight into the developer's environment.
- The payload — a reverse shell, in the cases described — executes with whatever privileges the coding agent's environment has.
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.
Why existing defenses miss this
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.
- Prompt injection filters look for adversarial content in the input — jailbreak phrasing, authority hijacks, instruction overrides. HalluSquatting doesn't inject anything into the prompt. The "attack" is the model's own hallucinated output being acted on. There's no adversarial string to pattern-match against in the user's request.
- SCA / dependency scanners check packages against CVE databases and known-vulnerability lists. A brand-new, purpose-registered malicious package with zero history has no CVEs and no reputation signal yet — it's not on anyone's blocklist because it was created specifically for this attack.
- Code review happens too late in agentic workflows. If the agent clones and executes in the same session, a reverse shell can be live before a human ever looks at a diff.
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.
Where Sentinel catches this: package_hallucination detection (SlopScan)
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:
-
The hallucinated name that doesn't exist yet → flagged as
SUSPICIOUS(not_in_registry), because no attacker has registered it, or the model invented a name with no registry match at all. -
The name an attacker has pre-registered with a malicious payload → still catchable, because a package created purely to catch hallucination traffic typically has zero download history, no reputation, and other low-trust signals SlopScan flags as
CAUTIONorSUSPICIOUSdepending 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.
What this looks like in practice
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.
The takeaway
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 — Starter tier is free, no credit card required, and SlopScan is available starting at Pro.
SlopScan: SlopScan Repo - Free to use, PR's welcome.
Top comments (0)