Tag: supply-chain

Ask an AI coding assistant for a Python snippet, and there’s a real, measured chance it will tell you to pip install a package that doesn’t exist. That’s not a hypothetical: the peer-reviewed USENIX Security 2025 study that first measured this at scale found that 19.7% of over 2.2 million AI-generated code samples recommended at least one non-existent package, and attackers have already started registering those exact hallucinated names with malicious payloads inside them, waiting for someone to copy-paste the AI’s suggestion. Security researchers call this “slopsquatting” — a term coined by Seth Larson, developer-in-residence at the Python Software Foundation — and in 2026 it’s one of the more concrete, quantifiable risks specific to AI coding assistants, distinct from the general “review AI code carefully” advice that applies to everything else an LLM writes.

At a Glance

Fact	Detail
What it is	An attacker registers a package name that LLMs are observed to hallucinate (invent) when generating code, so that developers who copy-paste AI-suggested install commands pull real, attacker-controlled malware
Term coined by	Seth Larson, developer-in-residence at the Python Software Foundation, by analogy with “typosquatting”
Original measured rate (2024/2025)	19.7% of 2.23 million AI-generated code samples across 16 models contained at least one hallucinated package (Spracklen et al., USENIX Security 2025)
2026 frontier-model rate	3.6%–5.0% of package mentions and 2.2%–3.4% of generations hallucinated across five 2026 frontier models, per an independent replication study
Real-world exploitation observed	At least 23 AI-hallucinated package names were found to have previously hosted actual malware before registries removed them; researchers observed roughly 1% of hallucinated names get registered by someone within six months of exposure
Primary defenses	Package-existence verification before install, committed and hash-verified lockfiles, SCA/allowlist tooling, human review of AI-suggested dependencies

What Slopsquatting Actually Is

Slopsquatting is a supply-chain attack that depends entirely on a quirk of how LLMs generate code: when asked to solve a problem, a model will sometimes invent a plausible-sounding package name that doesn’t exist — the kind of name a real package in that ecosystem might have — because the model is predicting statistically likely tokens, not looking anything up. If a developer (or an autonomous coding agent) trusts that suggestion and runs pip install or npm install on it, nothing happens — unless an attacker has already registered that exact name on PyPI or npm with malicious code inside it. At that point, the “nothing exists here” gap an LLM hallucinated into existence becomes a real, exploitable foothold. This is distinct from typosquatting (registering a misspelled variant of a real package name) because the attacker isn’t guessing at human typos — they’re exploiting a documented, measurable pattern in how specific LLMs fail, often by generating large volumes of code with those models first to find out exactly which fake names they tend to invent.

What the Research Actually Found

The foundational study here is Spracklen et al.’s “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs,” presented at USENIX Security 2025. The researchers generated 2.23 million code samples in Python and JavaScript across 16 different models and found that 440,445 of them (19.7%) recommended at least one hallucinated package, comprising 205,474 unique fabricated names. The breakdown matters for anyone picking a model: commercial models averaged a 5.2% hallucination rate versus 21.7% for open-source models — open-source models hallucinated roughly four times as often — and the best-performing individual model, GPT-4 Turbo, hallucinated in 3.59% of samples, while the best open-source model tested, DeepSeek at 1.3B parameters, still hallucinated 13.63% of the time. Python (15.8%) hallucinated less than JavaScript (21.3%) on average, though a model’s tendency to hallucinate correlated across both languages.

Two findings from that study are specifically what makes slopsquatting practical as an attack rather than just an annoyance. First, persistence: when the researchers reran the same prompt 10 times against the same model, 43% of hallucinated package names reappeared in all 10 runs, and 58% reappeared more than once — meaning a meaningful share of hallucinations aren’t one-off flukes, they’re reliable, repeatable outputs an attacker can specifically target by querying the same models themselves. Second, specificity: 81% of distinct hallucinated names were produced by only one model, meaning each model has its own, largely distinct set of fabricated names — which is exactly the kind of fingerprint that lets an attacker generate a target list by simply querying popular coding models at scale and registering whatever they consistently invent.

A 2026 independent replication, run against five current frontier models across 199,840 Python and JavaScript generations, found the rate has narrowed but not disappeared: 3.6%–5.0% of package mentions and 2.2%–3.4% of full generations were hallucinated, which the paper’s authors describe as “the 2026 frontier sits at the level of 2024’s commercial models” — in other words, today’s best models have converged toward where 2024’s best commercial models already were, rather than solving the problem outright, and the gap between open-weight and closed models that the original study found has also largely disappeared. The same 2026 study used an accidental six-month public exposure of its own hallucinated-name list as a natural experiment and found that about 1% of hallucinated names were registered by someone within that window — at the same rate whether or not the list had been published, suggesting opportunistic registration happens regardless of visibility. Most concerning: the researchers found at least 23 of the hallucinated names they tested had previously hosted actual malware that package registries had already removed, and one hallucinated name was registered with malware during the study’s own run window.

How This Differs From General “AI Code Security” Advice

Broader frameworks like OWASP’s AI Security Verification Standard treat AI-generated dependencies as one item among many requiring human review and automated scanning — useful, but not specific to this failure mode. Slopsquatting is narrower and more mechanical: it doesn’t require the AI-generated code itself to have a logic bug, a missing authorization check, or any of the subtler mistakes general AI-code-security guidance focuses on. The entire attack succeeds or fails on one yes/no question — does this exact package name exist, and if so, is it the real one — which is why the mitigations below are comparatively simple and mechanical compared to, say, reviewing AI-generated authentication logic.

Real-World Mitigations

Verify package existence and provenance before install. Before running an install command an AI assistant suggested, confirm the package actually exists in the target registry, was registered well before your project started, and has a publisher with an established track record — a newly registered package with no history is a meaningful red flag regardless of how plausible its name sounds. Commercial tools like Socket, Snyk, and Aikido automate this check and can be wired directly into CI.

Commit lockfiles and verify them on every install. A lockfile pins exact versions and content hashes for every dependency, including transitive ones, so a build can’t silently pull in a different package than the one a human actually reviewed and approved. The critical step most teams skip is verifying the lockfile’s hashes during automated installs — not just having a lockfile, but enforcing it:

# Python: install only exact, hash-verified versions from requirements.txt
# requirements.txt must list a --hash=sha256:... entry for every package
pip install --require-hashes -r requirements.txt

# Node.js: install exactly what's in package-lock.json; fails if it's out of sync
npm ci

# A requirements.txt line with a pinned hash looks like this:
# requests==2.32.3 \
#     --hash=sha256:70761cfe03c773ceb22aa2f671b4757976145175cdfca038c02654d061d6dc6

pip install --require-hashes refuses to install anything that isn’t in the lockfile with a matching hash, and npm ci (as opposed to npm install) refuses to modify package-lock.json at all — both turn “the AI suggested a new package” into a build failure that demands a human decision, rather than a silent, successful install.

Regenerate dependency trees from an approved lockfile, not from scratch. If an AI coding agent or assistant proposes adding a new dependency, that addition should go through the same review and approval step as any other dependency change — updating the lockfile deliberately — rather than letting an agent run an uncontrolled install command directly against a live environment.

Restrict what autonomous coding agents can install. For agents with any package-management ability, allowlist specific, pre-approved packages and route anything else to human review; if that isn’t practical for your workflow, disable automated package installation in agentic environments entirely until you can add that gate.

Flag newly registered packages in CI. Configure software composition analysis (SCA) tooling to flag any dependency registered in the 30–90 days before it was first introduced into your codebase — this window catches both slopsquatting and more conventional typosquatting without needing to know in advance which specific name is fake.

Trade-Offs

• Pros: the core mitigations (hash-verified lockfiles, package-existence checks, CI allowlisting) are mechanical, automatable, and don’t require judging AI-generated logic — they’re genuinely effective against this specific, narrow attack vector and most teams can adopt them without a major process overhaul.
• Cons: strict hash verification and lockfile enforcement can slow down legitimate dependency updates and requires deliberate process for adding anything new; newly-registered-package flagging produces false positives for genuinely new, legitimate libraries; and no mitigation here helps if a developer runs an AI-suggested install command manually, outside of CI, on a personal or unmanaged machine.

Who This Matters Most For

Teams using AI coding assistants or autonomous coding agents with any ability to run install commands — whether that’s a human copy-pasting Copilot/Claude/Cursor suggestions or an agent executing pip install autonomously as part of a task — are the direct audience here, especially teams working in ecosystems (Python and JavaScript specifically are the best-studied) and especially teams using open-source or self-hosted models, which the original research found hallucinate roughly four times as often as leading commercial models.

Who Should Look Elsewhere

Teams looking for broader guidance on reviewing AI-generated code in general — authorization logic, injection vulnerabilities, secrets handling — should look at OWASP’s AI-assisted secure coding guidance or a SAST tool comparison instead; this piece deliberately stays narrow on the package-hallucination problem specifically. Teams whose build pipelines already enforce hash-verified lockfiles and have no path for agents to run arbitrary installs have likely already closed most of this attack surface and may get more value focusing elsewhere.

Bottom Line

Slopsquatting is one of the more precisely measured risks in the AI-coding-assistant landscape: researchers can and have quantified exactly how often specific models invent package names, how persistently they repeat the same fabrications, and how often attackers have already weaponized the gap. The rate has improved — 2026’s best frontier models hallucinate at roughly a quarter the rate of 2024’s open-source models — but it hasn’t gone away, and the fix isn’t waiting for models to improve further. It’s treating every AI-suggested dependency as unverified until a lockfile, a hash check, or a human confirms it’s real.

FAQ

Who coined the term “slopsquatting”? Seth Larson, developer-in-residence at the Python Software Foundation, coined it by analogy with “typosquatting,” to describe attackers registering package names that AI models are observed to hallucinate.

How common is package hallucination today? The original 2024/2025 USENIX study found a 19.7% overall rate across 16 models. An independent 2026 replication against five current frontier models found 3.6%–5.0% of package mentions hallucinated — lower, but still a real, non-trivial rate, and roughly equivalent to where 2024’s best commercial models already stood.

Has slopsquatting actually been exploited, or is it theoretical? It’s been observed in practice. Researchers found at least 23 AI-hallucinated package names that had previously hosted real malware before being removed from registries, and one hallucinated name was registered with malware during a 2026 study’s own observation window.

Does using a lockfile fully solve this problem? It substantially reduces the risk for anything going through an enforced CI pipeline (via hash verification and commands like npm ci or pip install --require-hashes), but it doesn’t protect a developer who manually runs an AI-suggested install command outside that pipeline, on a personal machine or in an ad hoc script.

Are open-source models worse than commercial ones for this specific risk? Yes, according to the original research: open-source models averaged a 21.7% hallucination rate versus 5.2% for commercial models — roughly four times higher — though the gap has narrowed in more recent model generations per the 2026 replication study.

Sources

• Spracklen et al. — “We Have a Package for You!” A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort
• Cloud Security Alliance — Research Note: Slopsquatting, AI Hallucinations Fuel Supply Chain Attacks
• Infosecurity Magazine — AI Hallucinations Create “Slopsquatting” Supply Chain Threat

Related reading on this site: What OWASP’s Guidance Says About Securing AI-Generated Code in 2026 and Secure CI/CD Pipelines: A Practical Checklist for Supply-Chain Security in 2026.