How to Defend AI Coding Agents Against HalluSquatting Attacks

What HalluSquatting Actually Is

HalluSquatting is a supply chain attack that targets your agent's guesses instead of your typos. It was named in "Beware of Agentic Botnets", published on July 8, 2026 by researchers from Tel Aviv University, the Technion, and Intuit. The recipe is three steps: identify a trending resource, compute the LLM's probability distribution over the names it hallucinates for that resource, then pre-register the highest-probability fakes and host an adversarial prompt on them.

Then the attacker waits. When you ask your assistant to clone that trending repo or install that trending skill, it reaches for the name it invented, finds the attacker's payload sitting there, and pulls the poisoned content into its own context. From there it is indirect prompt injection, and the paper measured end-to-end remote code execution in 20-65% of runs across the coding assistants tested.

The distinction from slopsquatting matters. Slopsquatting, coined by Seth Larson in 2025, is opportunistic: register whatever nonsense models happen to emit and hope someone installs it. HalluSquatting is targeted and transferable. The adversarial trigger makes models hallucinate a name the attacker chose, and it works across vendors. That turns a random accident into a repeatable delivery mechanism.

Why Lockfiles and Install Cooldowns Do Not Stop This

Every npm hardening guide published in 2026 tells you the same things: commit your lockfile, run npm ci, turn on a cooldown so you never install a version published five minutes ago. That advice is good. It is also aimed at a different attack, and against HalluSquatting most of it does nothing.

The reason is structural. Every control in that list operates after a dependency has been resolved and recorded. HalluSquatting wins during resolution, when your agent decides what name to reach for in the first place. By the time your lockfile has an opinion, the decision has already been made.

I want to be fair to these controls. Cooldowns and lockfiles are genuinely effective against compromised-maintainer attacks, where a legitimate package suddenly ships a malicious version. Keep them. Just do not mistake them for coverage here, because the threat model is inverted: there is no legitimate package to compromise, only a name your model invented. (Worth disambiguating one word: when I pin the Claude Code CLI to a known-good version, that is a reliability control. This post is about integrity. Same verb, unrelated problems.)

Verify the Package Exists With a PreToolUse Hook

A PreToolUse hook is the enforcement version of "search before you fetch." It runs after Claude builds the tool parameters and before the command executes, it costs zero tokens, and it does not care what the model believes. An injected prompt can talk Claude out of a markdown rule. It cannot talk a shell script out of returning exit code 2. Wire it to the Bash tool:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/verify-package.sh"
          }
        ]
      }
    ]
  }
}

The hook receives the tool call as JSON on stdin. It pulls out the command, extracts any package or repo names, checks each one against the real registry, and blocks on a 404. Exit code 2 blocks the action and feeds stderr back to Claude as the reason, so the model learns why it was stopped and can correct itself.

#!/usr/bin/env bash
# Blocks installs and clones of names that do not resolve on the registry.
set -uo pipefail

INPUT=$(cat)
CMD=$(printf '%s' "$INPUT" | jq -r '.tool_input.command // empty')
LOG="$HOME/.claude/fetch-audit.log"

record() { printf '%s\t%s\t%s\t%s\n' "$(date -u +%FT%TZ)" "$2" "$1" "$CMD" >> "$LOG"; }

deny() {
  record DENY "$1"
  echo "Blocked: '$1' does not resolve. Search for the real name before fetching it." >&2
  exit 2   # 2 = block the tool call, stderr goes back to Claude
}

# npm / npx / pnpm / bun
for pkg in $(printf '%s' "$CMD" \
  | grep -oE '\b(npm i|npm install|npx|bunx|pnpm add) +[@a-zA-Z0-9/._-]+' \
  | awk '{print $NF}'); do
  npm view "$pkg" version >/dev/null 2>&1 && record ALLOW "$pkg" || deny "$pkg"
done

# pip
for pkg in $(printf '%s' "$CMD" \
  | grep -oE '\bpip3? install +[a-zA-Z0-9._-]+' \
  | awk '{print $NF}'); do
  curl -sf -o /dev/null "https://pypi.org/pypi/$pkg/json" && record ALLOW "$pkg" || deny "$pkg"
done

# git clone / GitHub slugs
for repo in $(printf '%s' "$CMD" \
  | grep -oE 'github\.com[:/][A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+' \
  | sed -E 's#github\.com[:/]##; s#\.git$##'); do
  gh repo view "$repo" >/dev/null 2>&1 && record ALLOW "$repo" || deny "$repo"
done

exit 0   # 0 = no decision, normal permission flow applies

If you prefer structured output over exit codes, return a JSON decision on stdout instead. This is the form to use when you want the denial reason surfaced cleanly rather than as raw stderr:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Package 'react-codeshift' does not exist on npm"
  }
}

Notice the hook also writes every decision to ~/.claude/fetch-audit.log. That log is the only forensic trail you will have. Grep it for installs of packages that never made it into package.json, clones nobody asked for, and repeated denials against the same name. That last pattern is what an active campaign looks like.

Lock Down the Install Path Itself

One .npmrc setting does most of the work here, and it is not the one the 2026 hardening posts lead with.

# The one that matters for this attack.
# Kills preinstall/install/postinstall/prepare, the cheapest RCE in the ecosystem.
ignore-scripts=true

# Defense in depth against *other* supply chain attacks. Near-useless here:
# a patient hallusquatter registered the name months ago and it clears the cooldown.
min-release-age=3

ignore-scripts=true earns its place because lifecycle scripts run automatically with your full user privileges the moment a package lands. It is the lowest-friction execution path in the ecosystem, and turning it off means a squatted package that does get installed sits there inertly instead of running. It will break a handful of packages with legitimate native build steps, and you will allowlist those individually. That trade has been worth it in every repo where I have made it.

For the blunt backstop, a deny rule forces every ad-hoc fetch-and-execute through a human. Rules evaluate in the order deny, then ask, then allow, so a deny always wins:

{
  "permissions": {
    "deny": [
      "Bash(npx *)",
      "Bash(bunx *)"
    ]
  }
}

This is deliberately annoying, and that is the point. npx is fetch-and-execute in a single breath with no lockfile step anywhere in the middle, which is why react-codeshift spread as an npx invocation rather than a dependency. If you want the tool-permission layer above this one, I covered allowlisting in depth in hardening AI agents in CI/CD. That post answers which tools the agent may run. This one answers which names it may resolve, which turns out to be a different question with a different answer.

What This Still Cannot Fix

Everything above is a compensating control. None of it addresses the root cause, and the paper is unsparing about how thin the model-side guardrails turned out to be. The finding that should worry you most: "No assistant refused execution based on payload content, even for the crude variant with explicit AI-targeting markers." The researchers left obvious fingerprints on the payload, the kind of thing a content filter exists to catch, and not one of the nine applications balked.

The mechanism behind that explains the shape of this entire post: once the agent operates on attacker-controlled files, it applies the same trust as to legitimate project code. There is no trust boundary after the fetch. The agent has no category for "code I pulled from a stranger." Which is why every control here lives before the fetch: afterwards, there is nothing left to enforce. The authors are equally unimpressed by confirmation prompts, and they are right. Many agents execute with no confirmation at all, and a human staring at a plausible package name is theatre with a latency cost.

The real fixes are upstream and out of your hands. Model providers enforcing search-before-fetch rather than leaving it to chance. Applications making verification non-optional instead of a behaviour that shows up 31% of the time. Registries doing defensive registration of high-probability hallucinations, the same move that already works against typosquatting. Until those land, everything in this post is you covering for a gap you did not create.

The residual risks, stated plainly: verification proves existence, not intent. The sandbox still permits egress to allowed domains, and github.com is on your allowlist. A squatted name that reaches a committed skill file outlives the session that created it. And if a scanner is your last line, remember that AI code review is advisory input rather than a merge gate, a case I made in the security review action guide.

Frequently Asked Questions