What Is Slopsquatting? The New HalluSquatting Attack on AI Coding Agents

What is slopsquatting?

Slopsquatting is the practice of registering a software package name that does not exist but that a large language model is likely to hallucinate, so that a developer or an AI agent installs the attacker's package believing it is legitimate. The term was coined by Seth Larson, Security Developer-in-Residence at the Python Software Foundation, in April 2025, as a portmanteau of "AI slop" and "typosquatting."

Two ideas sit underneath it, and it helps to keep them apart. Package hallucination is the model behavior: an LLM, asked to write code, references an install target that was never published. Slopsquatting is the attack that turns that behavior into a delivery mechanism, by claiming the hallucinated name first. The hallucination is the vulnerability; slopsquatting is the exploit.

“

A human who reads "pip install reqwest-py" might pause and check. An agent runs the command. The moment a package name goes from a suggestion a person types to an action an agent executes, the last human checkpoint disappears.

Slopsquatting vs typosquatting: what is the difference?

They are both name-confusion attacks on the software supply chain, but they exploit different mistakes and, crucially, they evade different defenses.

The load-bearing difference is the third row. Typosquatting defenses assume the malicious name looks like a real one, so they flag packages within a small edit distance of popular libraries. A hallucinated name is not a misspelling of anything. Socket's analysis of hallucinated names found nearly half were highly dissimilar to any real package, fabricated yet believable in context, which is exactly why lookalike detection slides right past them.

How does a slopsquatting attack actually work?

The attack has four steps, and the uncomfortable part is that the attacker does not need to guess. The model tells them what to register.

What makes step two exploitable is that hallucinations are not random noise. In the largest study to date, researchers re-ran the same prompt ten times and found that 43% of hallucinated package names reappeared in all ten runs, and 58% reappeared more than once. The model does not invent a different fake name each time; it gravitates to the same ones. An attacker can farm these names in bulk, register the sticky ones, and wait. Because agents in autonomous or "yolo" modes install and execute without confirmation, the payload's post-install hook fires the instant the package lands, before a pull request exists to review.

How common are hallucinated packages?

Common enough to be a distribution channel rather than an edge case. The definitive measurement is the USENIX Security 2025 study "We Have a Package for You!" from the University of Texas at San Antonio and Virginia Tech, which analyzed 2.23 million code samples generated by 16 models across Python and JavaScript.

The rate is not uniform. Open-source models hallucinated packages in 21.7% of samples against 5.2% for commercial models, roughly a fourfold gap, and some code-specialized models invented a package in more than a third of their outputs. Two forces then push the risk up over time, not down: teams increasingly let agents write and install dependencies unattended, and the same models keep suggesting the same fabricated names to everyone who asks.

Has slopsquatting happened in the real world?

Yes, and the proof predates the name. In late 2023, security researcher Bar Lanyado of Lasso Security noticed several models repeatedly hallucinating a Python package called huggingface-cli. As a harmless proof of concept he published an empty package under that name. Within three months it had been downloaded more than 30,000 times, and, as The Register reported, a major company (Alibaba) referenced the install command in the README of one of its own research repositories. The package was benign. A malicious actor watching the same hallucination would not have been.

The 2026 twist is that AI agents now spread these names for you. The Cloud Security Alliance's April 2026 research note on slopsquatting documents how hallucinated install commands are propagating through copy-pasted "agent skill" files. In one January 2026 case, a fabricated npm package (a name a model produced by conflating two real tools) was already referenced by 237 GitHub repositories before anyone flagged it, seeded largely by a single commit that added dozens of LLM-generated skill files. The hallucination did not stay in one chat window; it was committed, shared, and re-executed by every agent that read the skill.

What is the HalluSquatting attack (July 2026)?

For most of slopsquatting's short history the attacker was opportunistic: register whatever names the model happens to favor, then wait. A paper published on 8 July 2026, "Beware of Agentic Botnets" by Spira, Cohen, Feldman, Bitton, Wool and Nassi (Tel Aviv University, Technion and Intuit), removes the waiting. It demonstrates a universal, transferable adversarial trigger that makes agents hallucinate a specific, attacker-chosen resource on demand, rather than hoping they land on one the attacker already owns.

The mechanism chains two failures the earlier sections describe. First, the trigger steers the agent into fetching a resource (a repo, a skill, a package) under a name the attacker controls. Second, indirect prompt injection hidden inside that fetched resource executes when the agent's terminal runs it, achieving remote tool execution and installing self-propagating botnet malware. The researchers frame the result as an untargeted, scalable attack: one adversarial trigger, no per-victim setup, malware that spreads from one compromised agent to the next.

Why can't a scanner catch it?

Because the two controls most teams rely on both look in the wrong place or arrive too late.

Read down the right-hand column and a single theme emerges. Every one of these controls acts on the package after it is on disk, or looks for a resemblance that a fabricated name does not have. The install script of a malicious dependency runs at install time, which for an autonomous agent is seconds after the model invented the name, and long before any scanner, reviewer, or CVE feed weighs in. The only place to stop it is before the install command executes.

How to prevent slopsquatting

None of these are exotic. The discipline is applying them to agents that move faster than the humans supervising them.

1. Turn off blind auto-install. Do not run agents in fully autonomous "install and execute" modes against real credentials. Require explicit approval for any new dependency, so a fabricated name has to pass one human glance.

2. Verify a package exists and is real before it is added. "It installed" is not proof of legitimacy; the attacker made sure it would install. Check that the package has a genuine history: age, download trajectory, a real source repository, named maintainers. A package registered last week that a model swears is standard is the exact shape of this attack.

3. Pin versions and commit lockfiles with integrity hashes. A lockfile with hashes means a swapped or newly poisoned version cannot silently substitute itself, and it makes a new dependency visible as a reviewable change rather than an invisible transitive pull.

4. Constrain where packages can come from. Use an internal mirror, a private registry, or an allowlist so the agent can only install from vetted sources. If a hallucinated name is not in the mirror, the install fails closed instead of reaching out to the public registry.

5. Run software composition analysis, as a backstop. SCA is worth running on every new dependency, but treat it as the last net, not the first. It catches known-bad packages and versions; it will not catch a zero-day malicious package on the day it is registered.

6. Review new dependencies specifically. Make "did this change add a dependency?" an explicit review step. A one-line addition to package.json or requirements.txt deserves more scrutiny than a hundred lines of business logic, because it imports someone else's code with your privileges.

7. Isolate untrusted agent work. When an agent runs against an unfamiliar repository or third-party content, give it a container with no host secrets and no path to production. Install scripts run immediately, so a steered agent should have nothing valuable within reach when one fires.

8. Treat agent-suggested packages as untrusted input. The confidence of the suggestion is not evidence. A name the model presents as obvious is precisely the name an attacker has already checked the model likes.

Where prevention has to live: agent-time enforcement

Walk back through that list and the effective controls share a property: they act before the install command runs. The scanner reading a diff, the SCA feed, the CVE database, they all arrive after the agent has already fetched and executed the package. At agent cadence, that is too late. The place to enforce "do not install a package you cannot verify" is inside the agent loop, at the moment the agent reaches for the install command.

That is the layer VibeDefend adds. It is a free npm CLI that installs in about five seconds and wires your AI coding agents (Claude Code, OpenAI Codex, Cursor, Windsurf and VS Code Copilot) into governance that runs while they work, not after.

Two of the four layers map directly onto this attack. Action Guard intercepts the risky action before it fires: an install of a package that is unverified, brand-new, or absent from your allowlist is warned on or blocked, with the interception in the audit trail, so the fabricated dependency never reaches the install step. Security Rules load the discipline itself into the agent's context before it writes, so "verify a dependency exists and is trusted before adding it" is a rule the agent reads at prompt time rather than a checklist item nobody applied. Alongside them, Live Findings keeps every result from CybeDefend's scanners (SAST with reachability, SCA, secrets, IaC and CI/CD) live in the agent's context, so a dependency issue is triaged in the loop instead of surfacing days later.

And CybeDefend's SCA refreshes its vulnerability intelligence continuously, a fresh pull roughly every fifteen minutes, so the moment a package is disclosed as malicious it surfaces in the agent within minutes rather than on the next nightly scan, and every dependency the agent pulls in is checked in the loop. The two layers close each other's gaps: Action Guard stops the install of a brand-new package no one has flagged yet, and continuously refreshed SCA catches the ones that are only revealed as malicious later.

Crucially, nothing about your code crosses the wire. Decisions happen locally next to the agent; only structured governance metadata (the rule that fired, the file path, the severity, a timestamp) reaches the backend, and EU and US tenants are physically separate. This is not a replacement for lockfiles, allowlists, and human review. It is the layer that makes them enforceable at the speed an agent actually works, so the install of a package that was never real is stopped before it happens, instead of investigated after.

CybeDefend is the agent-time AppSec layer built for exactly this. It wires every AI coding agent on your machine to your business rules, your security frameworks (OWASP, SOC 2, GDPR, ISO 27001), an Action Guard that blocks unsafe or unverified installs before they run, and continuously refreshed scanning of every dependency and every line the agent writes. Slopsquatting only works in the gap between a model inventing a name and a human noticing. CybeDefend closes that gap, inside the loop, before the PR is ever opened.

Frequently asked questions

What is slopsquatting?

Slopsquatting is a software supply-chain attack that registers a package name an AI model is likely to hallucinate, so that developers and AI coding agents install the attacker's malicious package believing it is a real dependency. The term, coined by the Python Software Foundation's Seth Larson in April 2025, combines "AI slop" and "typosquatting." It works because large language models invent plausible package names that do not exist, and they invent the same ones consistently, giving attackers a predictable list of names to claim.

What is the difference between slopsquatting and typosquatting?

Typosquatting exploits human typing errors by registering names that closely resemble real packages, so it can be detected by measuring string distance from popular libraries. Slopsquatting exploits AI hallucination by registering entirely fabricated names that a model invents, which are not misspellings of any real package and therefore evade lookalike detection. In short, typosquatting bets on your fingers slipping; slopsquatting bets on your AI assistant inventing a dependency and installing it for you.

What is the HalluSquatting attack?

HalluSquatting is a 2026 escalation of slopsquatting described in the paper "Beware of Agentic Botnets" (arXiv, 8 July 2026). Instead of waiting for a model to happen upon a name the attacker already owns, it uses a universal, transferable adversarial trigger to make AI agents hallucinate a specific attacker-chosen resource on demand, then chains it with indirect prompt injection to achieve remote code execution and spread botnet malware. The researchers reported hallucinated-resource rates up to 85% for repository cloning and 100% for skill installation across nine assistants including Cursor, Windsurf, Copilot, Cline and Gemini CLI.

How common are AI package hallucinations?

Very common. A USENIX Security 2025 study of 2.23 million AI-generated code samples found 19.7% referenced at least one hallucinated package, catalogued 205,474 unique fabricated names, and showed the hallucinations are repeatable: 43% of them recurred across all ten re-runs of the same prompt. Open-source models were worse (21.7%) than commercial ones (5.2%). The repeatability is what makes the problem exploitable, because attackers can predict and pre-register the names a model favors.

Can an SCA scanner or typosquatting detection catch slopsquatting?

Not reliably, and for two different reasons. Typosquatting detection looks for names within a small edit distance of real packages, but a hallucinated name is fabricated rather than a near-miss, so it is not close to anything the filter watches. Software composition analysis runs after a package is installed and looks for known-vulnerable versions, but a freshly registered malicious package has no CVE yet, and its install script has already executed by the time SCA looks. Both are worth running as backstops; neither stops the install itself.

How do I stop my AI coding agent from installing hallucinated packages?

Do not let agents install dependencies unattended, verify that any new package genuinely exists and has real history before it is added, constrain installs to a private registry or allowlist, and commit lockfiles with integrity hashes so new dependencies are visible and reviewable. Because these checks only help if something enforces them before the install command runs, the durable fix is agent-time enforcement: a control like VibeDefend that intercepts the install of an unverified or non-existent package inside the agent loop, rather than a scanner that reads the damage afterward.