What is slopsquatting?

Slopsquatting is an attack path in which an adversary publishes a package under a name that a model may suggest even though the intended package did not exist. Harm still requires later steps. The name must resolve in the relevant ecosystem, a person or automation must accept and install it, and the package must execute in a consequential context.

Is slopsquatting the same as typosquatting or dependency confusion?

No. Slopsquatting starts with a model-suggested nonexistent name. Typosquatting relies on a human mistyping or confusing a similar name. Dependency confusion exploits resolver or namespace precedence between package sources. A compromised legitimate package already existed and was later altered. The paths can interact, but the initiating conditions differ.

How common are package hallucinations?

The USENIX Security 2025 study tested 16 models, two prompt datasets, Python and JavaScript, and 576,000 generated samples. It reported at least 5.2% hallucinated-package rates for the commercial models studied and 21.7% for the open-source models studied, plus 205,474 unique hallucinated names. Those are results for that experiment, not a universal current prevalence rate or evidence of successful attacks.

Does a lockfile stop slopsquatting?

A reviewed lockfile can expose or prevent an undeclared dependency change in a controlled install. It does not establish that the locked package is trustworthy, that the lockfile was reviewed, or that every install enforces it. Registry policy, source configuration, provenance checks, least privilege, review, and monitoring address different parts of the path.

What evidence should a dependency decision retain?

Record the requested dependency and rationale, package ecosystem and source, resolved name and version, and lockfile diff. Also record available integrity or provenance data, reviewed publisher and release history, scanner output, approver, install permissions, and the residual-risk decision. That evidence is scoped to one decision and date.

Security

Slopsquatting

Last updated: 2026-07-173 min read

Slopsquatting is a multi-step package-supply-chain path, not a synonym for every hallucinated dependency. A model suggests a nonexistent name; an adversary publishes under that name; a resolver selects it; a person or agent installs it; and its code reaches useful privileges. Each step needs evidence and can be constrained, but no single control removes the wider risk.

Contents

Start with the measured phenomenon

The USENIX Security 2025 study evaluated 16 models, two prompt datasets, Python and JavaScript, and 576,000 generated samples. It reported at least 5.2% hallucinated-package rates for the commercial models studied, 21.7% for the open-source models studied, and 205,474 unique hallucinated names. Checked 17 July 2026. These are bounded experimental findings-not a current universal rate, a count of malicious packages, or evidence that any suggestion produced a compromise.

Source and measurement boundary

Scope: Model-generated Python and JavaScript package recommendations, the later registry and resolver path, and consumer-side controls.
As of: 17 July 2026
Method: Separate model output, package existence at observation time, adversary publication, resolution, installation, execution, observed effect, control, evidence, and residual risk.
Primary sources: Experimental population: The paper evaluated 16 code-generating models with two prompt datasets and 576,000 generated samples in Python and JavaScript.USENIX Security 2025 paper · 2026-07-17Results depend on the sampled models, prompts, ecosystems, dates, and the paper's package-existence method.
Observed package hallucinations: The paper reports at least 5.2% for the commercial models studied, 21.7% for the open-source models studied, and 205,474 unique hallucinated package names.USENIX Security 2025 paper · 2026-07-17These figures are experimental outputs, not a universal prevalence estimate or incident count.
Consumer-side boundary: BSI and ANSSI recommend treating AI coding output as untrusted and checking dependencies and generated code within a wider security process.BSI/ANSSI recommendations · 2026-07-17Guidance identifies risk treatments; it does not show that a selected control is configured or effective in a particular workflow.
Not inferred: No claim of a confirmed slopsquatting incident or current attack prevalence
No transfer of findings to every model, prompt, language, registry, or date
No security conclusion from a package name, lockfile, scanner, mirror, or allowlist alone
Limitations: A hallucinated name is not yet an attacker-controlled package or successful install
Package existence, ownership, resolver configuration, and registry behavior can change
Controls reduce particular paths and leave configuration, publisher, transitive, and runtime risks

The cited study measures package hallucinations under a defined experiment; it does not measure current ecosystem prevalence, successful compromise, or the effectiveness of your controls.

Keep adjacent supply-chain paths distinct

Slopsquatting begins with a model-suggested name that did not exist in the intended source at the relevant observation time. Typosquatting begins with a confusingly similar name. Dependency confusion begins with source or namespace precedence. Compromise of a legitimate package begins after a real package or publisher already exists. The same registry, resolver, or runtime can appear in several paths, but similar impact does not establish the same threat.

Trace the path before assigning the attack label

A model suggestion, a published package, an install, and an observed impact are separate events with separate evidence.
	Model suggestion	Adversary publication	Resolution and install	Execution and effect	Adjacent attack class
QuestionWhat must be established?	Did the model name a package absent from the intended source at that time?Threat decomposition · 2026-07-17A review question, not an incident finding.	Was the name published by an adversary rather than a legitimate owner?Threat decomposition · 2026-07-17A review question, not an incident finding.	Which source, name, and version did the package manager resolve and install?Threat decomposition · 2026-07-17A review question, not an incident finding.	What code ran with which identity, data, network, and filesystem access?Threat decomposition · 2026-07-17A review question, not an incident finding.	Did the path instead begin with a typo, source precedence, or compromise of an existing package?Threat decomposition · 2026-07-17A review question, not an incident finding.
ControlWhat can constrain this step?	Grounded catalogs, dependency policy, and explicit task boundariesLayered-control exampleSelect and test controls for the actual ecosystem and resolver.	Approved sources, namespace ownership, provenance checks, and publisher reviewLayered-control exampleSelect and test controls for the actual ecosystem and resolver.	Source pinning, scoped namespaces, mirrors, lockfile enforcement, and approvalLayered-control exampleSelect and test controls for the actual ecosystem and resolver.	Isolation, least privilege, egress limits, runtime monitoring, and rollbackLayered-control exampleSelect and test controls for the actual ecosystem and resolver.	Threat-specific registry and resolver controls plus incident analysisLayered-control exampleSelect and test controls for the actual ecosystem and resolver.
EvidenceWhat can be retained?	Prompt/output, intended source, lookup method, and timestampObservable artifactAvailability and meaning vary by package ecosystem.	Registry metadata, provenance, artifact hash, and review recordObservable artifactAvailability and meaning vary by package ecosystem.	Resolver configuration, lockfile diff, install log, and integrity resultObservable artifactAvailability and meaning vary by package ecosystem.	Process, network, filesystem, identity, and incident telemetryObservable artifactAvailability and meaning vary by package ecosystem.	Original requested name, source order, ownership history, and artifact historyObservable artifactAvailability and meaning vary by package ecosystem.
Residual riskWhat remains open?	A later publication can change whether the name resolvesResidual-risk boundary · 2026-07-17No single control removes supply-chain risk.	Identity and provenance signals can be absent, forged, or incompleteResidual-risk boundary · 2026-07-17No single control removes supply-chain risk.	Misconfiguration, transitive dependencies, and permitted malicious versions remainResidual-risk boundary · 2026-07-17No single control removes supply-chain risk.	An allowed package may still behave unexpectedly or become compromised laterResidual-risk boundary · 2026-07-17No single control removes supply-chain risk.	Similar outcomes do not establish the same initiating mechanismResidual-risk boundary · 2026-07-17No single control removes supply-chain risk.

A model suggestion, a published package, an install, and an observed impact are separate events with separate evidence.

Layer controls around resolution, installation, and execution

Treat an AI-suggested dependency as untrusted until reviewed. Constrain allowed sources and namespaces, and make new dependencies explicit task-scope changes. Review lockfile and publisher evidence, and retain integrity or provenance data the ecosystem provides. Scan artifacts, limit automatic install permissions, isolate builds, constrain egress and credentials, and monitor execution.

The BSI/ANSSI guidance supports dependency and generated-code review as part of a wider security process. Checked 17 July 2026. An allowlist can constrain resolution; a lockfile can make a change visible; a scanner can report what its rules recognize. None establishes package trust by itself.

Where Reality Graph fits

Reality Graph can bind an AI coding run to declared files, dependency boundaries, selected checks, observed results, changed files, and an operator decision. That can surface an undeclared dependency and preserve review evidence. It does not inspect every package payload, operate a registry, validate publisher identity, monitor runtime behavior, or replace package-manager, scanner, build-isolation, and incident-response controls. See the broader AI code vulnerability boundary.

A bounded record can show

Which dependency was requested, why, from which ecosystem and source
Which name, version, hash, source, lockfile change, and policy result were observed
Who approved the change, which checks ran, and which residual risks were accepted

It cannot establish

That a nonexistent suggestion or suspicious package proves a slopsquatting attack
That an allowlist, mirror, lockfile, scanner, local model, or verification removes supply-chain risk
That publisher ownership, package content, transitive dependencies, or runtime behavior will remain safe

A governed dependency decision can document a path and observed controls; it cannot establish that a registry, package, or future install is secure.

FAQ

What is slopsquatting?: Slopsquatting is an attack path in which an adversary publishes a package under a name that a model may suggest even though the intended package did not exist. Harm still requires later steps. The name must resolve in the relevant ecosystem, a person or automation must accept and install it, and the package must execute in a consequential context.
Is slopsquatting the same as typosquatting or dependency confusion?: No. Slopsquatting starts with a model-suggested nonexistent name. Typosquatting relies on a human mistyping or confusing a similar name. Dependency confusion exploits resolver or namespace precedence between package sources. A compromised legitimate package already existed and was later altered. The paths can interact, but the initiating conditions differ.
How common are package hallucinations?: The USENIX Security 2025 study tested 16 models, two prompt datasets, Python and JavaScript, and 576,000 generated samples. It reported at least 5.2% hallucinated-package rates for the commercial models studied and 21.7% for the open-source models studied, plus 205,474 unique hallucinated names. Those are results for that experiment, not a universal current prevalence rate or evidence of successful attacks.
Does a lockfile stop slopsquatting?: A reviewed lockfile can expose or prevent an undeclared dependency change in a controlled install. It does not establish that the locked package is trustworthy, that the lockfile was reviewed, or that every install enforces it. Registry policy, source configuration, provenance checks, least privilege, review, and monitoring address different parts of the path.
What evidence should a dependency decision retain?: Record the requested dependency and rationale, package ecosystem and source, resolved name and version, and lockfile diff. Also record available integrity or provenance data, reviewed publisher and release history, scanner output, approver, install permissions, and the residual-risk decision. That evidence is scoped to one decision and date.

Keep reading

SecuritySecurity Vulnerabilities in AI CodeVeracode's 100+ LLMs: 45% introduced OWASP Top 10 flaws, XSS failed at 86%, Java at 72% - and security stayed flat across model generations. The classes, the causes, and a defense stack ordered deterministic-first.Local-firstWhat AI Coding Tools Actually ReadPrompts, repo context, indexes, telemetry - the five transmission paths mapped to countermeasures, with the measured numbers: AI-assisted commits leak secrets at twice the baseline rate.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.

Sources

Want to see what your last agent run would have looked like?

Request access