2.5 Deprecated Libraries and Slopsquatting

Every AI-suggested dependency carries two separate risks. The first is straightforward: AI models typically suggest packages from training-data patterns rather than live registry lookups, so they may recommend outdated packages with known vulnerabilities — even when the tool could verify the package first. The second is more alarming: AI models sometimes invent package names that don't exist, and attackers have pre-registered many of those invented names with malicious code inside.

This section covers both risks and provides a concrete checklist to verify every package before it enters your codebase.

Deprecated and Outdated Libraries#

Why AI Suggests Outdated Packages#

Most AI coding assistants suggest libraries based on patterns learned during training — not by querying a live package registry. Even agentic tools like Claude Code that can run npm info or pip index versions to verify packages don't always do so automatically before suggesting a dependency. A model relying on training data with a fixed cutoff has no way of knowing:

• A package was deprecated and archived in 2024
• A security vulnerability (CVE) was published for a specific version in the past year
• The community has since moved to a more secure alternative

The problem is compounded by how training data is weighted. A library that was popular in 2019 is likely more heavily represented in the training data than its modern replacement — simply because more code was written using it over the years. Models tend to favor the most common pattern, not the most recent or most secure one.

The numbers show the scale of this problem: research by Aqua Security found that 8.2% of the most-downloaded npm packages are officially deprecated, and npm users download deprecated packages approximately 2.1 billion times per week. AI tools that recommend these packages contribute to this volume. A Snyk survey found that over 50% of organizations experienced outages or security incidents due to AI-generated code referencing outdated APIs.

There is also a less obvious danger: some maintainers deprecate packages specifically to signal a security flaw rather than filing a formal public CVE. When AI suggests one of these packages, it points you toward known-vulnerable code with no visible warning in its output.

How to Verify a Package Before Installing#

# Inspect an npm package before installing it
npm info <package-name>
# Key fields to read: version, time.modified (last publish), deprecated

# Scan installed dependencies for known CVEs
npm audit

# Check which versions of a Python package are available
pip index versions <package-name>

# Scan Python dependencies for known vulnerabilities
pip-audit

Warning signs to look for:

• deprecated field is set — npm displays this in npm info output; do not ignore it
• Last published more than 2 years ago — the package likely receives no security maintenance
• Weekly downloads far below what the AI implied — a package described as "widely used" should have the download numbers to match
• No GitHub repository, or a repository with no recent commits and many unresolved issues
• Open security advisories — check the npm advisory database and the GitHub Security tab for the package

Slopsquatting#

What Is Slopsquatting?#

Slopsquatting is a supply chain attack that exploits AI hallucination. The term was coined by Seth Larson, Developer in Residence at the Python Software Foundation, as a variation on "typosquatting" — except instead of betting on a developer's typo, the attacker bets on a package name invented by an AI.

AI models predict package names based on training-data patterns rather than looking them up in a live registry. Even agentic tools that could verify a name before suggesting it typically don't do so by default. When a model predicts a package name that sounds plausible but doesn't actually exist on any registry, that is a hallucination. Slopsquatting exploits this behavior in three steps:

1. AI models hallucinate package names at a measurable and consistent rate
2. Many hallucinations are stable — the same fake name appears reliably across different prompts, sessions, and sometimes across different models
3. Attackers identify those stable names and register them before any legitimate developer does

A USENIX Security 2025 study ("We Have a Package for You!" — Spracklen et al.) analyzed 576,000 code samples generated by 16 AI models and found that approximately 19.7% of package suggestions referenced packages that did not exist on PyPI or npm. Of those hallucinated names, 58% were stable and repeatable — appearing more than once across 10 identical runs of the same prompt.

Why Stable Hallucinations Make This Attack Practical#

If every AI hallucination were random, slopsquatting would be impractical — an attacker would need to register thousands of names hoping to match a single occurrence by chance. The 58% stability finding changes the picture completely.

A stable hallucination means the AI consistently produces the same fake package name for the same type of question — across different prompts, different sessions, and sometimes across different models. This makes the attack systematic: an attacker runs a batch of coding prompts, filters for names that appear reliably across repeated runs, and registers exactly those names. The USENIX researchers deliberately withheld their list of 205,474 unique hallucinated package names from publication to avoid handing attackers a ready-made target list.

The study also found that hallucinated names fall into three categories:

• 51% pure fabrications — invented names that sound like real packages (e.g., jwt-parse-utils, secure-validator-core)
• 38% conflations — two real packages merged into a single fake name (e.g., jscodeshift + react-codemod → react-codeshift)
• 13% typo variants — minor misspellings of real package names

Because most hallucinations are plausible fabrications rather than obvious typos, they are very hard to catch through visual inspection alone.

Hallucination Rates Vary Widely Across Models#

Not all AI coding assistants hallucinate at the same rate. The USENIX study found a significant gap between commercial and open-source models.

Commercial models showed roughly four times fewer hallucinations than open-source alternatives. However, even a 3.59% rate represents a significant attack surface when millions of developers are asking similar coding questions. If your team uses a self-hosted or less capable model, the risk is substantially higher.

Real-World Incidents#

The huggingface-cli experiment — The legitimate HuggingFace CLI is installed via pip install -U "huggingface_hub[cli]". Multiple AI models consistently hallucinated a shorter package name: huggingface-cli. Researcher Bar Lanyado (Lasso Security) registered this nonexistent name with a harmless test package to measure real developer demand. The result: over 30,000 authentic downloads in three months. Alibaba separately copy-pasted the hallucinated install command into the README of one of their public repositories — showing how a single AI hallucination can spread from one model's output into real codebases and official documentation.

The react-codeshift incident — The npm package name react-codeshift is a conflation of two real packages: jscodeshift and react-codemod. This hallucinated name appeared in 47 LLM-generated agent skills in a single GitHub commit, with no human ever manually writing it. By the time it was discovered, the phantom name had spread to 237 repositories and was receiving daily downloads from AI agents operating autonomously with no human in the loop.

Both incidents illustrate the same pattern: AI-hallucinated package names spread quickly through codebases and documentation. When AI agents have permission to run install commands on their own, there is no natural point at which a human would notice the fake package name.

The Package Verification Checklist#

Apply this checklist to every package an AI suggests — even ones with familiar-sounding names. Attackers also register names that differ from legitimate packages by just one character, or plausible-sounding combinations of two real package names.

Prefer Known Alternatives Over AI Suggestions#

For common tasks, well-established packages with years of history and millions of weekly downloads are almost always the right choice. When AI suggests an unfamiliar alternative to one of these, verify it carefully before installing.

A Note on AI Agents Installing Packages Autonomously#

The react-codeshift incident highlights a risk that grows as AI agents become more capable: when an agent has permission to run npm install or pip install without human review, it can install hallucinated — and potentially malicious — packages with no one ever seeing the install command. This is a specific instance of the excessive agency problem covered in Chapter 4.

The fix is the same as for all high-risk agent actions: package installation should require explicit human confirmation. The agent should propose the install command and show which package it intends to install; the developer verifies the package on the registry before approving. Never configure an AI agent to install packages automatically.

Sources:

• We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• Slopsquatting — when AI hallucinates package names (Seth Larson, Python Software Foundation)
• Can LLMs Generate Malicious Package Recommendations? (Lasso Security, 2024)
• Deprecated npm Packages: A Hidden Attack Surface (Aqua Security, 2025)
• Over 50% of Organizations Hit by AI-Generated Code Issues (Snyk, 2025)
• react-codeshift: How a Phantom npm Package Spread Through AI Agent Skills (Socket, 2025)