Back to Blog
Supply Chain

Slopsquatting: How AI-Hallucinated Packages Are Poisoning Your Supply Chain (and How to Stop It)

Slopsquatting is the fastest-growing software supply chain attack of 2026. Learn how AI coding assistants hallucinate fake npm packages, how attackers weaponize them, and how to scan your dependencies before they reach production.

June 5, 2026
Belsoft Team
10 min read

What Is Slopsquatting?

Slopsquatting is a software supply chain attack that weaponizes a well-documented flaw in AI coding assistants: they hallucinate package names that do not exist. When a developer—or an autonomous AI agent—blindly runs the suggested install command, they can pull down an attacker-controlled package instead of safe, real code.

The name is a play on "typosquatting." But where typosquatting relies on a human fat-fingering a real package name, slopsquatting relies on the predictable "slop" that large language models produce. Attackers no longer have to guess your typos. They watch which names the AI invents, register those exact names on npm or PyPI, and wait for the installs to roll in.

Research across multiple 2026 studies found that roughly **20% of AI-generated code samples reference packages that do not exist.** That is not a rounding error—it is a massive, machine-generated attack surface that grows every time someone vibe-codes a new app.

Why AI Coding Assistants Hallucinate Packages

Large language models predict the most statistically likely next token, not the truth. Ask an LLM to "import a library that removes unused imports," and it confidently produces a name that *sounds* right based on patterns in its training data—even if no such package was ever published.

Two properties make this dangerous:

  • **The hallucinations are repeatable.** The same model, given a similar prompt, tends to invent the same fake name. Attackers can reproduce the hallucination, then register the package and harvest every developer who hits it.
  • **The names are plausible.** Models blend real packages into believable hybrids. In January 2026, a security researcher documented `react-codeshift`—a name an LLM invented by mashing together the real `jscodeshift` and `react-codemod` packages. Real AI agents were observed trying to execute it.
  • How a Slopsquatting Attack Actually Works

    The attack chain is short and brutally effective:

    1. An attacker prompts popular models with realistic coding tasks and records the fake package names they hallucinate.

    2. The attacker publishes malicious packages under those exact names to a public registry like npm or PyPI.

    3. A developer asks their AI assistant for help, gets code that imports the hallucinated name, and runs `npm install`—or an AI agent does it autonomously, with no human in the loop.

    4. The malicious package executes an install script, exfiltrates environment variables and secrets, or plants a backdoor that ships straight to production.

    Because the install often happens inside an automated agent or CI pipeline, the malicious code can run with elevated permissions and direct access to your cloud credentials.

    Real Slopsquatting Incidents in 2026

    This is not theoretical. Documented cases are already in the wild:

  • **The `unused-imports` package.** AI models repeatedly hallucinate this name instead of the legitimate `eslint-plugin-unused-imports`. As of early 2026, a malicious package squatting that name was still recording roughly 233 weekly downloads even after being flagged.
  • **`react-codeshift`.** A hallucinated name spreading through real AI infrastructure, with live agents attempting to resolve and execute it.
  • Security researchers tracking AI-generated vulnerabilities saw a sharp climb in 2026, and slopsquatting is a major contributor: it turns a model's confident guess into a direct path into your build.

    Why Slopsquatting Is Worse Than Classic Typosquatting

    Traditional typosquatting depends on human error and scales linearly—one typo at a time. Slopsquatting scales with AI adoption:

  • **It is automated on both sides.** AI generates the bad import; AI agents install it. A human may never review the dependency list.
  • **It exploits trust in the assistant.** Developers assume a confident AI suggestion is real. That trust is exactly what the attacker monetizes.
  • **It hits CI and agents hardest.** Autonomous pipelines install dependencies without a skeptical human asking, "Wait, is that a real package?"
  • How to Prevent Slopsquatting: A Practical Checklist

    #

    Verify Every Package Before You Install

    Never run an install command an AI suggested without confirming the package is real and maintained. Check the registry page, the GitHub source, the download counts, the publish date, and the maintainer history. A package that appeared last week with one version and no repository is a red flag.

    #

    Use a Dependency Allowlist

    Restrict installations to a vetted set of approved packages and internal mirrors. If a name is not on the allowlist, the install fails. This single control neutralizes most slopsquatting because the hallucinated name never resolves.

    #

    Lock and Verify with Checksums

    Commit your lockfile and enforce integrity checks. Use `npm ci` with a frozen lockfile in CI so builds install only the exact, verified versions you already reviewed—not whatever an agent decided to add.

    #

    Scan Dependencies Automatically in Every Build

    Add an automated dependency audit to CI so no human has to remember it:

    # Fail the build if a dependency is unknown, malicious, or vulnerable

    npm audit --audit-level=high

    npx deployready@latest analyze . --fail-on critical

    #

    Sandbox AI Coding Agents

    Run AI-suggested installs inside disposable containers with no network egress to anywhere but your approved registry. If a malicious post-install script fires, it has nothing to phone home to and no secrets to steal.

    How DeployReady Catches Slopsquatting

    DeployReady audits your dependency tree as part of its pre-deployment scan. It cross-references every package against known registries, flags names that look hallucinated or recently registered, maps known issues to CVE databases, and surfaces them in your production-readiness score before the code ships.

    npx deployready@latest analyze ./my-app

    ✦ Auditing dependencies...

    🔴 CRITICAL: Suspicious dependency "react-codeshift" not found on npm registry

    🔴 CRITICAL: Hardcoded secret in .env

    🟡 WARNING: 2 outdated packages with known CVEs

    Production Readiness Score: 31 / 100

    Because the check runs locally and in CI, you catch a hallucinated package the moment it enters your project—not after it has already run in production.

    The Bottom Line

    Slopsquatting is what happens when AI's confident guesses meet a public package registry. As more teams let AI assistants and agents manage their dependencies, the attack surface only grows. The defense is unglamorous but effective: verify every package, lock and allowlist your dependencies, sandbox your agents, and run an automated dependency audit on every build.

    npx deployready@latest analyze .

    Catch the hallucination before it catches you.

    Resources

  • CSA Research — Slopsquatting and AI Supply Chain: https://cloudsecurityalliance.org/
  • Slopsquatting on Wikipedia: https://en.wikipedia.org/wiki/Slopsquatting
  • OWASP Top 10: https://owasp.org/www-project-top-ten/
  • npm audit docs: https://docs.npmjs.com/cli/v9/commands/npm-audit
  • ---

    **Worried your AI-generated dependencies are hiding a slopsquatting risk?** [Run a free production-readiness scan](https://www.npmjs.com/package/deployready) or [contact our team](https://www.belsoftsolutions.com/contact).

    About the author

    The DeployReady team creates production-readiness tools for developers building with AI and building in general. We're passionate about security, performance, and shipping code with confidence.

    Ready to check your app's production readiness?

    DeployReady scans your code and running application to find security vulnerabilities, performance issues, and deployment risks—before they reach production.