What Is Slopsquatting?

What is slopsquatting? It is an attack in which malicious actors register the exact package names that AI coding assistants hallucinate, then load those packages with malware and wait for a developer to install them. It is not an edge case. In research presented at USENIX Security 2025, 19.7% of packages recommended by AI coding models across 576,000 code samples did not exist, and researchers logged over 205,000 unique hallucinated names across the models tested.

Understanding what is slopsquatting (and what slopsquatting meaning looks like in practice) matters because it is not just an AI quirk. Slopsquatting is the AI-era successor to typosquatting, with one critical difference: typosquatting depends on a human’s typing mistake, while slopsquatting depends on a model’s mistake, repeated predictably enough for an attacker to exploit it at scale. This guide explains what slopsquatting is, why it spreads faster than package review can catch it, what risks it creates, and how organizations can discover and prevent it before it reaches production.

Slopsquatting Meaning: Definition #

Slopsquatting meaning, formally: the practice of registering a package name that a large language model hallucinates, an invented name that sounds plausible but does not exist in any public registry, and loading it with malicious code before a real developer installs it based on the AI’s suggestion.

The term extends the concept of typosquatting (registering a package name that mimics a real one through a common misspelling) to the specific failure mode of generative AI. Where typosquatting exploits a human’s typo, slopsquatting exploits an AI model’s hallucination: a coding assistant recommends pip install or npm install for a package that has never existed, and an attacker who has noticed the same invented name recurring across prompts registers it first.

Slopsquatting meaning, in practical terms, is this: a supply chain attack that turns a model’s mistake into a working exploit, with no human error required beyond trusting the AI’s suggestion. It is not theoretical. A single hallucinated package, planted as a benign test in 2023, drew over 30,000 downloads in three months with zero promotion and confirmed that malicious variants exploiting this exact pattern are live in public registries today.

Slopsquatting vs Typosquatting: What Is the Difference? #

Slopsquatting and typosquatting share the same outcome (a developer installs a malicious package believing it is legitimate), but the source of the error is categorically different.

Typosquatting depends on a human typing mistake: a developer means to type requests and types reqeusts instead, and an attacker who registered that misspelled name is waiting. The risk is bound to one developer’s keystroke, one moment of inattention.

Slopsquatting removes the human error entirely and replaces it with a model’s error, one that repeats at scale across every developer who receives a similar prompt. Follow-up analysis found that when researchers re-ran identical prompts ten times each, 43% of hallucinated package names showed up on every single run, and 58% recurred more than once. That repeatability is what makes slopsquatting exploitable: an attacker does not need to guess a typo. They only need to observe which hallucinated name a model keeps repeating and register it before a real developer does.

The biggest difference is scale. A typosquatted package waits for a typing accident. A slopsquatted package waits for the same AI-generated recommendation to reach the next developer, and the one after that, and the one after that, across every organization using the same model.

Why Slopsquatting Spreads? #

Slopsquatting proliferates for the same reason typosquatting always has: attackers exploit a predictable pattern that developers trust by default. What is new is the scale of trust.

The rise of AI-assisted coding, autonomous agents, and “vibe coding” workflows, where developers review less and less of the code before running it, has shifted the software attack surface in two concrete ways:

The entry point is no longer just the developer. A typosquatting attack depends on one person’s typing mistake. Slopsquatting can originate inside the model itself and propagate to hundreds of different developers who ask similar questions and receive the same hallucinated recommendation, multiplying the reach of a single attack.

The attack surface has moved further up the chain. It is no longer enough to review the code a human writes. Teams also need to watch the dependencies an AI assistant suggests, the MCP servers it connects to, and the agents that install packages autonomously with no direct human review. Traditional AppSec, built to review repositories and human commits, was never designed to observe this new interaction between developer, AI, and package registry, which is exactly where slopsquatting hides.

Slopsquatting Risks #

Slopsquatting creates risk across dimensions that compound each other, and the trend is accelerating rather than fizzling out.

• Repeatable exploitation. Because hallucinated names are not random, the same fake name resurfaces predictably across sessions and models. Attackers do not need to guess; they only need to observe model behavior and register the names that keep recurring, turning a one-off hallucination into a scalable, repeatable attack.
• Agentic propagation. Slopsquatting is no longer confined to a developer copy-pasting a suggested install command. In January 2026, researchers found that AI coding agents had already spread instructions referencing a hallucinated npm package across 237 repositories, with agents still attempting to install it daily, no human in the loop to catch the mistake.
• Name-similarity evasion. Roughly 38% of hallucinated names closely resemble real packages, lowering the odds that a developer spots the substitution at a glance. A malicious package sitting one character off from a trusted dependency does not look suspicious; it looks like a typo you’d make yourself.
• Persistent exposure after detection. A hallucinated package that replaced a legitimate ESLint plugin was still recording weekly downloads even after the registry placed it under a security hold, evidence that flagging a slopsquatted package does not immediately stop it from being installed.

Where Slopsquatting Hides #

The hardest part of slopsquatting to catch is that it does not look like an attack at the moment it happens; it looks like a normal pip install or npm install completing successfully, because the package genuinely exists once an attacker has registered it.

Slopsquatting typically enters through:

• AI coding assistants and copilots. The initial suggestion, an invented package name presented alongside legitimate, working code, is where the vulnerability originates. Nothing about the surrounding code looks wrong, because it usually isn’t; only the dependency is fake.
• Autonomous coding agents. Agentic workflows that install dependencies without human review remove the one checkpoint, a developer pausing to verify a name, that would otherwise catch a hallucinated package before it reaches a project.
• Package managers with no verification step. Neither pip install nor npm install throws an error when the target package exists and is malicious. The install completes normally because, from the package manager’s perspective, nothing is wrong.

How to Discover and Prevent Slopsquatting #

Preventing slopsquatting does not require exotic tooling. It requires applying dependency hygiene practices that already exist, systematically, rather than relaxing them the moment an AI “suggests” the code.

Verify any new package before installing it, especially one suggested by an AI assistant. Confirm it exists in the official registry, who maintains it, when it was published, and whether its download numbers look genuine.

Never assume AI-generated code is safe by default. Code that “works” doesn’t mean its dependencies are legitimate. Dependency review should be part of code review, not an exception to it.

Deploy dependency scanning that flags risk patterns beyond known CVEs: anomalous packages, names suspiciously similar to existing ones, new maintainers with no track record, or install scripts with unusual behavior.

Apply AI-SPM as the governance layer. AI Security Posture Management is the practice designed to catch exactly this kind of AI-introduced risk at scale, continuously discovering AI-suggested dependencies and scoring them before a human ever has to remember to check manually.

Securing Against Slopsquatting With Xygeni #

Slopsquatting cannot be prevented by developer vigilance alone. A policy that says “verify every AI-suggested package” does not scale across an organization where dependency suggestions arrive faster than any human review process can keep up with.

Xygeni’s approach treats this as a continuous detection problem: AI Inventory and AI BOM surface every AI-introduced dependency across the SDLC, giving teams a living record of what an AI assistant has actually suggested and installed. Xygeni Shield, powered by MEW (Malware Early Warning), detects and blocks malicious packages, including slopsquatted ones, before a signature exists, closing the exact gap that signature-based scanners leave open.

If your teams are using AI coding assistants, the slopsquatting problem is already present. The question is whether the next hallucinated name gets caught before it gets installed.

FAQ #