Engineering Analysis
Slopsquatting at Agent Speed: What Hallucinated Resolution Actually Breaks
BleepingComputer, Unit 42, Aikido Security · Aug 16, 2026 · 14 minutes
This isn't a content-filtering problem you can scan your way out of — it's a naming-and-resolution problem baked into how agents decide what "real" means. Security teams need to stop treating hallucinated packages and skills as a model-quality bug and start treating agent resolution as an unauthenticated trust boundary.
The pattern, compressed
Three attacks landed in six months, and trade coverage treated them as three separate stories. They're one story.
- January 2026 — Aikido researcher Charlie Eriksen found a non-existent npm package,
react-codeshift, that had already spread across 237 GitHub repositories through AI-generated agent skill files. No human had planted it. An LLM had conflated two real packages (jscodeshiftandreact-codemod) into a plausible-sounding fake, and agents kept trying to install it daily. Eriksen registered the name himself before anyone with worse intentions could. This is slopsquatting. - June 2026 — Unit 42 catalogued roughly 250,000 domains that language models hallucinate when generating URLs — all sitting unregistered, all free to claim. This is phantom squatting.
- July 2026 — A Tel Aviv University / Technion / Intuit team led by Aya Spira, working in Ben Nassi's group, published research showing the same failure at the repository and skill layer: identical hallucinated repo names appeared in up to 85% of runs, and identical hallucinated skill names appeared in 100% of runs. They called it HalluSquatting.
Same mechanism, three namespaces. An agent needs to resolve a name — a package, a domain, a skill — to something executable, doesn't verify it exists first, and attackers pre-populate the names it's statistically likely to invent. The interesting engineering question isn't "why do models hallucinate names," which is a known and somewhat boring fact about generation. It's why those hallucinations are stable enough to attack, and why the fix isn't "scan harder."
Why the hallucinations are attackable at all
A one-off hallucination is a nuisance. A repeatable hallucination is a target. The research base on repeatability is what makes this an engineering problem rather than a model-quality footnote:
- A USENIX Security 2025 study across 16 models and 576,000 code samples found LLMs hallucinate non-existent package names in roughly 19.7% of interactions, and broke the hallucinations down structurally: 51% pure fabrication, 38% conflation of two real package names, 13% typo-adjacent variants.
- When researchers re-ran identical prompts ten times each, 43% of hallucinated names showed up on every single run.
- The HalluSquatting paper pushed this further at the skill layer specifically: across Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI, and OpenClaw, skill-install prompts converged on identical hallucinated names 100% of the time in their test set.
That convergence isn't random noise — it's the model doing exactly what it's trained to do. Next-token prediction over a fixed training distribution, at a fixed temperature, given a similar prompt shape, reliably lands on the same high-probability fabrication. react-codeshift isn't a random string; it's the statistically obvious blend of two packages that co-occur constantly in the training data for React tooling. The model isn't malfunctioning. It's doing text completion correctly, and text completion has no concept of "does this referent exist."
That's the load-bearing fact for the rest of this piece: the attacker doesn't need to guess your agent's hallucination. They can compute it. Run the same prompt shape a few dozen times against the same model family, keep the names that recur, register those names first. The attack cost isn't "penetrate a system," it's "win a race against nobody" — because until an attacker or a defender claims the name, it simply doesn't exist anywhere for anyone to check against.
Why typosquatting defenses don't fire
This matters mechanically, not just semantically. Every mainstream package-registry defense — npm's collision detection, PyPI's similarity checks, most enterprise dependency-confusion tooling — is built on string-distance heuristics: is this name one edit away from a popular, known-good name? Typosquatting relies on a human mistyping something real. The defense works because the malicious name has to stay close enough to the real one to fool a human's eye, which also keeps it close enough for Levenshtein distance to flag it.
A hallucinated name breaks that assumption at the root. react-codeshift isn't a typo of anything — it's a synthesis of two real, unrelated package names into a third string that has never existed and therefore has zero distance to compare against. There's nothing for a similarity heuristic to be close to. The entire defensive category was built for a threat model where the attacker mimics something real. Slopsquatting, phantom squatting, and HalluSquatting all attack the case where the "real" thing was never real in the first place — the model invented the referent, and the attacker just filled in the reference.
Why scanning the artifact doesn't close the gap either
The instinct once you can't catch this at the naming layer is to catch it at the content layer instead: scan the skill or package before it runs. 2026's research on this has been unusually blunt about how badly that's holding.
Adversa AI ran eight open-source agent skill scanners — including the current OASB leaderboard leader — against real attack samples and got a malicious skill past all eight. The shared root cause across every scanner: they match bytes in the file, not the bytes that actually execute. None of them decode an obfuscated payload and re-scan the decoded plaintext; none normalize Unicode before running their rule bank. A paraphrase as simple as swapping "ignore all previous instructions" for "set aside the earlier guidance" — or translating the instruction into another language — walked past every scanner tested. Separately, Trail of Bits bypassed the malicious-skill detectors for ClawHub, Cisco's scanner, and Vercel's skills.sh in under an hour in three of four cases.
The SkillCloak research adds the sharper data point: self-extracting packing of the payload bypassed all eight scanners tested more than 90% of the time, and dropped Cisco's scanner — the strongest baseline in the study, catching 99% of unaltered malicious skills — down to roughly 10% detection once payloads were cloaked. Critically, cloaking caused no measurable loss of the skill's actual functionality. The malware runs exactly as designed; only the static file on disk looks clean.
And the OASB benchmark's own numbers make the structural point without needing an attacker at all: structural/config-based scanning catches config-encoded attacks reasonably well (81%+ on structurally-encoded samples) but collapses to 29.1% recall across the full Damn Vulnerable AI Agent corpus, because most real attacks live in natural language and behavior, not in a static signature a byte-matcher can key on.
Put together: static scanning is a content-inspection strategy applied to a problem that isn't about content. The malicious skill doesn't need to look malicious. It needs to be named the thing the agent was already going to ask for.
The actual trust boundary that's missing
Here's the reframe that matters for anyone doing threat modeling on agent systems: skill and package resolution is currently unauthenticated identity resolution wearing the costume of a file download.
When a human developer types npm install, there's at least an implicit human-in-the-loop check — did I mean to type this, does this name look right. When an agent resolves a name it generated itself, there is no equivalent checkpoint. The agent's own hallucination is the request. Nothing in the pipeline asks "does this identifier correspond to something that was verified to exist before this conversation started," because the pipeline was inherited wholesale from package-manager design, and package managers were built assuming the human typing the name already believed it was real.
This is the same boundary-collapse pattern showing up across the rest of this year's agent security research — configuration becoming executable, metadata becoming a decision input the agent trusts implicitly. Here it's specifically the resolution step: name → thing. Once you see it that way, the fix stops being "scan the payload better" and becomes "verify the referent before the agent is allowed to treat it as real," which is a fundamentally different control to build.
Concretely, this points at a few architectural properties that current agent skill/package pipelines mostly lack:
- Resolution happens against a pinned, pre-verified allowlist, not live public registries. If your agents can only install from a mirror you've already vetted, a hallucinated name simply fails closed — there's nothing to race against.
- Registry-side provenance has to be cryptographic, not reputational. Download counts and "verified" badges are metadata an attacker can also accumulate over time (see: the postmark-mcp pattern of clean releases before a poisoned one). OWASP's Agentic Skills Top 10 work and the SoK: Agentic Skills paper both converge on the same recommendation — Merkle-root transparency logs, signed publisher identity, content hashes pinned rather than version ranges resolved at install time.
- The agent's proposed name and the registry's confirmed name are different trust levels, and your telemetry should say so. Log the raw string the model generated before resolution, separately from what actually got installed. That diff is your detection signal — a hallucinated-name attack is invisible in "what got installed" logs and glaringly obvious in "what did the model ask for that didn't match" logs.
- Treat skill bodies as inherited execution context, not documentation. Several of 2026's frameworks (OpenClaw among them) now support explicit trust-confirmation gates before repository-controlled configuration can execute, and workflows that require human approval before a proposed skill change is applied. That's the right instinct generalized: any name the agent resolves on your behalf that leads to code execution or prompt-context injection deserves a checkpoint that isn't the model checking itself.
What this doesn't fix
None of the above closes the domain-level and repository-level versions of this problem, which are structurally the same attack surface with different registrars and no realistic path to a pinned allowlist — you can't pre-vet the entire internet the way you can pre-vet a corporate skill mirror. Phantom squatting in particular has no clean architectural answer yet; it's closer to a monitoring and takedown problem than a resolution-gate problem. Worth naming as an open gap rather than hand-waving past it.
The one-sentence version for a threat model
If your STRIDE model has "malicious skill/package installed" as a Tampering or Spoofing entry evaluated at the content-scanning layer, move it. It belongs at the resolution boundary, and the relevant question isn't "is this file malicious" — it's "did anything verify this name existed before my agent asked for it."
Sources
- BleepingComputer — "Slopsquatting, Phantom Domains, and HalluSquatting Are the Same AI Attack" (Aug 2026)
- The Hacker News — "New HalluSquatting Attack Could Trick AI Coding Assistants Into Installing Botnet Malware" (Jul 8, 2026)
- Aikido Security — "Slopsquatting: The AI Package Hallucination Attack Already Happening" (Feb 2026)
- Xygeni — "Slopsquatting Evolution: From AI Curiosity to Agent RCE"
- Tech Times — "AI Coding Agents Skip Package Verification, and Attackers Are Exploiting It" (Jul 1, 2026)
- Adversa AI — "AI skill scanner bypass: 8 open source tools tested" (Aug 2026)
- Cloud Security Alliance Labs — "AI Agent Skill Scanners: Bypassed Across the Board" (Jun 10, 2026)
- TechVipul / SkillCloak research summary — "SkillCloak Exploit: How Malicious AI Agent Skills Evade Static Scanners" (Jul 7, 2026)
- OASB — Skills Security Benchmark, Scanner Leaderboard (oasb.ai)
- OWASP — Agentic Skills Top 10, AST04 (Insecure Metadata) and project overview
- arXiv 2602.20867 — "SoK: Agentic Skills — Beyond Tool Use in LLM Agents"
- arXiv 2605.11418 — "Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry"
- Digital Applied — "Slopsquatting: When AI Invents Packages Attackers Own" (Jul 19, 2026)