Slopsquatting is the term coined by researchers in 2024 and 2025 for a specific class of supply-chain attack: registering a package name that large language models hallucinate when answering coding questions, so that when a developer pastes the suggested npm install command they install a package controlled by the attacker. The term is a portmanteau of "slop" and "typosquatting," and it names a risk that sits at the intersection of registry hygiene and AI model behavior.
The research that established the scale of this risk includes work from Lasso Security, Socket, Bar-Ilan University, and independent researchers who have published repeated measurements through 2024, 2025, and into 2026. Their core finding is consistent: LLMs hallucinate package names at a non-trivial rate, the hallucinations are often stable across prompts, and the hallucinated names are registerable on public registries. This post summarizes what those researchers have published and what the implications are for teams that let AI assistants write install commands.
What is slopsquatting, precisely?
Slopsquatting, precisely, is the practice of registering a package name that is likely to appear in LLM-generated code output even though the name does not correspond to a real, legitimate package. The attacker monitors LLM outputs, either by sampling public chatbots or by inference from known hallucination patterns, identifies names that are plausible but unclaimed, registers those names on npm or another registry, and ships a payload. When a developer or an agentic coding tool runs the hallucinated install command, the attacker's package executes.
This is distinct from typosquatting, where the attacker bets on human typing errors, and from dependency confusion, where the attacker bets on resolver order between public and private scopes. Slopsquatting bets on model behavior.
How often do LLMs hallucinate package names?
LLMs hallucinate package names often enough to be exploitable in practice, according to research published in 2024 and 2025. The widely-cited Lasso Security study from 2024 reported hallucination rates in the single-digit to low-double-digit percentages for npm install suggestions, varying by model and prompt. Bar-Ilan University and other academic follow-ups published in 2025 confirmed that the phenomenon persists across model generations, that it is more common for niche topics than for mainstream libraries, and that many hallucinations are stable, meaning the same model will produce the same wrong name repeatedly.
Stability is the key property that makes slopsquatting economically attractive to attackers. If a hallucinated name appears only once and never again, it is not a reliable distribution channel. If the same name appears across millions of user sessions, it is.
Are there documented slopsquatting incidents on npm?
There are documented slopsquatting incidents on npm, though the public catalog is still small compared with typosquatting. Socket, Phylum, and ReversingLabs have each blogged about specific packages that matched known LLM-hallucinated names and that carried malicious payloads. In several cases the packages had been published before the researchers or registries became aware of the hallucination pattern, which is consistent with attackers monitoring model outputs proactively rather than reactively.
Absolute incident counts are hard to compare across vendors because classification criteria differ. What is not disputed is that the attack class is real, the names are registerable, and the developer-facing install workflow does not distinguish a slopsquat from a legitimate install.
Why do agentic coding tools make this worse?
Agentic coding tools make this worse because they close the loop between hallucination and execution. A developer using a chat-based assistant still has to read the suggested command, copy it, and run it; they have a chance, however fleeting, to notice that the package name looks unfamiliar. An agentic tool that is authorized to run shell commands on its own can install the hallucinated package within a few seconds of suggesting it, and the developer may not review the specific install step.
This is not hypothetical. Several developer-tool vendors now ship agents that can run npm install autonomously inside a container or a dev sandbox. If the agent hallucinates a package name and the attacker has registered that name, the agent will execute the malicious install without any human touching the keyboard. The blast radius depends on what else the agent is authorized to access.
Can model providers fix this at the model layer?
Model providers can partially fix this at the model layer, and several are working on it, but a complete fix from the model side alone is unlikely. The standard mitigations under research include retrieval-augmented generation that grounds install suggestions in a verified package index, tool-use patterns where the model calls out to a registry-lookup function before suggesting an install, and fine-tuning datasets that penalize hallucinated names. Each helps, but each also introduces latency and coverage costs, and none is universally deployed.
The more robust fix sits at the registry and organization layer. A registry that distinguishes between popular, audited packages and obscure new uploads gives developers and agents a signal they can act on. An organization that restricts installs to a curated set of vetted packages forecloses the problem entirely for its own builds, at the cost of requiring a process to approve new packages.
What should a team shipping AI-assisted code do in 2026?
A team shipping AI-assisted code should do three things in 2026. First, require that AI agents install packages only through a curated proxy or allowlist, so that a hallucinated name does not resolve to anything unless a human has reviewed it. Second, enforce lockfile review in code review, so that even if a hallucinated name sneaks in, it shows up as a conspicuous diff in the pull request rather than hiding in a transitive. Third, instrument post-install behavior; a package that makes unexpected outbound network calls on first import or install is almost certainly worth blocking, regardless of whether anyone ever flagged its name.
None of these steps are AI-specific. They are the same defense-in-depth measures recommended against typosquatting, protestware, and account takeovers. The addition of AI assistants simply raises the stakes and shortens the time between a hallucination and an execution.
Is this a temporary problem?
This is not a temporary problem on the scale of months or years. Hallucination rates will continue to drop as models improve, retrieval grounding becomes more common, and registries invest in agent-friendly APIs. But the underlying asymmetry, where the attacker can register a plausible-looking name and wait for a mistake, has existed on package registries since their creation. Slopsquatting is the newest expression of that asymmetry, not a fundamentally different risk class.
Organizations that build agent-driven development workflows should plan on this risk being persistent, and design their controls accordingly. That means assuming that at some point an agent will propose installing a package you have never heard of, and making sure your infrastructure catches that rather than trusting it.
How Safeguard.sh Helps
Safeguard.sh applies reachability analysis to AI-generated and human-written package manifests, cutting noise by 60 to 80 percent so that a slopsquatted package flagged at install time is not lost in a flood of low-severity findings. Griffin AI performs autonomous remediation, automatically replacing hallucinated package names with verified alternatives in pull requests. Eagle classifies new and unfamiliar packages using behavioral signals, identifying install-time stagers and suspicious network calls before they reach CI. The Gold registry offers a curated, vetted package index that agents can be pointed at safely, SBOM generation tracks dependencies 100 levels deep, and container self-healing rebuilds images when a suspicious slopsquat is identified after deployment.