Slopsquatting and AI Supply Chain Attacks: A Defense Guide

Your AI Coding Assistant Is Recommending Packages That Do Not Exist

In April 2025, Seth Larson, Python Software Foundation Developer-in-Residence, coined a term for a new attack vector: slopsquatting. The concept is simple and devastating: AI coding tools hallucinate package names that do not exist, and attackers register those names as malware.

A USENIX Security 2025 study analyzed over 576,000 code samples across 16 LLMs and found that 19.7% of recommended packages did not exist. That is roughly one in five AI-suggested dependencies pointing to a package name that an attacker could register.

This is not theoretical. Security researcher Bar Lanyado of Lasso Security registered huggingface-cli, a name frequently hallucinated by LLMs, as an empty package on PyPI. It received over 30,000 downloads in three months. Major companies including Alibaba were found referencing this hallucinated package in their own public documentation.

The vibe coding culture makes this worse. When developers "Accept All" without reading the code, hallucinated package names go straight to npm install or pip install without a second look.

How Slopsquatting Works

The attack flow has three steps:

1. AI hallucinates a package name: A developer asks an LLM to solve a problem. The LLM recommends import fast-json-validator or pip install azure-ml-utils. These packages sound plausible but do not exist.

2. Attacker registers the name: An attacker monitors LLM output patterns (or simply generates thousands of code samples and collects non-existent package names). They register these names on npm, PyPI, or other registries with malicious payloads.

3. Developer installs the malware: The developer copies the AI-suggested code, runs npm install or pip install, and the malicious package executes. Payloads range from credential theft to remote shells to cryptocurrency drainers.

What makes this different from traditional typosquatting: the "typo" is generated by the AI, not the human. The developer typed the package name correctly. The AI just hallucinated a name that does not exist.

“Attackers do not need to scrape massive prompt logs or brute force potential names. They can simply observe LLM behavior, identify commonly hallucinated names, and register them.”

Socket.dev Security Research

The Data: How Bad Is AI Package Hallucination?

The USENIX Security 2025 Study

The most comprehensive research comes from Spracklen et al. at the University of Texas at San Antonio and Virginia Tech, published at USENIX Security 2025. Their methodology: generate code samples across Python and JavaScript using 16 commercial and open-source LLMs, then verify every recommended package against official registries.

The repeatability finding is the most alarming. 43% of hallucinated package names appeared in every single re-run (10 out of 10 times). This means attackers can predict with high confidence which fake names a model will suggest, making the attack scalable.

The Lasso Security Demonstration

Bar Lanyado's research tested hallucination rates in conversational settings across multiple models:

• Gemini: 64.5% of conversations produced hallucinated packages
• GPT-4: 24.2%
• GPT-3.5: 22.5%
• Coral: 29.1%

After identifying huggingface-cli as a consistently hallucinated name, Lanyado registered it as an empty (non-malicious) package on PyPI. The result: over 30,000 downloads and adoption into documentation by major companies. If the package had contained malware, thousands of systems would have been compromised.

The Veracode Broader Picture

Veracode's 2025 GenAI Code Security Report tested 100+ LLMs and found that 45% of AI code generation tasks introduced a known security flaw. Language-specific rates:

• Java: 72% security failure rate
• JavaScript: 43%
• Python: 38%
• Cross-Site Scripting (CWE-80): AI failed in 86% of relevant code samples

Newer and larger models do not generate significantly more secure code than their predecessors. The problem is structural, not incremental.

“The Pareto optimality boundary between code generation performance and package hallucination is sparsely populated, suggesting that coding models are not being optimized for secure code.”

Importing Phantoms (arXiv:2501.19012)

Vibe Coding Amplifies the Risk

The vibe coding movement (coined by Andrej Karpathy in February 2025, named Collins English Dictionary Word of the Year 2025) encourages developers to "fully give in to the vibes" and "Accept All" without reading the code. This is a supply chain attacker's dream scenario.

The Numbers Are Stark

Palo Alto Unit 42 found:

• 99% of survey respondents use GenAI-assisted coding
• 52% of teams ship code weekly
• Only 18% can fix vulnerabilities at the same pace they ship
• Unit 42 introduced the SHIELD framework: Separation of duties, Human in the loop, Input/output validation

Wiz Research found security risks in 20% of vibe-coded apps, with insecure authentication as a primary risk pattern.

The Acceleration Problem

When a developer vibe-codes, they:

1. Accept AI-generated import statements without verifying packages exist
2. Run npm install or pip install without checking package provenance
3. Skip lockfile review, allowing new dependencies to enter unexamined
4. Do not audit package.json or requirements.txt changes

Each of these steps is a point where a slopsquatted package can enter the codebase undetected. Without human review at dependency changes, the attack surface is wide open.

The Broader AI Supply Chain Threat Landscape

Slopsquatting is not the only AI-specific supply chain attack. The 2025-2026 threat landscape includes several related vectors:

IDEsaster Vulnerabilities

Security researcher Ari Marzouk disclosed 30+ CVEs in AI-powered IDEs affecting Cursor, Windsurf, Kiro.dev, GitHub Copilot, Zed.dev, Roo Code, and Junie. Attack success rates reached 84% for executing malicious commands through the IDE.

Rules File Backdoor

Pillar Security discovered that attackers could inject hidden malicious instructions into AI coding agent configuration files (.cursorrules, .github/copilot-instructions.md). Using invisible Unicode characters undetectable to humans but readable by AI agents, attackers could instruct the AI to insert backdoors into generated code. GitHub implemented Unicode text warnings on May 1, 2025 in response.

Malicious Package Campaigns

Socket.dev's 2025 Mid-Year Threat Report documented campaigns weaponizing benign-looking libraries to deliver infostealers, remote shells, and cryptocurrency drainers. Considering that 70-90% of a typical codebase consists of third-party packages, the attack surface is massive.

Dependency Confusion

Originally demonstrated by Alex Birsan in 2021 (hacking 35+ major companies including Apple, Microsoft, Tesla), dependency confusion gets amplified by AI. The USENIX paper notes that AI package hallucination "combines aspects of typosquatting and dependency confusion but is triggered by AI hallucinations rather than human error."

Defense Strategies: A Layered Approach

No single tool prevents slopsquatting. You need defense in depth.

Layer 1: Lockfiles and Dependency Auditing

The most basic defense: maintain lockfiles (package-lock.json, poetry.lock, Cargo.lock) and review every change to them.

• Run npm audit or pip-audit in CI/CD before every merge
• Flag any new dependency additions for manual review
• Use --frozen-lockfile in production builds to prevent unreviewed additions

Layer 2: Package Provenance and Attestation

Both npm and PyPI now support cryptographic package provenance:

npm Trusted Publishers:

• OIDC-based authentication eliminating long-lived tokens
• Automatically generates provenance attestations
• Over 16,000 packages now published with provenance

PyPI Attestations:

• Trusted publishers cover 20%+ of all file uploads
• Digital attestations for PyPI Publish and SLSA Provenance
• New typosquatting detection warns maintainers before confusing names are registered

Layer 3: Real-Time Package Analysis

• Socket.dev: Monitors AI-hallucinated package registrations, detects slopsquatting patterns in real time
• Snyk: Typosquatting scanners flag suspicious packages during installation; security policies detect packages with suspicious characteristics (recent creation, low download counts)
• SLSA Framework: Supply-chain Levels for Software Artifacts, providing four progressive levels of assurance. Check slsa.dev for the current version.

Layer 4: Sandboxed Installation

Trend Micro recommends isolated installation environments:

• Transient Docker containers or ephemeral VMs for new dependency testing
• Provenance tracking with cryptographically signed SBOMs
• Automated vulnerability scanning (Safety CLI, OWASP dep-scan) in CI/CD

Layer 5: AI Agent Constraints (CLAUDE.md Rules)

Your CLAUDE.md or project rules can constrain AI agents from installing unverified packages. While no canonical guide exists yet for anti-slopsquatting rules (this is emerging practice), effective rules include:

## Dependency Management Rules

- NEVER install new packages without explicit user approval
- Before suggesting any package, verify it exists on the official registry
- For any new dependency, check: package age, download count, maintainer history
- Prefer well-established packages with >10,000 weekly downloads
- Document the reason for every new dependency in the PR description
- Use exact versions in package.json, not ranges

These rules help because Claude Code loads CLAUDE.md at the start of every session as persistent instructions. CLAUDE.md is guidance, though: to actually block an install, add a permission deny rule or a PreToolUse hook, and back it with the CI/CD quality gates covered in Part 3 of our AI Technical Debt series.

Layer 6: Governance (Thread-Based Engineering)

Tools catch known patterns. Humans catch novel ones. Thread-based engineering requires human review at critical checkpoints, and dependency changes should always be one of those checkpoints.

The governance model:

1. AI generates code with dependency suggestions
2. Pre-commit hooks flag any changes to package.json or requirements.txt
3. Human reviewer verifies each new dependency against the registry
4. CI/CD runs provenance checks and vulnerability scanning
5. Only after all gates pass does the dependency enter production

We follow this at Pixelmojo through policy rather than a hook: a dependency change needs an explicit justification, and every pull request, dependency changes included, gets a human review before merge.

What the Industry Is Doing About It

Registry Responses

PyPI (2025 improvements):

• Typosquatting detection that warns maintainers before confusing names are registered
• Domain resurrection checks to block expired domain exploitation
• Spam prevention filters blocking abusive registration sources
• 52% two-factor authentication adoption among active users
• 3.9 million new files and 130K new projects delivered with these protections

npm:

• Trusted publishing via OIDC standard
• Automatic provenance attestation generation
• Over 16,000 packages with verified provenance

GitHub:

• Unicode text warnings implemented May 1, 2025 after Pillar Security disclosure
• Copilot patches for prompt injection vulnerabilities released December 2025

The SLSA Framework

The SLSA (Supply-chain Levels for Software Artifacts) framework, managed by OpenSSF, provides a standardized approach to supply chain integrity. Check slsa.dev for the current version and implementation guides. The framework is being adopted across npm, PyPI, and other registries through the trusted publishers standard.

“Vibe coders do not directly interact with code and are consequently unable to assess, much less guarantee, code quality.”

Lawfare Media

AI-Specific Defense: What LLMs Can Do About Their Own Hallucinations

Interestingly, TechRepublic reports that GPT-4 Turbo and DeepSeek can detect and flag hallucinated packages in their own output with over 75% accuracy. This suggests a future where AI coding assistants self-verify their dependency recommendations before presenting them to developers.

Until that becomes standard, the responsibility falls on:

1. Tool providers to implement package verification in the suggestion pipeline
2. Registry operators to flag and quarantine suspicious package registrations
3. Development teams to enforce governance at dependency boundaries
4. Individual developers to not blindly accept AI-generated import statements

Connecting to the Bigger Picture

Slopsquatting is one manifestation of the broader AI technical debt crisis. The same forces that create unmaintainable code (accepting AI output without review) create supply chain vulnerabilities (accepting AI-recommended packages without verification).

The defenses are consistent across both problems:

• CLAUDE.md optimization constrains AI behavior at generation time
• Thread-based engineering provides human checkpoints at critical boundaries
• CI/CD quality gates automate what can be automated
• Production guardrails catch what slips through

The teams that implemented governance early (as we described across our 4-part AI Technical Debt series) are better placed against slopsquatting. The same human review checkpoints that prevent bad code from merging also prevent malicious packages from entering the dependency tree.

Conclusion: Governance Is the Defense

Slopsquatting turns a quirk of AI (hallucinating plausible-sounding names) into a weaponized attack vector. The defense is not waiting for models to stop hallucinating. It is building governance that catches hallucinated dependencies before they reach production.

The same governance framework we have been building across our AI Technical Debt series directly addresses this threat. CLAUDE.md constrains AI behavior. Thread-based engineering provides human checkpoints. CI/CD quality gates automate verification. Together, they make slopsquatting a solvable problem rather than an inevitable one.

Ready to secure your AI-assisted development pipeline?

• AI Product Development - Supply chain security built into every project
• Contact Us - Let us help you implement AI governance that prevents supply chain attacks