AI Hallucinated Imports: When npm Packages Don't Actually Exist

What Are Hallucinated npm Imports?

Large language models are trained on billions of lines of code, but that training data has a knowledge cutoff. Packages get renamed, deprecated, or unpublished. New utility patterns emerge and AI models construct plausible-sounding package names that happen not to exist. This is called a hallucinated import.

The problem shows up in two forms. First, the package simply does not exist on npm, so npm install throws a 404 and your CI pipeline fails. Second - and far more dangerous - the package name exists but is owned by someone else, and that someone may have published a malicious payload. This second scenario is called slopsquatting, a close cousin of dependency confusion attacks, the supply chain exploit one researcher used to get code running inside more than 35 companies.

Dependency confusion and typosquatting are well-known ways attackers get malicious code into projects through npm. When AI code introduces a fictitious package name, any attacker who registers that name on npm gains an execution vector into your codebase.

Vibe coding tools - Bolt, Lovable, Cursor, and v0 - are especially prone to this because they generate complete files without running npm install themselves. The output looks syntactically correct, the import line looks reasonable, and nothing fails until you actually try to build.

Why AI Models Invent Package Names

The root cause is how language models generate code. They predict the next most probable token. If a codebase they trained on used a certain import pattern, and a similarly-named real package existed at that time, the model will generate that import even if the package was later renamed, split, or deleted.

Common hallucination patterns include:

• Old package names: node-fetch vs cross-fetch vs native fetch - AI conflates these.
• Scoped package guesses: Generating @stripe/stripe-js when the actual package is @stripe/stripe-js is fine, but generating @vercel/analytics-nextjs instead of @vercel/analytics breaks the install with a 404.
• Compound names: AI suggests react-query-devtools, an old standalone package built for React Query v2, when current TanStack Query uses @tanstack/react-query-devtools.
• Invented utilities: Creating import { formatCurrency } from 'currency-formatter-utils' for a package that sounds plausible but does not exist.

A 2024 study by researchers at the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech, We Have a Package for You!, found that at least 5.2% of the packages suggested by commercial models did not exist, rising to 21.7% for open-source models, and that JavaScript code produced more hallucinated packages than Python (21.3% against 15.8% on average).

The Risk: From Build Failure to Supply Chain Attack

Most developers discover hallucinated imports only when a build fails. This is the good outcome. The serious risk is the gap between when AI generates the code and when someone notices.

If you commit a project to a public GitHub repository with a hallucinated package name in package.json, an attacker who monitors npm for new package registrations or scans public repos for unregistered names can register that name with a postinstall script that exfiltrates environment variables. The next time any contributor runs npm install, the malicious package executes.

This is not hypothetical. In 2021, security researcher Alex Birsan demonstrated the dependency confusion attack against major tech companies including Apple, Microsoft, and PayPal. Their internal package names had been exposed in public code, such as package.json files on GitHub. The research earned him over $130,000 in bug bounties. AI code generators create the same exposure vector every time they invent a package name.

What Hallucinated Code Looks Like

Here is a realistic example. You ask Cursor to add image optimization to a Next.js project:

// ❌ BAD - Hallucinated package name
import { optimizeImage, resizeToWebp } from 'next-image-optimizer-utils';
import { createBlurHash } from 'blurhash-generator-next';

export async function processUploadedImage(file: File) {
  const optimized = await optimizeImage(file, { quality: 80 });
  const blur = await createBlurHash(optimized);
  return { optimized, blur };
}

Neither name was a real package when this example was written. The real packages are sharp for image processing and blurhash or plaiceholder for blur placeholders. The AI invented compound names that sound reasonable but do not map to real packages. blurhash-generator-next still does not exist on npm, but next-image-optimizer-utils was registered on 1 July 2026: its description calls it a security research proof of concept, and it runs a postinstall script. That is exactly the risk described above, so do not install it.

// ✅ GOOD - Verified real packages
import sharp from 'sharp';                  // npm: sharp (real)
import { getPlaiceholder } from 'plaiceholder'; // npm: plaiceholder (real)

export async function processUploadedImage(buffer: Buffer) {
  const optimized = await sharp(buffer)
    .webp({ quality: 80 })
    .toBuffer();

  const { base64 } = await getPlaiceholder(buffer);
  return { optimized, blurDataURL: base64 };
}

The fix is to verify every package name against the npm registry before using it. Run npm info <package-name> in your terminal, or check npmjs.com directly.

How to Detect Hallucinated Imports Before They Reach Production

Manual verification works for small projects, but does not scale. Here is a systematic approach:

1. Run npm install immediately after AI generates code. If a package does not exist, you will see an error like npm error 404 Not Found - GET https://registry.npmjs.org/<package>. Do not commit until this passes.
2. Compare imports to package.json: Every import ... from 'x' where x is not a relative path should have a corresponding entry in dependencies or devDependencies. Orphaned imports are a red flag.
3. Use depcheck or knip: The depcheck CLI finds unused and missing dependencies, flagging imports that have no entry in package.json. It is no longer maintained and recommends knip, which reports the same problem as "unlisted dependencies".
4. Automated scanning: Tools like VibeDoctor's Vibe Check automatically look up every dependency in your package.json on the live npm registry and flag names that do not exist, and flag imports that are known hallucinations or are missing from package.json, with the file and line of each import. Free to sign up.
5. Lock your registry: npm already runs audit on install by default, but that only catches known vulnerabilities. A private registry proxy like Verdaccio or Artifactory can be configured to serve only the package names you allow.

According to Veracode's State of Software Security 2024, 70% of applications contain flaws in third-party code imported through libraries. Hallucinated imports that get registered as malicious packages are a direct path into that statistic.

Comparison: AI Tools and Their Hallucination Risk

FAQ