Before You npm install What Copilot Suggested, Read This

AI coding assistants generate dependencies as confidently as they generate code — but 27.8% of AI-suggested package versions don't exist (Sonatype, 2026 State of the Software Supply Chain), and AI-generated code contains 2.74× more vulnerabilities than human-written code (Veracode, 2025 State of Software Security). Newer research shows the problem varies by model family: open-source models hallucinate up to 22% of dependency names, while commercial models like GPT-4 and Claude hover around 5% (Lasso Security, 2025). Attackers have a name for weaponizing this now — slopsquatting — and a growing body of research shows it's exploitable at scale. Before you npm install what Copilot suggested, scan it.

Here's how to audit AI-generated dependencies systematically.

What We'll Cover

• What is slopsquatting?
• Slopsquatting vs typosquatting
• The three risks of AI-suggested dependencies
• Phantom dependencies: hallucinated packages
• Outdated or vulnerable versions
• Unnecessary dependencies
• The 4-step AI dependency audit checklist
• Automating the audit in CI
• Real-world scenarios

What Is Slopsquatting?

Slopsquatting is a supply chain attack where an attacker registers a package name that an AI coding assistant hallucinates, betting that a developer will copy-paste the AI's suggested install command without checking whether the package is real. The term — a portmanteau of "AI slop" and "typosquatting" — was coined by Python Software Foundation Developer in Residence Seth Larson in 2025 and has since been adopted across the security industry (Snyk, Trend Micro, Aikido, and others) as the standard name for this attack class.

The mechanics differ from ordinary phantom dependencies in one important way: slopsquatting describes the attacker's side of the exploit, not just the AI's mistake. Academic research analyzing over 576,000 LLM-generated code samples found an average hallucination rate of 19.7% across open-source and commercial models combined, surfacing more than 205,000 unique hallucinated package names — and 43% of those hallucinations reappeared consistently across ten repeated runs of the same prompt, meaning attackers can predict which fake names to squat on rather than guessing. A researcher who uploaded an empty proof-of-concept package under one hallucinated name recorded over 30,000 downloads within three months, with no promotion beyond the package existing where an AI assistant was already recommending it.

Slopsquatting vs Typosquatting

Both attacks rely on a developer installing the wrong package, but the trust mechanism they exploit is different. Typosquatting targets human error — an attacker registers expres hoping someone fat-fingers express. The developer makes the mistake; the attacker just waits for it.

Slopsquatting targets AI trust instead. The developer doesn't mistype anything — they copy the exact package name an AI assistant confidently recommended. The "typo," if you can call it that, originates in the model's training data or generation process, not in the developer's keystrokes. That makes slopsquatting harder to catch with the usual typo-detection heuristics (edit-distance checks against popular package names), because a hallucinated name like python-socks isn't necessarily one character off from a real package — it just sounds plausible enough that a model generated it with confidence and a developer had no reason to doubt it. The audit checklist below (Step 1 in particular) is the defense for both, but slopsquatting is the reason "verify the package exists" now belongs in every AI-assisted workflow, not just import statements you're unsure about.

The Three Risks of AI-Suggested Dependencies

When an AI coding assistant suggests a dependency, it draws from training data — not from the live registry. It doesn't verify that the package exists, that the version is current, or that the version is free of known vulnerabilities. This creates three distinct risk categories.

3 Risks of AI-Suggested Dependencies

👻Phantom Dependencies

27.8%

of AI-suggested versions don't exist

AI suggests packages that aren't in any registry. Attackers register these hallucinated names and publish malware.

Example: AI suggests python-socks → real package is PySocks

📦Outdated Versions

2.74×

more vulnerabilities in AI-generated code

AI training data has a cutoff. It suggests versions that were common in training, not versions with the latest security patches.

Example: AI suggests lodash@4.17.11 → 4.17.21 fixed critical CVE

🧱Unnecessary Packages

50+

transitive deps from a single package

AI adds packages for things the standard library already handles. Each dep expands your attack surface and trust boundary.

Example: AI suggests moment for dates → Intl.DateTimeFormat is built in

Sources: Sonatype 2026 State of Software Supply Chain · Veracode 2025 State of Software Security

1. Phantom Dependencies (Hallucinated Packages)

AI models sometimes suggest packages that don't exist in any registry. Sonatype's 2026 research found this happens at an alarming rate: 27.8% of AI-suggested package versions point to packages or versions that cannot be found on npm, PyPI, or other registries.

This isn't just a broken build problem. It's a supply chain attack vector.

When a researcher or attacker discovers that an AI model consistently hallucinates a specific package name — say, python-socks instead of the real PySocks — they can register that name on PyPI and publish malicious code. Every developer who trusts the AI's suggestion and runs pip install python-socks installs the attacker's package instead.

This attack pattern is called package hallucination hijacking. The AI confidently provides an import statement. The package name looks plausible. The developer has no reason to question it. For a deeper look at how attackers exploit namespace confusion — including cases where AI tools suggest internal package names that conflict with public registry packages — see Dependency Confusion Attacks Explained.

2. Outdated or Vulnerable Versions

AI models have a training data cutoff. They suggest package versions that were current when the training data was collected, not versions that are current today.

This means an AI might suggest lodash@4.17.11 — a version with a critical prototype pollution vulnerability (CVE-2019-10744, CVSS 9.1) — when 4.17.21 has been available since July 2020 with the fix. The AI doesn't check the npm advisory database. It doesn't know about CVEs published after its training cutoff. It suggests what it's seen most often in the code it was trained on.

For popular packages like express, django, or spring-boot, the AI-suggested version can be years behind the latest security patch.

3. Unnecessary Dependencies

AI assistants are trained on code that uses packages liberally. When you ask "how do I format a date in JavaScript?", the AI is more likely to suggest moment or date-fns than Intl.DateTimeFormat — even though the standard library has handled date formatting since ES2017.

Every unnecessary dependency is a trust decision you didn't need to make. Each one:

• Adds its own transitive dependency tree (often dozens of packages)
• Increases the surface area for supply chain attacks
• Creates maintenance burden when vulnerabilities are disclosed
• Slows builds and increases bundle sizes

The security principle is simple: the safest dependency is the one you don't install.

The 4-Step AI Dependency Audit Checklist

AI Dependency Audit Checklist

1. 1Verify Package Exists

   Action: npm view / pip index versions

   Catches: Phantom dependencies, typosquatting

2. 2Check Version Currency

   Action: Compare suggested vs latest release

   Catches: Outdated versions with known CVEs

3. 3Scan with EPSS + KEV

   Action: Exploitation signals, not just CVE counts

   Catches: Actively exploited vulnerabilities

4. 4Evaluate Necessity

   Action: Standard library? Maintained? Dep tree size?

   Catches: Unnecessary attack surface expansion

Steps 1–2 take seconds. Step 3 requires exploitation data (EPSS + CISA KEV). Step 4 is a judgment call — when in doubt, fewer dependencies wins.

Step 1: Verify the Package Exists

Before running npm install, pip install, or any package manager command, check that the package actually exists on the registry.

# npm: check if package exists
npm view <package-name> version

# PyPI: check if package exists
pip index versions <package-name>

# Go: check if module exists
go list -m <module-path>@latest

Watch for these red flags:

• Typosquatting variants: python-datutil instead of python-dateutil, reqeusts instead of requests
• Plausible but nonexistent names: The AI generates a name that sounds like it should exist but doesn't
• Wrong ecosystem: The AI suggests an npm package name when you're working in Python, or vice versa

If the package doesn't exist, stop. The AI hallucinated it. Find the real package that provides the functionality you need.

Step 2: Check the Version

If the package exists, verify the version the AI suggested is current and free of known vulnerabilities.

# Compare AI-suggested version vs latest
npm view <package-name> versions --json

# Check for known advisories
npm audit --json

Key checks:

• Is the suggested version the latest? If not, how far behind is it?
• Are there known CVEs between the suggested version and the latest?
• Does the suggested version have any security advisories?

Step 3: Scan with Exploitation Signals

Finding a CVE in a dependency tells you the vulnerability exists. It doesn't tell you whether anyone is actually exploiting it. This is where EPSS and CISA KEV change the game.

Run AI-suggested dependencies through a scanner that provides exploitation context:

• EPSS score: What's the probability this CVE will be exploited in the next 30 days? An EPSS score above 0.1 (10%) means the vulnerability is in the top 15% for exploitation likelihood. Learn more about EPSS →
• CISA KEV status: Is this CVE in the Known Exploited Vulnerabilities catalog? If yes, it has confirmed active exploitation — patch immediately.
• CVSS severity: How severe is the impact if exploited?

The 3-Signal Triage Method applies here: CVSS alone would flag everything. EPSS and KEV tell you what's actually being weaponized right now.

Scan your AI-suggested dependencies for free →

Step 4: Evaluate Necessity

Before accepting any AI-suggested dependency, ask three questions:

1. Can the standard library do this? Node.js has crypto, fs, path, url. Python has datetime, json, urllib, re. Go's standard library covers most use cases. Check before you add a package.

2. Is the package actively maintained? Check the repository for recent commits, open issue response times, and release cadence. A package with no commits in 18 months is a liability, not an asset.

3. What's the transitive dependency tree size? Run npm ls <package> or pipdeptree -p <package> to see what you're actually installing. A single AI-suggested package can pull in 50+ transitive dependencies — each one a potential vulnerability vector.

If the answer to question 1 is "yes," remove the dependency. Your code is more secure with fewer dependencies, not more.

Automating the Audit in CI

Manual auditing works for individual packages, but AI-generated code enters your codebase through pull requests at scale. You need automation.

Step 1: Scan lock files on every PR. When AI-generated code adds new dependencies, the lock file changes. Scan it automatically.

Step 2: Block merges on exploited vulnerabilities. If a dependency has a CISA KEV entry or an EPSS score above your threshold, the PR should not merge until the dependency is updated or removed.

Step 3: Flag phantom packages. Packages that fail registry lookup aren't just build failures — they might be hallucinated names waiting to be hijacked.

With GeekWala's GitHub integration, you can auto-scan every PR that modifies dependency files. Import your repository and get vulnerability reports with EPSS + KEV enrichment on every push.

Import your GitHub repo and auto-scan every PR →

Real-World Scenarios

These scenarios illustrate why auditing AI-suggested dependencies matters. Each involves a real supply chain incident that an AI coding assistant could plausibly reproduce.

Scenario A: The Backdoored Stream Library

An AI suggests event-stream@3.3.6 for stream processing in a Node.js application. The suggestion is technically correct — event-stream is a legitimate, widely-used package.

But version 3.3.6 was compromised. In 2018, a new maintainer gained access to the package, added a dependency on flatmap-stream, and injected code that targeted cryptocurrency wallets. The malicious version was downloaded 8 million times before discovery.

An audit catches this: the package exists (Step 1 passes), but version 3.3.6 has a known advisory (Step 2 fails). Scanning with exploitation signals (Step 3) reveals active exploitation history.

Scenario B: The Protestware Package

ChatGPT suggests colors@1.4.0 for terminal color formatting. Again, colors is a real package used by thousands of projects.

In January 2022, the author of colors deliberately corrupted versions 1.4.1 and above, adding an infinite loop that printed gibberish to the console. It was a protest against open-source sustainability issues. While version 1.4.0 itself wasn't corrupted, nearby versions were — and the AI has no awareness of this context.

Step 2 catches this: comparing the suggested version against the latest reveals the package's troubled history. Step 4 also applies: chalk is a maintained alternative, and Node.js 20+ has built-in styleText for basic color formatting.

Scenario C: The Typosquatting Near-Miss

An AI suggests installing python-datutil for date parsing. The real package is python-dateutil — note the missing e.

This is a textbook typosquatting vector. If python-datutil doesn't exist on PyPI, an attacker could register it. If it does exist, it might already be malicious. Either way, the AI's confident pip install python-datutil instruction is one character away from a supply chain compromise.

Step 1 catches this immediately: pip index versions python-datutil either returns nothing (hallucinated) or returns a package that isn't what you expected.

The Supply Chain Angle

AI-generated dependencies don't just introduce vulnerability risk — they amplify supply chain attack surfaces. When an AI suggests a package, it may be pulling from training data that included compromised versions, typosquatted names, or packages that were later hijacked. This intersects directly with the broader supply chain attack trends targeting open source in 2026, where attackers are increasingly targeting the gap between what developers intend to install and what actually gets resolved.

The combination of AI hallucination and dependency confusion is particularly dangerous: an AI might suggest a package name that matches an internal company package, causing the public registry version to be installed instead. Read Dependency Confusion Attacks Explained for the full attack mechanics and defenses.

Does This Mean I Shouldn't Use AI Coding Assistants?

No. AI coding assistants are powerful tools that accelerate development. The issue isn't AI-generated code itself — it's trusting AI-generated code without the same scrutiny you'd apply to a human pull request.

You wouldn't merge a colleague's PR without reviewing the dependency changes. Apply the same standard to AI suggestions. The 4-step checklist above takes minutes per dependency and prevents the categories of supply chain risk that AI tools uniquely introduce.

Is Vibe Coding Safe?

Vibe coding — prompting an AI to write code and accepting its suggestions with minimal manual review — is safe only if you still audit what gets installed. The risk isn't the workflow itself, it's skipping the dependency review a human-authored pull request would normally get; run every AI-suggested package through the 4-step audit checklist above before it reaches production.

Vibe coding compounds slopsquatting risk in a specific way: the entire point of the workflow is to minimize manual intervention, so the checkpoint where a developer would normally pause and ask "does this package actually exist, and do I need it?" gets skipped by design, not by accident. Treat the audit checklist as a required step in the vibe coding loop, not an optional extra you run only when something looks wrong.

Which AI Tools Have the Worst Hallucination Rates?

Hallucination rates vary by model, training data recency, and the ecosystem being targeted. Sonatype's research found that the 27.8% hallucination rate applies across major AI tools, with some variation by programming language. Python and JavaScript ecosystems see the highest rates because they have the largest package registries and the most namespace collisions.

Rather than ranking tools, the practical takeaway is: always verify, regardless of which AI you use. Models improve with each release, but no model has access to live registry data during code generation.

Can GeekWala Detect Phantom Packages?

GeekWala validates every package against real registry data. When you submit a dependency list, packages that can't be resolved against the registry are flagged — they either don't exist or the version doesn't exist. Combined with EPSS exploitation probability and CISA KEV active exploitation status, you get a complete picture: does this package exist, is it vulnerable, and is anyone actually exploiting those vulnerabilities?

Scan your AI-generated dependencies now — free, no account required →