Research Explainer · XiaoHu Explains

You ask AI to write code, and the package it recommends doesn't actually exist — hackers already planted malware under that exact name

576,000 samples, 16 models tested: 19.7% of AI-recommended packages are hallucinated, and 43% keep generating the same fake name over and over.
TL;DR
  • Slopsquatting is a new supply-chain attack that exploits AI coding assistants hallucinating nonexistent package names, which attackers then register and fill with malicious code — named in April 2025 by Seth Larson, the Python Software Foundation's security developer-in-residence.
  • An academic study tested 16 major code-generation models across 576,000 code samples and found 19.7% of recommended packages were hallucinated — commercial models averaged a 5.2% hallucination rate versus 21.7% for open-source models, roughly a 4x gap.
  • The hallucinations are persistent: asking the same model the same prompt 10 times, 43% of fake package names showed up in every single run, and 58% repeated at least once — a predictable, stable target attackers can stake out in advance.
  • This has already been proven in the real world: a security researcher registered huggingface-cli, a fake package repeatedly hallucinated by multiple models, and it was downloaded over 15,000 times in three months — even ending up in the install instructions of Alibaba's official GraphTranslator project.
  • Among the mitigation methods tested, fine-tuning and combining multiple methods (ensemble) worked best, cutting the hallucination rate by about 85% — but fine-tuning noticeably hurt code-generation quality (pass@1), so there's a real trade-off between safety and capability.
1The Old Problem

Tricking you into installing the wrong package by misspelling its name — registries shut that down long ago

Installing a software package is something developers do dozens of times a day without thinking twice — one line of pip install or npm install pulls someone else's code from a public registry straight into your project. Attackers spotted this habit a long time ago.

The oldest trick is typosquatting: register a fake name that's off from a popular package by just one or two characters — say, registering crossenv when the real, widely-used package is cross-env — and bet that your fingers slip and install the malicious version instead. This trick has been around for decades, and centralized registries like PyPI and npm built protective blocklists for it long ago. A name like crossenv, off from cross-env by a single hyphen, looks like an obvious typo at a glance, so the registry blocks it outright.

The Analogy

It's the same trick as someone registering faceboook.com (with an extra o) to catch traffic from your typos. It looks familiar, but it's an impostor. A registry's blocklist exists specifically to catch names that look like obvious typos.

2New Threat

AI invents convincing package names out of thin air — and the old defenses can't tell the difference

AI coding assistants have changed this threat model. To produce the statistically most plausible answer, they'll confidently invent a package name that doesn't exist at all — and it sounds entirely reasonable. All an attacker has to do is figure out which fake names a given model likes to invent, then register a malicious package under that same name first. That's slopsquatting.

Terminology

Slopsquatting combines AI slop (junk content generated by AI) with typosquatting. It was coined in April 2025 by Seth Larson, the Python Software Foundation's (PSF) security developer-in-residence, and spread after Ecosyste.ms creator Andrew Nesbitt posted it on Mastodon. It falls under the broader category of package confusion attacks — any technique that tricks developers into installing the wrong package — with typosquatting and exploiting AI hallucinations both being specific tactics under that umbrella.

The key difference: names AI invents aren't simple typos, so a registry's existing blocklists can't recognize them at all. The same blocklist produces two very different outcomes for the old trick and the new one:

Old Trick · Typosquatting

crossenv is off from the real package cross-env by a single hyphen, a tiny edit distance — an obvious-looking typo at a glance. The registry's blocklist catches it immediately and blocks it.

New Trick · AI Hallucination Squatting

cross-env-extended, mpn install cross-env file — these sound like legitimate extension packages, but don't correspond exactly to any real package. The blocklist can't recognize them, so they slip through.

Worse still, the brute-force fix of cross-checking generated package names against a list of known packages doesn't work either: attackers may have already registered the hallucinated package in the registry, which means the reference list itself is already contaminated.

3A Real Case

This already happened for real: an empty package got downloaded 15,000 times

This isn't theoretical. In late 2023 and early 2024, Bar Lanyado, a researcher at security firm Lasso Security, ran a real test: he noticed that several large models kept hallucinating the same nonexistent Python package, huggingface-cli, so he actually registered that name on PyPI. The package was empty — no malicious code at all, purely an experiment.

2023.12 – 2024.02
A researcher notices multiple large models repeatedly recommending the same nonexistent package, huggingface-cli
Registration
Registers this shell package on PyPI, with no malicious code at all — purely to test whether anyone would actually install it
Within 3 months
This empty package is downloaded over 15,000 times for real
Slips into a major company
Alibaba's open-source project GraphTranslator writes it into the official README's install instructions

Even an empty package fooled its way to tens of thousands of downloads in three months and landed in a major company's official docs. If the package had actually contained malicious code, the infection would already have spread through the dependency chain. (Source: The Register, 2024-03-28)

4Core Mechanism

Why these fake package names are worth staking out: AI keeps inventing the same name over and over

A single hallucination isn't the scary part — what's scary is that the same model, asked the same question, keeps inventing the exact same fake name. The research team randomly sampled 500 prompts that had previously triggered hallucinations, asked the same model each one 10 times, and recorded how many times the same fake package name reappeared.

Core Mechanism

The result was a clear split into two extremes: 43% of hallucinated package names appeared in all 10 runs, 39% never reappeared at all, and 58% repeated at least once. Most hallucinations are stable, reproducible behavior — ask again at a different time, in a different session, and the same fake name shows up again. For an attacker, a reliably reproducible fake name is a target they can stake out in advance and register in bulk.

Hit all 10 times
43%
Hit sometimes (1–9 times)
18%
Never reappeared in 10 tries
39%
The distribution clusters clearly at the 0-time and 10-time extremes: hallucinations either reproduce reliably or don't reappear at all, with little middle ground. The reliably reproducing half is exactly what attackers can exploit.

What do these fake package names look like

The study also measured how similar these fake names actually are to real package names, using Levenshtein distance (edit distance). It measures the minimum number of character changes needed to turn one name into another — a small distance means the two names look alike and could be a typo, while a large distance means the two words aren't related at all.

Distance 1–2, simple typo
13.4%
Distance 3–5, near-variant
37.9%
Distance ≥6, essentially unrelated
48.6%
Nearly half of hallucinated fake names differ from any real package by 6+ characters — these aren't typos at all, but entirely new names the model invented out of nothing.

On top of that, 81% of unique fake names only appeared on one of the 16 models tested — meaning each model essentially has its own exclusive set of hallucinations. Whichever model an attacker targets, they can harvest developers who use that specific model.

Can a model recognize the fake packages it invented itself?

The study also tested whether models can identify hallucinated packages. Mixing real and fake package names and asking the model "is this a valid Python package," GPT-4 Turbo, GPT-3.5, and DeepSeek all identified their own hallucinations with over 75% accuracy. Models appear to have an implicit self-awareness of their own generation patterns — which is exactly what opens the door for the "have the model double-check itself" mitigation discussed later.

5Differences Between Models

Open-source models hallucinate 4x more than commercial ones — but nobody is fully immune

For the same coding task, which model you pick makes a huge difference in your odds of hitting a landmine. This study generated 576,000 code samples and over 2.2 million package references in total, with an overall hallucination rate of 19.7%. Broken down, commercial and open-source models differ by roughly 4x.

Commercial Models · Average
5.2%
GPT-family and other closed models
Open-Source Models · Average
21.7%
CodeLlama, DeepSeek, and others

Looking at individual models, GPT-4 Turbo had the lowest hallucination rate at just 3.59%; even DeepSeek, the best performer among open-source models, still came in at 13.63%.

GPT-4 Turbo · Best commercial
3.59%
GPT-3.5
5.76%
DeepSeek · Best open-source
13.63%
Overall average
19.7%
Open-source average
21.7%

Two settings amplify the hallucinations further: the higher the temperature (the parameter controlling randomness), the more hallucinations occur — at the highest temperature, open-source models actually invented more fake packages than real ones. Even so, GPT-4 at its highest temperature (8.9%) was still nearly 4x lower than GPT-3.5 (31.8%). Separately, when asked about topics that emerged after a model's training cutoff, the hallucination rate averaged 10% higher than for older topics. For production environments sensitive to package-name accuracy, simply choosing a commercial model cuts a large chunk of this risk on its own.

6Mitigations

There are fixes — but they force a trade-off between safety and code quality

The research team tested several mitigation methods, moving from "filter after generation" toward "prevent before generation" — with each layer working better than the last.

The most basic method is cross-filtering against a real package list after generation, but as noted earlier, attackers can poison that list — it's purely reactive damage control. A step further are two pre-generation interventions: RAG (retrieval-augmented generation) has the model look up a list of real packages before answering and feeds that into the prompt, like handing out an authoritative reference sheet before an open-book exam; self-refinement has the model judge whether each package name is real after generating it, and rewrite if it decides it's wrong, up to 5 retries. Beyond that are fine-tuning and ensemble (stacking several of the above methods together).

The chart below lets you switch between two open-source models to see how far each of the five methods drove the hallucination rate down:

Baseline · No intervention
16.14%
RAG · Open-book
12.24%
Self-refinement
13.04%
Fine-tuning
2.66%
Ensemble
2.40%
DeepSeek's hallucination rate dropped all the way from 16.14% to 2.4%, a roughly 85% reduction — lower than any GPT model.
Baseline · No intervention
26.28%
RAG · Open-book
13.40%
Self-refinement
25.51%
Fine-tuning
10.27%
Ensemble
9.32%
CodeLlama dropped from 26.28% to 9.32%, a roughly 64% reduction. Self-refinement barely helped it at all, since it tends to judge every package as valid and can't recognize its own mistakes.
Trade-off

Fine-tuning cuts hallucinations the most, but at the cost of the code's actual runnable quality. Measured by HumanEval's pass@1 (whether the code the model writes in one shot actually runs and passes tests — higher is more reliable), DeepSeek's pass@1 dropped from 51.4% to 25.3% after fine-tuning, and CodeLlama's from 19.6% to 16.4%. Wanting more safety means accepting a hit to coding ability. RAG and self-refinement don't cut hallucinations as aggressively as fine-tuning, but they barely hurt code quality — a more balanced compromise.

ModelOriginal pass@1After fine-tuning pass@1
DeepSeek51.4%25.3%
CodeLlama19.6%16.4%
Note on data sources: every number in this section comes from real-world testing of code-package hallucinations in the academic paper arXiv:2406.10279 (USENIX Security 2025). The original VentureBeat article also cites a separate figure — "hallucination rates of 50%–82%, with GPT-4o lowest at 23%" — but that comes from an adversarial hallucination study in a medical clinical-decision setting, not the same measure as code-package hallucination. The two shouldn't be conflated.
7The Threat Surface

As AI writes more and more code, this vulnerability gap will only keep widening

The threat surface for this attack path is expanding fast, because more and more code is being written with AI's help.

40%+
Share of their own committed code developers estimate involved AI assistance, and expect that to keep rising
72%
Of developers who've tried AI coding tools, the share using them daily
85%
Increase in the average time a vulnerability stays alive in the open-source ecosystem
49% / 14%
Share of NPM / PyPI vulnerability reports that come from deliberately malicious packages

The open-source ecosystem's overall security picture is also getting worse. A study analyzing 31,267 vulnerability samples across 10 languages found that reported vulnerabilities are growing at 98% per year — far outpacing the 25% annual growth rate of the total package count.

Reported vulnerabilities · YoY growth
98%
Total packages · YoY growth
25%
Vulnerabilities are growing nearly 4x faster than the ecosystem itself is expanding — the attack surface is genuinely widening.

Even more worth watching is the share coming from deliberately malicious sources: among these vulnerability reports, 49% in the NPM ecosystem and 14% in PyPI stem from packages deliberately uploaded to be malicious. A substantial chunk of the pitfalls in these registries were dug on purpose. AI-hallucinated packages just open one more door for this kind of deliberate attack.

8What To Do

Two things any developer can start doing right now

This attack exploits a gap in trust: developers assume whatever package AI recommends is real, and skip verifying before installing. Closing that gap costs almost nothing — just two things.

1
Verify with the official registry before installing
Search every package name AI recommends on the official PyPI or npm site, confirm it actually exists with normal download counts and maintenance history, before adding it to your project. Don't just pip install the moment you get a name.
2
Add automated verification and monitoring for your team
Add a package-name verification step into your CI/CD pipeline that checks against a trusted "known-good" package list, and monitor for anomalous install behavior. Don't rely solely on the assumption that "if AI recommended it, it must be trustworthy" — catch malicious packages before they ever reach production.

Layer on what was mentioned earlier: for scenarios where package-name accuracy really matters, choosing a commercial model — or one that's been through RAG or fine-tuning — cuts this layer of risk down even further.

This attack loop keeps turning because the hallucination is reproducible
Persistent, reproducible hallucination Attackers can stake it out in advance Developer asks AI to write code AI hallucinates a fake name Attacker registers same name Next dev gets recommended Installs, malware enters Infection spreads via deps
The same model keeps generating the same fake name, the attacker registers it ahead of time, and the next developer gets recommended that exact same name — which is what keeps the loop spinning. Being persistent and reproducible is exactly what makes this more dangerous than a random error.
A persistent hallucination is more valuable to an attacker looking to exploit this vulnerability, making this hallucination attack path a more viable threat. Paper "We Have a Package for You!", USENIX Security 2025
This article is compiled based on a VentureBeat guest post (by Zac Amos, 2026-07-11). Core quantitative data comes from the academic paper arXiv:2406.10279, "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" (USENIX Security 2025); open-source vulnerability growth data comes from arXiv:2506.12995; real-world case details come from The Register (2024-03-28) and Lasso Security; terminology sourced from PSF security developer-in-residence Seth Larson. All figures follow their respective original sources.