What is slopsquatting, and how do you protect against it?

Slopsquatting is registering package names that AI models hallucinate, so that developers who install an AI-recommended dependency without checking receive the attacker's code. The protection is closing the install path: lockfiles and internal mirrors so unknown names do not resolve, a review gate for every new dependency, and treating any dependency an AI run adds as a scope event that needs explicit approval. The term was coined by PSF security developer Seth Larson.

How common are hallucinated packages, measured?

The USENIX Security 2025 study 'We Have a Package for You!' measured it across 16 code-generating models: 19.7% of recommended packages did not exist, producing over 205,000 unique invented names. Commercial models hallucinated less than open-source ones, but no model was clean. The scale matters: this is not an occasional glitch but a systematic output property, large enough to farm.

Why does the 43% persistence number matter so much?

Because it converts a curiosity into an attack surface. When the researchers re-ran hallucination-triggering prompts ten times, 43% of invented names reappeared every single time (58% more than once). A name that models reliably re-invent is a name an attacker can register once and wait - the victims arrive on their own, prompted by the same statistical grooves in the model. Random noise would be unexploitable; repeatable hallucination is infrastructure for the attacker.

Has slopsquatting been exploited in the wild?

The building blocks are all documented in the wild: typosquatting and dependency-confusion attacks have a long incident history, malicious packages appear on registries continuously, and researchers have demonstrated the hallucination-to-registration path end to end. Attribution of specific incidents to slopsquatting specifically is harder, precisely because a successful install looks like any dependency addition - which is an argument for closing the path, not for waiting for a headline case.

Do package registries protect against this?

Partially and increasingly: registries remove reported malware, some scan uploads, and ecosystem work on trusted publishing and provenance raises the bar. None of that prevents an attacker from registering a plausible unclaimed name with functioning-but-malicious code before anyone reports it. Registry hygiene is real progress and no substitute for the consumer-side gate: your build should not resolve names nobody approved.

Security

Slopsquatting

Last updated: 2026-07-024 min read

Slopsquatting is the supply-chain attack born from AI hallucination: attackers register the package names models invent, and developers who install AI-recommended dependencies unchecked receive the attacker’s code. The numbers make it systematic – 19.7% of LLM-recommended packages did not exist across 205,000 unique invented names, and 43% of those hallucinations repeat consistently, giving attackers predictable targets. The defense closes the install path: mirrors, lockfiles, and a gate for every new dependency.

Contents

The mechanic, step by step

The attack needs no exploit – it rides on trust in the package manager. A model, asked for a solution, recommends a dependency that does not exist but sounds exactly right for the job. An attacker who knows which names models tend to invent registers one of them on the public registry, with code that works well enough not to raise alarms – plus a payload. A developer (or an agent with install permissions) runs the install command from the AI’s answer, the name now resolves, and the supply chain is breached through the front door. The term was coined by PSF security developer Seth Larson; the mechanics are typosquatting’s smarter sibling – the attacker no longer guesses what humans mistype, the model tells them what it will recommend.

The USENIX 2025 numbers

Finding	Number	Why it matters
Recommended packages that do not exist	19.7%	Systematic output property, not an occasional glitch
Unique hallucinated names observed	205,000+	A large, farmable namespace of registrable targets
Hallucinations repeating in all 10 reruns	43%	Predictable names - register once, victims arrive on their own
Repeating more than once	58%	The majority of hallucinations are stable artifacts, not noise

Key findings of 'We Have a Package for You!' (USENIX Security 2025, 16 code-generating models) - the persistence row is what turns hallucination from noise into attack surface.

The study also found commercial models hallucinating less than open-source ones – but no model clean. And the attack combines with older classes: slopsquatting meets dependency confusion where internal-sounding hallucinated names collide with public registries. The BSI/ANSSI recommendations flagged package hallucination as a supply-chain vector back in 2024.

The defenses, deterministic-first

Make unknown names fail to resolve. Internal mirrors or registry allowlists mean a hallucinated name simply does not install - the strongest single control, and standard kit in isolated environments for exactly this reason.
Lockfiles and pinned dependencies. Builds install what is locked, not what an answer suggested - new names require a deliberate lockfile change that is visible in review.
A gate for every new dependency. Human approval with a minimum check: does it exist, since when, maintained by whom, needed why. Minutes per occurrence, and occurrence is rare when tasks are scoped.
No install permissions for agents by default. An agent that cannot install cannot install malware - the permission ladder applied to the package manager.

Why the verification loop catches it structurally

Strip the security payload and a hallucinated dependency is familiar: it is hallucination plus scope creep – the AI added something the task did not ask for. A written task with boundaries makes every new dependency a visible deviation rather than a line lost in a diff, and the change-against-task check flags it before anything reaches a shared branch. The security controls above then make the unapproved path physically fail. Belt, suspenders – and the belt is the same verification loop the rest of this site describes.

Where Reality Graph fits

Reality Graph is not a registry scanner and does not analyze package payloads. Its contribution is the structural catch: with boundaries declared per run, a dependency the task did not ask for surfaces as a scope finding in the evidence report, before the human gate – whatever the name and whoever registered it. The registry-side controls remain yours to run; the two layers close the path from opposite ends.

This analysis gives you

The mechanic and the USENIX numbers, precisely sourced
The persistence insight that makes the attack farmable
Four defenses ordered by determinism
The structural catch via scope verification

It does not give you

A registry malware scanner - run dependency review tooling
A claim of documented mass exploitation - attribution is hard
Safety from typosquatting's other variants - defenses overlap, run them
A reason to ban AI suggestions - the gate, not the ban, scales

If these boundaries fit how your team wants to ship:

Get early access See how it works

FAQ

What is slopsquatting, and how do you protect against it?: Slopsquatting is registering package names that AI models hallucinate, so that developers who install an AI-recommended dependency without checking receive the attacker's code. The protection is closing the install path: lockfiles and internal mirrors so unknown names do not resolve, a review gate for every new dependency, and treating any dependency an AI run adds as a scope event that needs explicit approval. The term was coined by PSF security developer Seth Larson.
How common are hallucinated packages, measured?: The USENIX Security 2025 study 'We Have a Package for You!' measured it across 16 code-generating models: 19.7% of recommended packages did not exist, producing over 205,000 unique invented names. Commercial models hallucinated less than open-source ones, but no model was clean. The scale matters: this is not an occasional glitch but a systematic output property, large enough to farm.
Why does the 43% persistence number matter so much?: Because it converts a curiosity into an attack surface. When the researchers re-ran hallucination-triggering prompts ten times, 43% of invented names reappeared every single time (58% more than once). A name that models reliably re-invent is a name an attacker can register once and wait - the victims arrive on their own, prompted by the same statistical grooves in the model. Random noise would be unexploitable; repeatable hallucination is infrastructure for the attacker.
Has slopsquatting been exploited in the wild?: The building blocks are all documented in the wild: typosquatting and dependency-confusion attacks have a long incident history, malicious packages appear on registries continuously, and researchers have demonstrated the hallucination-to-registration path end to end. Attribution of specific incidents to slopsquatting specifically is harder, precisely because a successful install looks like any dependency addition - which is an argument for closing the path, not for waiting for a headline case.
Do package registries protect against this?: Partially and increasingly: registries remove reported malware, some scan uploads, and ecosystem work on trusted publishing and provenance raises the bar. None of that prevents an attacker from registering a plausible unclaimed name with functioning-but-malicious code before anyone reports it. Registry hygiene is real progress and no substitute for the consumer-side gate: your build should not resolve names nobody approved.
How does this relate to general AI code verification?: A hallucinated dependency is scope creep with a supply-chain payload: the AI added something the task did not ask for. That is why the general verification loop catches it structurally - a written task with boundaries makes every new dependency a visible deviation, and a human gate approves it or rejects it before anything installs. The security-specific defenses (mirrors, lockfiles) then make the unapproved path physically fail.

Keep reading

SecurityPrompt Injection Against Coding AgentsAn agent reads a poisoned README and runs the attacker's instructions - OWASP's #1 LLM risk, with 2026 CVEs against Copilot, Claude Code and MCP servers. Why it may be structural, and why containment beats cure.GuideYour First Verification ReportA team lead can stand up a first AI-code verification report in an afternoon, no platform required - the tool-agnostic roadmap, a copyable report template, and the path from one report to a team practice.All articlesThe whole collection – 58 cited, dated guides on verifying AI-generated code.