Slopsquatting: When AI-Hallucinated Packages Become Real Malware

What Is Slopsquatting and Why Should You Care?

Slopsquatting is a portmanteau of "slop" - the industry term for unreliable AI output - and "typosquatting," the long-standing attack where malicious packages mimic popular names with slight misspellings. But slopsquatting is more dangerous than typosquatting because the package names are not misspellings. They are entirely fabricated names that sound plausible, generated by AI models that predict tokens based on training patterns rather than verifying what actually exists in a registry.

Researchers from Apiiro analyzed code generated by multiple LLMs and found that AI models hallucinate package names at rates between 5% and 20% depending on the model and the programming language. That is not a rounding error. If an AI tool generates 40 import statements across a project, statistically two to eight of those could reference packages that do not exist. Each one is an empty namespace an attacker can claim.

The attack works because developers trust AI output. When Claude Code, Cursor, Bolt, or Lovable generates a file that imports react-form-validator-utils, most developers run npm install without checking whether that package is real. If an attacker has already registered it with a postinstall script that exfiltrates .env files, the damage is done before anyone reads a line of code.

How the Attack Chain Works

The slopsquatting attack follows a predictable pipeline. First, a researcher or attacker systematically prompts popular AI coding tools - Cursor, Bolt, Lovable, Claude Code, v0 - across thousands of common development tasks. They collect every package name the models suggest. Second, they cross-reference those names against npm, PyPI, and other registries to find names that do not yet exist. Third, they register those names with malicious payloads.

Socket.dev's 2024 supply chain security report documented over 12,000 malicious packages published to npm in a single quarter, many exploiting namespace confusion. The slopsquatting variant is particularly effective because the attacker does not need to guess what names developers might mistype. The AI models do the guessing for them - consistently and predictably.

The payload varies. Some packages run a postinstall script that reads environment variables and sends them to an external server. Others install a reverse shell. Some are subtler - they export functions that work correctly but also phone home with telemetry about the host system. The common thread is that npm install or pip install gives the package execution rights on your machine the moment it runs.

What makes this worse is persistence. Once an AI model hallucinates a particular package name for a given task, it tends to hallucinate the same name again. Every developer who prompts that task gets the same malicious suggestion.

What Slopsquatted Code Looks Like

Here is a realistic scenario. You ask an AI tool to add form validation to a Next.js project with Supabase:

// ❌ BAD - AI-hallucinated packages (slopsquatting targets)
import { validateEmail, validatePhone } from 'next-form-validator-utils';
import { sanitizeInput } from 'supabase-input-sanitizer';
import { createRateLimiter } from 'express-rate-limiter-redis';

export async function handleSignup(formData: FormData) {
  const email = sanitizeInput(formData.get('email') as string);
  const phone = validatePhone(formData.get('phone') as string);
  // ... rest of handler
}

None of those three packages exist on npm. The names sound reasonable - they combine real ecosystem terms (next, supabase, express, redis) with descriptive suffixes. An attacker who registers next-form-validator-utils gets code execution on every machine that runs this project's install step.

// ✅ GOOD - Verified real packages with registry checks
import { z } from 'zod';                           // npm: zod (real, 25M+ weekly downloads)
import DOMPurify from 'dompurify';                  // npm: dompurify (real, 5M+ weekly downloads)
import { Ratelimit } from '@upstash/ratelimit';     // npm: @upstash/ratelimit (real, scoped)

export async function handleSignup(formData: FormData) {
  const parsed = z.object({
    email: z.string().email(),
    phone: z.string().min(10).max(15),
  }).safeParse(Object.fromEntries(formData));

  if (!parsed.success) return { error: parsed.error.flatten() };

  const cleanEmail = DOMPurify.sanitize(parsed.data.email);
  // ... rest of handler
}

The fix uses well-known, heavily downloaded packages with verifiable registry presence. Before using any AI-suggested package, run npm info <package-name> to confirm it exists and check its download count, maintainer, and publish date.

Why Traditional Scanners Miss This Entirely

This is the gap that makes slopsquatting so effective. The standard security toolchain - npm audit, Snyk, Dependabot, Trivy - is designed to check installed packages against a database of known CVEs. They answer: "Does this package have a published vulnerability?" They do not answer: "Should this package exist at all?"

According to Snyk's 2024 State of Open Source Security report, 68% of applications contain at least one known open-source vulnerability. But known vulnerabilities are only half the problem. A slopsquatted package has no CVE because it was just registered. It has no advisory because nobody has reported it yet. It passes every standard security check with a clean bill of health - while executing a postinstall script that exfiltrates your AWS credentials.

Who Is Most at Risk

Solo founders and small teams building with AI tools are the primary targets. If you built your SaaS with Bolt or Lovable and deployed to Vercel without reviewing every import line, you are in the highest risk category. These platforms generate entire package.json files from scratch, and the developer often does not have deep npm ecosystem knowledge to recognize a fabricated name.

The risk compounds with certain patterns. Projects using Next.js with Supabase are heavily represented in AI-generated code because those stacks dominate the training data. AI models confidently generate Supabase-adjacent package names that do not exist - supabase-auth-helpers-nextjs (the real one is @supabase/auth-helpers-nextjs), supabase-storage-utils, supabase-realtime-client. Each unscoped name is trivially registrable on npm by anyone.

GitHub's 2024 Octoverse report found that supply chain attacks targeting the npm ecosystem grew 74% year-over-year. The intersection of AI-generated code and npm's open registration model makes slopsquatting one of the fastest-growing vectors in that statistic.

How to Protect Your Codebase

Defending against slopsquatting requires a shift in how you validate dependencies. Instead of only scanning for known vulnerabilities after install, you need to verify package legitimacy before install.

1. Verify before you install. For every AI-suggested package, run npm info <package-name> before running npm install. If it returns a 404, the package does not exist and the AI hallucinated it. If it exists but has zero or very low weekly downloads and was published recently, treat it as suspicious.
2. Check scoped vs unscoped names. Scoped packages (@org/package) are harder to squat because the attacker needs to own the npm organization. When AI suggests an unscoped name for something that should logically be scoped (like Supabase or Vercel utilities), that is a red flag.
3. Lock your dependencies. Always commit your lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml). Pin exact versions in package.json rather than using ^ or ~ ranges. This limits the blast radius if a package is compromised after you install it.
4. Use automated scanning. Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase for hallucinated imports and verify every package against the npm registry, flagging packages that don't exist before they become attack vectors. Free to sign up.
5. Audit postinstall scripts. Run npm install --ignore-scripts first, then review what scripts each new package wants to execute before allowing them.

FAQ