Slopsquatting in 2026: the numbers that matter

“Slopsquatting” describes a supply-chain risk created when a code-generating model recommends a plausible package that does not exist, and another party registers that name before a developer installs it.

The strongest numbers come from the peer-reviewed USENIX Security 2025 paper We Have a Package for You!. The researchers tested 16 models with two prompt datasets and analyzed 576,000 Python and JavaScript code samples.

What the study found

Across its experiments, the paper reports an average percentage of hallucinated packages of at least 5.2% for commercial models and 21.7% for open-source models. It also reports 205,474 unique hallucinated package names.

These are experimental results under the study's models, prompts, languages, and definitions. They do not mean that 5.2% or 21.7% of all packages in production are malicious, or that every hallucinated name becomes an attack.

Where risk appears

The dangerous sequence has several steps: a model emits a non-existent package name; the name is plausible enough to trust; an attacker publishes under that name; and a developer or agent installs it without checking provenance. Breaking any step reduces risk.

The model alone is not the complete security boundary. Package managers, code review, lockfiles, registry provenance, installation scripts, and dependency policy all matter.

Practical controls

Before installing an unfamiliar dependency, verify that it exists in the expected registry, inspect its publisher and history, confirm the name in primary documentation, and review lifecycle scripts. Pin and review lockfile changes. In automated coding workflows, require approval before dependency installation and keep execution isolated from production credentials.

Verglos includes package-name checks as one scanner signal. That signal should trigger review, not declare a package malicious. A missing or suspicious name is evidence to investigate; registry existence by itself is not proof of trustworthiness.

The research supports a narrow conclusion: package hallucination is measurable and can create an exploitable naming opportunity. Defending against it requires verification at the point where generated text becomes an installed dependency.