Slopsquatting and Package Hallucination Guide

Code-generating AI models regularly recommend software packages that do not exist, and an attacker who registers one of those invented names can have developers and AI agents install their code on request. This is slopsquatting: squatting on package names that large language models hallucinate. Peer-reviewed research presented at USENIX Security 2025 found hallucinated packages in at least 5.2% of package suggestions from commercial models and 21.7% from open-source models, and many hallucinations repeat for the same prompt. This guide explains how the attack works, where it shows up, how to detect it and how to harden developer workflows, CI pipelines and coding agents. It is written for application security, platform engineering and developer tooling teams. Broader malicious package, typosquatting and dependency confusion defences are covered in the Malicious Package and Dependency Confusion Guide; this page covers what is specific to AI-invented names.

Key takeaways

Hallucinated packages are common and repeatable. Spracklen et al. recorded 205,474 unique hallucinated package names, and 43% of hallucinated packages reappeared in all ten repeats of the same prompt.
Repeatability is what makes it exploitable. An attacker can ask models the same questions developers ask, collect the names that come back consistently, and register them.
Most invented names are not typos. Only 13.4% of hallucinated names in the study were one or two edits from a real package, so typosquatting detectors miss most of them.
"It exists on the registry" proves nothing. Once an attacker publishes the name, an allowlist that only checks existence passes it. Age, popularity, provenance and behaviour matter.
Agents raise the stakes. A coding agent that both suggests and installs a dependency removes the human pause where a developer might have checked it.

How the attack works

The research term is package hallucination: a model generates code or instructions that import or install a package that is not in the registry. Seth Michael Larson, security developer-in-residence at the Python Software Foundation, coined the name slopsquatting for registering those names (reported by The Register, April 2025). MITRE ATLAS describes the two adversary steps as AML.T0062 Discover LLM Hallucinations and AML.T0060 Publish Hallucinated Entities.

Discovery: the attacker sends models the kinds of coding questions developers ask and records package names that do not exist in PyPI, npm or other registries.
Selection: names that recur across repeats, or across models, are the valuable ones, because many users will receive the same suggestion.
Registration: the attacker publishes a package under the name, often with a plausible README and repository to look legitimate.
Installation: a developer, a CI job or a coding agent follows the AI's suggestion and installs it. Install-time scripts (npm lifecycle scripts, Python source builds) or import-time code then run with the developer's or pipeline's access.

The concept was demonstrated safely in 2024. Bar Lanyado of Lasso Security published an empty package under a name that models repeatedly hallucinated, huggingface-cli, and recorded more than 30,000 authentic downloads in three months; installation instructions for it had appeared in a README in an Alibaba research repository. OWASP's Top 10 for LLM Applications 2025 now uses hallucinated packages as an attack scenario under LLM09:2025 Misinformation.

What the research measured

Finding	Value	Source
Models and samples	16 code-generating LLMs, 576,000 code samples, Python (PyPI) and JavaScript (npm)	Spracklen et al., USENIX Security 2025
Hallucination rate	At least 5.2% average for commercial models, 21.7% for open-source models	Spracklen et al.
Unique hallucinated names	205,474	Spracklen et al.
Repetition over 10 re-queries	43% repeated every time, 39% never repeated, 58% repeated more than once	Spracklen et al.
Distance from real names	13.4% within 1 to 2 edits; 48.6% six or more edits away	Spracklen et al.
Cross-language confusion	8.7% of hallucinated Python names were valid npm packages	Spracklen et al.
Temperature	Hallucination rates rose with sampling temperature for all models	Spracklen et al.
Real-world uptake	Over 30,000 downloads of an empty proof-of-concept package in three months	Lasso Security, 2024

Where it shows up

Chat assistants: a developer asks for a snippet and copies pip install or npm install lines into a terminal.
IDE assistants and coding agents: suggested imports, generated requirements.txt or package.json entries, and agents with terminal access that install dependencies to make tests pass. See the AI Coding Agents Security Guide.
Vibe coding and AI app builders: users who cannot judge whether a dependency is real accept whatever the tool adds. See the Vibe Coding Security Guide.
Documentation and search: AI-written tutorials, READMEs and search summaries repeat hallucinated or malicious names. The Register reported a Google AI Overview suggesting a typosquatted npm package, @async-mutex/mutex, in place of the real async-mutex.
Cross-ecosystem confusion: a model suggests a name that is real in npm for a Python project. The name may be free on PyPI and therefore claimable.
Ecosystem differences: Lasso found Go and .NET produced many hallucinations that were harder to exploit, because Go modules are fetched from many locations and many .NET names used reserved prefixes. Central registries with open, first-come naming (PyPI, npm) are the main exposure.

Attackers are also targeting AI-assisted developers in other ways. In the TrapDoor Supply Chain Campaign 2026, malicious npm packages planted hidden instructions in .cursorrules and CLAUDE.md files to steer coding assistants; that campaign used invented tool names rather than documented hallucinations, but it shows the same intent to exploit AI in the dependency path.

Impact

Stage reached	Likely impact	Identity angle
Developer workstation	Install or import code runs as the developer: theft of SSH keys, cloud credentials, tokens and browser data	Developer tokens, cloud keys and registry publish tokens become attacker credentials
CI/CD pipeline	Code runs with pipeline secrets; build outputs can be tampered with	Pipeline service accounts and deployment keys; see the Secrets Management Guide
Shipped product	Malicious dependency reaches customers through your release	Your signing and publishing identities vouch for attacker code
Coding agent session	Agent installs and runs the package with whatever access the agent holds	Agent tokens and tool permissions; over-scoped agents widen the blast radius

ATT&CK classifies the delivery as T1195.001 Compromise Software Dependencies and Development Tools, and ATLAS lists AML.T0011.001 Malicious Package for user execution of a malicious package in AI workflows.

Detection

New dependency review: flag every pull request that adds a direct dependency not already used in the organisation, and surface package age, maintainer history, download trend, repository link and install scripts in the review.
Young-package alerts: alert when a build resolves a package or version published in the last few days, and on packages with very low downloads but sudden interest from your developers.
Registry miss logging: your internal proxy or repository manager sees requests for names that do not exist upstream. Repeated misses for the same name across developers often mean an AI tool is suggesting it; that name is a squatting candidate and should be blocked or reserved.
Behavioural scanning: scan new packages for install-time network calls, credential file access, obfuscated code and binaries. Existence and CVE checks alone do not detect a brand-new malicious package.
Agent logs: record every package install command executed by coding agents, with the prompt context, and review installs of packages new to the organisation.
Provenance gaps: npm audit signatures reports registry signatures and provenance attestations; a newly added dependency without them deserves a closer look, although provenance does not prove the code is benign.

Metrics that show control: percentage of package installs that go through the internal proxy; number of new direct dependencies added per month and the share reviewed; count of blocked installs of packages younger than the cooldown window; time to block a reported hallucinated or malicious name; percentage of coding agent sessions running with install restrictions.

Prevention and hardening

Package manager and registry controls

Control	Ecosystem setting	Effect on slopsquatting
Internal proxy or curated mirror	npm `registry`; pip `--index-url`	One place to block, quarantine and log new names
Release age cooldown	npm `min-release-age` (days) or `before` (date); equivalent proxy policies	Newly registered squats are not installable until scanners and registries have had time to react
Block install scripts	npm `ignore-scripts=true`	Stops lifecycle scripts running at install; code can still run when imported
Lockfiles and hashes	npm `package-lock.json` with `npm ci`; pip `--require-hashes` with pinned `==` versions	Builds install exactly what was reviewed; a new name cannot slip in without a lockfile change
Avoid source builds	pip `--only-binary :all:`	Prevents arbitrary build code running from source distributions
Restrict git dependencies	npm `allow-git=none` or `root`	Stops dependencies pulled from arbitrary repositories
Verify signatures and provenance	`npm audit signatures`	Confirms registry signatures and build provenance where present

AI tool and agent controls

Ground the model: the research found retrieval-augmented generation and self-refinement reduced hallucination rates; fine-tuning reduced them most but cut code quality sharply. Give assistants your approved package list as context and instruct them to prefer well-known packages.
Ask the model to check itself: GPT-4 Turbo, GPT-3.5 and DeepSeek identified their own hallucinated packages with over 75% accuracy in the study. A second pass that asks "does each package exist and is it the canonical one?" is cheap, though not sufficient on its own.
Lower temperature for code: hallucination rates rose with temperature in every model tested.
No unsupervised installs: configure coding agents to propose dependency changes rather than install them, or restrict them to the internal proxy with the cooldown applied. See the GitHub Copilot Security Guide.
Least privilege for build and agent identities: short-lived credentials on developer machines and in CI, so a malicious install has little to steal. See the AI Coding Agents Security Guide.

Rollout order

Route all installs through an internal proxy and start logging misses and new packages (no blocking yet).
Turn on new-dependency review in pull requests and require lockfiles in CI.
Enable a release-age cooldown in report-only mode, measure how many builds it would affect, then enforce with an exception process for urgent security fixes.
Set ignore-scripts for CI and agents, with an allowlist for packages that genuinely need install scripts; roll back per project if builds break, not globally.
Restrict coding agents to propose-only dependency changes, then extend to developer guidance and training.

Small teams can get most of the benefit from lockfiles, a cooldown setting and pull request review of new dependencies. Large organisations should add the proxy, behavioural scanning, registry-miss analytics and agent policy enforcement.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0062 Discover LLM Hallucinations; AML.T0060 Publish Hallucinated Entities; AML.T0011.001 Malicious Package	The attacker's discovery, registration and execution steps
MITRE ATT&CK	T1195.001 Compromise Software Dependencies and Development Tools	Delivery through a dependency
OWASP Top 10 for LLM Applications 2025	LLM09:2025 Misinformation; LLM03:2025 Supply Chain	Hallucinated packages scenario; dependency risks in LLM applications
NIST SP 800-53 Rev. 5	SR-3; SR-4 Provenance; SR-11 Component Authenticity; CM-7(5); SI-7	Supply chain controls, provenance, authenticity, allow-by-exception, integrity
NIST CSF 2.0	ID.RA-09; GV.SC-07; ID.AM-02	Assess authenticity of software before use; supplier risk; software inventory

Lessons from incidents

No breach in the NHI Mgmt Group database is yet attributed to a slopsquatted package, and the best documented case remains the harmless huggingface-cli experiment. The surrounding incidents still teach the defences: the TrapDoor Supply Chain Campaign 2026 showed attackers deliberately targeting AI coding assistants through packages, and its payload went straight for SSH keys, cloud credentials and GitHub tokens, which is exactly what a slopsquatted package would do once installed. See the Malicious Package and Dependency Confusion Guide for registry-level defences.

Practitioner checklist

Route every package install, including from coding agents and CI, through an internal proxy that logs misses.
Require pull request review for any new direct dependency, showing age, maintainers and install scripts.
Enforce a release-age cooldown with a documented exception path.
Commit lockfiles, use npm ci, and use pinned versions with --require-hashes for Python.
Disable install scripts in CI and agent environments unless a package is allowlisted.
Configure coding agents to propose, not install, new dependencies.
Give AI assistants an approved package list and a verification step for package names.
Block or reserve names that internal logs show AI tools repeatedly suggest but that do not exist.
Keep developer and CI credentials short-lived so a malicious install has little to steal.

Slopsquatting and Package Hallucination Guide: Defending Against AI-Invented Dependencies