1. LLM-generated code tries to run code from online software packages. Which is normal but 2. The packages don’t exist.…

What "LLM Generated" Means — and Why It Matters Here

LLM-generated code routinely invents software package names that don't exist — and attackers have started registering those exact phantom names on public repositories like PyPI and npm, stuffing them with malware. A developer asks an AI assistant for help, pastes the generated code into their project, runs an install command, and unknowingly executes an attacker's payload. The threat has a name now — slopsquatting — and peer-reviewed research shows it is far more systematic and scalable than most developers realize.

Before examining the attack, it's worth being precise about what we mean. LLM-generated refers to any text, code, or structured output produced by a large language model — a neural network trained on vast amounts of human-written content that learns to predict statistically plausible continuations of a prompt. When an LLM generates code, it does not execute that code, query a live package registry, or verify that any library it cites actually exists. It produces output that looks correct based on patterns in its training data. That gap — between statistical plausibility and factual accuracy — is the root cause of everything described below.

How a Normal Workflow Becomes a Security Nightmare

The attack chain is deceptively simple, and every step of it looks routine. A developer, under deadline pressure, opens an AI coding assistant — GitHub Copilot, ChatGPT, Claude, or any number of similar tools — and asks it to write a function. The LLM obliges, producing syntactically valid, logically coherent code. Buried inside that code is an import statement or an install command referencing a package that sounds entirely plausible:

# Illustrative examples of the kind of plausible-sounding but
# non-existent package references LLMs commonly generate
# (both names below are drawn from documented real-world incidents
# described later in this article):
pip install huggingface-cli
npm install react-codeshift

The developer copies it, trusts it, and runs it. The package doesn't exist — or rather, it didn't exist until an attacker got there first.

AI researcher Janelle Shane captured the attack chain precisely in an April 2025 Bluesky post:

"1. LLM-generated code tries to run code from online software packages. Which is normal but 2. The packages don't exist. Which would normally cause an error but 3. Nefarious people have made malware under the package names that LLMs make up most often. So 4. Now the LLM code points to malware."

That four-step sequence captures everything. The underlying phenomenon — an LLM confidently recommending a package that was never published — is called a package hallucination. Exploiting that hallucination by registering the phantom name with malicious code attached has been widely referred to as "slopsquatting", a term that gained currency in early 2025 — with Seth Larson, Security Developer-in-Residence at the Python Software Foundation, among the prominent figures helping popularize and define it publicly. The name deliberately echoes typosquatting — the older trick of registering packages with names one character off from popular ones — except here the mistake originates with the AI, not the human.

The Research Behind the Risk: Hallucination at Scale

The scale of this problem is not anecdotal. A landmark study — "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" — from researchers at the University of Texas at San Antonio, Virginia Tech, and the University of Oklahoma generated 576,000 code samples across Python and JavaScript from 16 popular LLMs, then verified every recommended package against the live PyPI and npm registries. The findings were stark:

• 19.7% of all recommended packages were hallucinated — nearly one in five.
• Commercial models (GPT-4, Claude, Gemini, Cohere) hallucinated at an average rate of 5.2%.
• Open-source models (CodeLlama, DeepSeek Coder, LLaMA) hallucinated at an average of 21.7%.
• The study identified 205,474 unique hallucinated package names in total.
• Worst performers included CodeLlama 7B and 34B, each hallucinating in more than 33% of outputs.
• GPT-4 Turbo was among the best commercial models, with a hallucination rate of 3.59%.

A separate study published on arXiv (2501.19012) tested 11 models across JavaScript, Python, and Rust and found that all models were vulnerable, with some alarming outliers: Granite-3.0 hallucinated Python packages at a rate of 46.15%, and Qwen2.5-Coder reached 43.08% for Rust packages. That study also found a statistically significant inverse correlation between model size and hallucination rate — larger models (70 billion parameters or more) performed meaningfully better, with a p-value of 0.00028.

Hallucination Rates by Model and Language

Model	JavaScript (npm)	Python (PyPI)	Rust (crates.io)
GPT-4o	1.76%	3.52%	10.99%
Nemotron-Llama-3.1 (70B)	0.22%	4.84%	0.22%
Llama-3.1-70B	24.40%	25.93%	18.02%
StarCoder2	14.51%	27.03%	31.65%
CodeGemma	23.74%	33.85%	42.20%
Qwen2.5-Coder	15.16%	38.02%	43.08%
Granite-3.0	24.62%	46.15%	42.86%

The language dimension matters too. Rust had the highest mean hallucination rate at 24.74%, most likely because crates.io held approximately 169,000 packages at the time of the study — far fewer than npm's roughly 3.4 million. A smaller registry means more plausible-sounding names simply don't exist yet, giving attackers proportionally more unclaimed real estate to squat on.

Why Hallucinated Packages Are a Gift to Attackers

The insight that turns this from an annoying bug into a viable attack vector is reproducibility. Per the UT San Antonio / Virginia Tech / University of Oklahoma study, researchers ran 500 hallucination-generating prompts ten times each and found:

• 43% of hallucinated package names appeared in all ten re-runs of the same prompt.
• 58% appeared more than once across ten tries.
• Only 39% were one-off, non-repeating hallucinations.

As the research team stated directly in their paper: "A persistent hallucination is more valuable for malicious actors looking to exploit this vulnerability and makes the hallucination attack vector a more viable threat." An attacker needs no access to logs or user data. They can run the same prompts developers commonly use, watch which non-existent packages the model recommends consistently, cross-reference those names against live registries, and register any unclaimed ones with malicious payloads attached. The barrier to entry is essentially zero.

Security researchers studying this attack class have noted that the attacker's workflow is straightforward: observe which non-existent package names a given model reliably produces for common development tasks, check whether those names are unclaimed on the relevant registry, and register them with malicious code attached. No insider knowledge, no sophisticated tooling — just prompt engineering and a registry account.

What the Malware Actually Does

Once a malicious package is installed, damage happens fast. Attackers commonly use two delivery mechanisms:

• Post-install scripts — Both npm and PyPI allow packages to execute scripts automatically on installation. A postinstall script in package.json, or a setup.py with a custom install command, can exfiltrate API keys, cloud provider tokens, SSH credentials, and npm authentication tokens to an attacker-controlled server before the developer has written a single line of their own application code.
• URL-based remote payloads — npm's native support for URL-based dependencies allows a package to contain no obviously malicious static code. Instead, it fetches its true payload from an external server only at install time, evading naive static scanners entirely since the malicious bytes never appear in the published package itself.

Real-World Cases Already Documented

This is not hypothetical. Concrete, documented incidents are already on record, spanning both proof-of-concept demonstrations and confirmed malicious deployments.

The huggingface-cli Proof of Concept

In 2024, security researcher Bar Lanyado of Lasso Security observed multiple LLMs consistently recommending huggingface-cli as a PyPI package. The correct installation route for the Hugging Face CLI is:

pip install -U "huggingface_hub[cli]"

But models reliably suggested the shorter, non-existent variant huggingface-cli. To measure the real-world impact, Lanyado uploaded an empty, benign package under that name as a proof of concept. According to Lasso Security's reporting, it accumulated over 30,000 authentic downloads in the months that followed — with no promotion whatsoever. Alibaba had even copy-pasted the hallucinated install command directly into the README of a public repository, meaning AI-generated misinformation was now propagating through human-curated documentation.

The react-codeshift Autonomous Agent Case

In early 2025, Aikido security researcher Charlie Eriksen documented the case of react-codeshift on npm — a classic conflation hallucination, blending the real packages jscodeshift and react-codemod into a single plausible-sounding but non-existent name. Nobody planted it deliberately. It first appeared in a single commit containing 47 LLM-generated agent skills, where an AI hallucinated the package names its skills would need, with no human review step anywhere in the pipeline.

That one hallucinated name then spread to 237 repositories through forks and was translated into Japanese-language documentation — all without any human author knowingly endorsing the package. After Eriksen claimed the package name on npm to stop a malicious actor from doing so first, the package kept receiving daily install requests — not from humans reading documentation, but from AI agents autonomously executing the skill instructions and triggering npx installs without any human in the loop.

The unused-imports Confirmed Malicious Case

The npm package unused-imports — a hallucinated conflation of the legitimate eslint-plugin-unused-imports — was identified as actively malicious and placed under a security hold by the npm registry. According to Aikido's published analysis, even after the security hold was applied, the package was still drawing approximately 233 downloads per week — a figure that reflects how deeply hallucinated package names can embed themselves in codebases, CI pipelines, and documentation that outlive any individual developer's awareness of the threat.

LLM Generated Code Security: Why Existing Defenses Fall Short

The conventional response to supply chain attacks — verify that the package exists before installing it — is no longer sufficient on its own. Simply querying a registry is unreliable once attackers have pre-registered hallucinated names. Download count is equally untrustworthy: a newly registered malicious package starts with low numbers, but AI agents consistently following the same hallucinated instructions will organically inflate that figure, giving the package a superficial appearance of legitimacy.

The react-codeshift case exposes a deeper structural problem. As AI agents — tools like Claude Code running in autonomous mode, agentic CI/CD pipelines, and self-directing coding bots — become more prevalent, the human review step disappears entirely from the install pipeline. An AI agent that can both generate code and execute install commands becomes a fully automated delivery mechanism for slopsquatting payloads. The attacker doesn't need to target individual developers; they just need to register the right package name and wait for agents to trigger downloads at scale.

LLM Generated Code Detection: Models Can Catch Their Own Errors — If Asked

Research on LLM generated code detection of hallucinated packages reveals an important asymmetry. Studies found that many LLMs can identify their own hallucinations when explicitly prompted to audit their output — GPT-4 Turbo and DeepSeek demonstrated self-detection accuracy above 75% in controlled tests. The problem is that the dominant "vibe coding" workflow — where a developer describes intent and accepts generated code wholesale — never includes that audit prompt. The model has the capability to flag the risk; the workflow just never asks it to.

What Developers Can Do Right Now

Mitigation is achievable, but it requires changing habits that AI-assisted development has actively encouraged. The following steps are ordered by immediacy of impact:

1. Verify every AI-suggested package before installing it. Search the registry directly at pypi.org or npmjs.com. Check the publisher's identity, the registration date, the number of releases, and the maintainer's account history. A package registered yesterday by a brand-new account with no prior history is a red flag regardless of its download count.
2. Never allow an AI agent to install packages without a human confirmation step. Treat autonomous package installation as a privileged, audited operation — equivalent to deploying to production. Any agentic workflow with the ability to run pip install or npm install without explicit human approval should be considered a high-risk configuration requiring architectural review.
3. Run Software Composition Analysis (SCA) against your full dependency tree, not just your direct package.json or requirements.txt. Hallucinated packages can propagate as transitive dependencies, invisible to a developer reviewing only first-level dependencies.
4. Adopt registry-aware security tooling. Tools like Socket scan dependency trees and flag suspicious behaviors — install scripts, obfuscated code, and remote payload fetching — before any code executes. Aikido's open-source SafeChain wrapper (available on GitHub) intercepts npm, npx, yarn, and pnpm install commands and checks them against a live threat-intelligence feed before proceeding.
5. Choose your LLM deliberately for coding tasks. The data shows meaningful, measurable variation: GPT-4o and Nemotron-Llama-3.1 (70B) show hallucination rates under 5% for Python and JavaScript, while several smaller open-source models exceed 40% for specific language ecosystems. For any codebase headed to production, LLM selection is now a security decision, not merely a developer-preference one.
6. Prompt the model to audit its own package references. After generating code, follow up with something like: "List every package you referenced in that code and confirm that each one exists on its respective registry." Given that self-detection accuracy exceeds 75% in tested models, this single additional step can eliminate a significant fraction of hallucination risk at zero tooling cost.

Key Takeaways

The following points summarize the current state of the slopsquatting threat for practitioners evaluating their exposure:

• LLM-generated code hallucinates package names at scale — averaging nearly 20% across major models studied, and exceeding 40% in the worst cases for specific ecosystems such as Rust and Python.
• The attack technique is called slopsquatting, a term that gained traction in early 2025 — the name deliberately echoes typosquatting but refers specifically to attackers registering the phantom package names that LLMs most consistently and reproducibly invent.
• 43% of hallucinated package names repeat across all ten re-runs of the same prompt (per the UT San Antonio / Virginia Tech / University of Oklahoma study), making them predictable, targetable, and trivially exploitable by any adversary willing to run the same prompts developers run.
• Real-world cases are documented: the benign huggingface-cli proof-of-concept drew 30,000+ downloads; unused-imports was confirmed malicious, placed under a registry security hold, and still pulled approximately 233 downloads per week.
• Malicious packages most commonly use post-install scripts or remote URL payloads to steal credentials — mechanisms specifically designed to evade static analysis tools.
• AI agents running without human review are the highest-risk scenario, capable of autonomously propagating hallucinated package installs across repositories and CI pipelines at machine speed.
• Defenses must move beyond "does this package exist?" to encompass publisher verification, full-tree SCA tooling, and hard architectural constraints on autonomous install operations.
• LLM generated code detection of hallucinations is technically feasible — models like GPT-4 Turbo can self-identify hallucinated packages with over 75% accuracy when explicitly prompted — but the dominant vibe-coding workflow rarely includes that audit step.

---

The trajectory here points toward escalation before it improves. As agentic AI coding tools become the default interface for software development, the attack surface for slopsquatting grows proportionally — more autonomous agents executing more install commands with less human oversight at every step. Package registries including PyPI and npm are aware of the problem, but proactive, systematic defense at the registry level remains immature. The most probable near-term mitigations are tighter integration between AI coding assistants and registry-verification APIs (so hallucinated names trigger a warning before a command is suggested), targeted LLM fine-tuning to reduce package hallucination rates for specific ecosystems, and regulatory or industry-standard pressure on AI code-generation vendors to surface explicit hallucination warnings before any install command appears in generated output. Until those systemic fixes arrive, the responsibility sits with developers and security teams: every AI-generated dependency reference is, for now, a claim that must be verified rather than a fact that can be trusted.