Slopsquatting: AI Package Hallucination Attacks

When Your AI Coding Assistant Becomes an Attack Vector

There is a quiet but dangerous supply chain attack brewing in the AI-assisted development world, and most security teams have no specific defense against it. It is called 'slopsquatting' — a portmanteau of 'slop' (a colloquial term for AI-generated nonsense) and 'typosquatting' (the classic attack of registering misspelled domain or package names). The concept is deceptively simple: LLMs hallucinate fake software package names, attackers register those names on repositories like PyPI or npm, and unsuspecting developers install malicious code.

The issue recently resurfaced in the security community when a developer working through the OWASP LLM Top 10 for 2025 — specifically LLM09:2025 (Misinformation) — realized that while they had built hallucination detection into their AI security proxy, they had never explicitly accounted for package hallucination as a distinct threat vector.

'I'd seen it happen. I'd caught it myself because I know PyPI well enough to recognize when a package name smells wrong,' the developer noted. The implication was clear: expertise saved them, but most developers would not be so lucky.

How Slopsquatting Works

The attack chain is straightforward and alarmingly effective:

1. LLM Hallucination: A developer asks an AI coding assistant — ChatGPT, Copilot, Claude, or any other — for help with a coding problem. The model confidently recommends a package that does not exist. This is not rare; studies have shown that LLMs fabricate package names in a significant percentage of code suggestions.

2. Attacker Registration: Malicious actors systematically query popular LLMs, catalog the fake package names they generate, and register those names on public repositories like PyPI, npm, or RubyGems.

3. Developer Installation: A developer, trusting the AI's recommendation, runs pip install fake-package-name or npm install hallucinated-lib. The malicious package executes, potentially exfiltrating credentials, injecting backdoors, or compromising the entire CI/CD pipeline.

What makes slopsquatting particularly insidious is the trust factor. Typosquatting relies on human error — a misspelled reqeusts instead of requests. Slopsquatting relies on machine authority. Developers are increasingly conditioned to trust AI-generated code suggestions, and a confidently stated package name from GPT-4 or Claude carries implicit credibility.

The Scale of the Problem

Research from several security teams has begun quantifying the risk. A March 2024 study by researchers at the University of Texas at San Antonio and other institutions found that when prompted with coding tasks, popular LLMs hallucinated package names approximately 20% of the time across languages like Python and JavaScript. Of those hallucinated names, a meaningful percentage were consistent — the same fake names appeared repeatedly across different sessions and users, making them prime targets for attacker registration.

Security firm Socket, which monitors open-source package registries for malicious uploads, has flagged a growing trend of newly registered packages whose names correlate strongly with known LLM hallucination patterns. While not every suspicious registration is confirmed malicious, the pattern is unmistakable.

The npm registry alone hosts over 2 million packages, and PyPI surpassed 500,000 projects in 2024. The sheer volume makes manual review impossible, and automated scanning tools are only beginning to incorporate AI hallucination awareness into their detection models.

Why Current Defenses Fall Short

Most organizations defending against supply chain attacks focus on three areas: dependency pinning, lockfile enforcement, and known-vulnerability scanning (tools like Dependabot, Snyk, or Grype). None of these address slopsquatting directly.

Dependency pinning assumes the package was legitimate to begin with. If a developer adds a hallucinated package to requirements.txt, pinning its version does not make it safe.

Lockfiles capture whatever was installed, including malicious packages. They prevent drift, not initial compromise.

Vulnerability scanners rely on databases of known CVEs. A freshly registered malicious package masquerading as a hallucinated name has no CVE — it is a zero-day by definition.

Even AI security proxies and guardrails — like the developer's 'Sentinel' system mentioned in the OWASP training scenario — typically focus on prompt injection, data leakage, and content policy violations. Package hallucination detection requires a fundamentally different approach: real-time validation of recommended packages against actual registry data.

The OWASP LLM Top 10 Connection

The OWASP LLM Top 10 for 2025 categorizes package hallucination under LLM09: Misinformation. This is accurate but arguably undersells the risk. Misinformation in the OWASP framework covers a broad range of issues — from factual inaccuracies to misleading summaries. Package hallucination is a weaponizable form of misinformation with a direct path to code execution.

Some in the security community argue it deserves its own subcategory or even a distinct entry. The attack does not just mislead — it creates a concrete, exploitable artifact (a package name) that can be claimed and poisoned by adversaries.

Defending Against Slopsquatting

Organizations serious about mitigating this threat should consider a multi-layered approach:

1. Registry Validation at the IDE Level: Before any pip install or npm install triggered by an AI suggestion, validate that the package exists, has a meaningful download history, and has been published by a verified maintainer. Tools like Socket and pip-audit can help, but integration needs to happen before installation, not after.

2. AI Output Filtering for Code Suggestions: If you are running an AI proxy or gateway (like Sentinel, Prompt Security, or Lakera), add rules specifically for package name validation. Cross-reference any package names in AI-generated code against known registries in real time.

3. Private Registry Enforcement: For enterprise environments, mandate that all packages come from a curated internal mirror (Artifactory, Nexus, or CodeArtifact). If a hallucinated package name is not in the mirror, it cannot be installed.

4. Developer Awareness Training: This is perhaps the most important and least technical defense. Developers need to understand that AI coding assistants hallucinate packages regularly and that a confidently stated package name is not proof of existence. The same skepticism applied to phishing emails should be applied to AI-recommended dependencies.

5. LLM Provider Responsibility: OpenAI, Anthropic, Google, and other model providers should implement guardrails that cross-check package recommendations against live registry data. Some progress is being made here — Anthropic's Claude, for instance, increasingly hedges when recommending packages it is not certain about — but the industry has a long way to go.

What Comes Next

Slopsquatting sits at the intersection of two massive trends: the rapid adoption of AI coding assistants and the persistent fragility of open-source supply chains. As tools like GitHub Copilot, Cursor, and ChatGPT become default development companions for millions of engineers, the attack surface expands proportionally.

The security industry is beginning to respond. Expect to see dedicated slopsquatting detection features in supply chain security platforms by late 2025. Package registries like PyPI and npm are also exploring stricter name registration policies and AI-hallucination-aware moderation.

But the window of vulnerability is open right now. Every developer using an AI assistant without package validation is a potential target. And unlike traditional supply chain attacks that require sophisticated social engineering or build system compromises, slopsquatting requires nothing more than patience and a script that queries ChatGPT.

The developer who discovered this gap during OWASP training put it best — they caught the problem because they knew PyPI well enough to smell something wrong. The question every security team should ask today: do all your developers have that instinct? And if not, what is catching the hallucinations before they become installations?