Slopsquatting Evolution

Slopsquatting evolution: From AI Curiosity to Agent RCE

Next time an AI assistant recommends a package to install, are you going to check whether it actually exists? Most developers don’t. That gap between suggestion and verification is where slopsquatting attacks begin, and in less than three years, the threat has evolved from a researcher’s proof of concept into remote code execution inside autonomous coding agents. This piece traces the slopsquatting evolution and what each stage means for AppSec and DevSecOps teams.

New here? Start with our primer on what slopsquatting is and how to defend against it, then come back for the timeline.

A slopsquatting attack in one paragraph

A slopsquatting attack registers a malicious package under a name that AI models predictably hallucinate. Where typosquatting exploits a human mistyping reqeusts for requests, slopsquatting exploits the model itself inventing a plausible name that exists in no registry, then an attacker claims that exact name before anyone legitimate does. The term was coined by Seth Larson, Security Developer-in-Residence at the Python Software Foundation, and popularized by Andrew Nesbitt. What makes the pattern worth tracking is how fast it has matured.

Slopsquatting evolution

2023: the first warning sign

Security researcher Bar Lanyado noticed that several LLMs kept recommending a package called huggingface-cli, which doesn’t exist (the real tool installs with pip install -U “huggingface_hub[cli]”). To demonstrate the risk, he uploaded an empty package under that hallucinated name. Within three months it had been downloaded more than 30,000 times, with zero promotion, and the fake name even appeared in the README of a repository tied to research from a major technology company. The package was harmless. The lesson was not: a hallucinated name only has to be consistent enough for someone to weaponize it.

2024: from blog post to mainstream coverage

In March 2024, The Register reported on AI models confidently inventing software package names that developers were then downloading, some potentially poisoned with malware. The coverage mattered less for what it revealed technically than for what it signalled: huggingface-cli was no longer a one-off curiosity but the first sign of a pattern serious enough for mainstream tech press to flag, ahead of the large-scale study that would confirm its scope a year later.

2025: the first rigorous measurement

The USENIX Security 2025 paper “We Have a Package for You!” (Spracklen et al.) tested 16 code-generation models, commercial and open source, across 576,000 Python and JavaScript samples. It moved slopsquatting from anecdote to data:

  • 19.7% of recommended packages did not exist.
  • Open-source models hallucinated far more often (21.7% on average) than commercial ones (5.2%).
  • The worst offenders, CodeLlama 7B and 34B, hallucinated in more than a third of their outputs.
  • Across all models, researchers logged over 205,000 unique hallucinated names, a pool large enough to fuel sustained campaigns across ecosystems.

The study also categorized how the fakes form: 38% were conflations that merge two real package names (exactly the pattern that later produced react-codeshift from jscodeshift and react-codemod), 13% were typo-style variants of real packages, and 51% were pure fabrications that are plausible but entirely invented. That first group matters most for defense, because a name stitched together from two real tools is the hardest to spot at a glance.

The single most important finding for attackers: hallucinations are not random and don’t change on every attempt. When researchers re-ran identical prompts ten times each, 43% of hallucinated names appeared on every single run and 58% recurred more than once. An attacker doesn’t need to guess. They observe model behavior, note the names that keep recurring, and register them first. That repeatability is what turns a one-off hallucination into a scalable attack.

2026: from isolated packages to autonomous agents

This year produced the clearest evidence yet that slopsquatting is no longer confined to a developer copy-pasting a suggested npm install.

In January 2026, security researcher Charlie Eriksen found a hallucinated npm package, react-codeshift, that AI-generated agent instructions had already spread across 237 repositories through forks, with agents still attempting to install it daily. It originated in a single commit of AI-written agent skill files that no human had reviewed. Eriksen registered the name himself, defensively, before an attacker could weaponize it.

Separately, a genuinely malicious package named unused-imports, hallucinated in place of the legitimate eslint-plugin-unused-imports, kept drawing installs even after npm placed it under a security hold, showing how long a slopsquatting attack can keep finding victims after it’s been flagged.

Then, in July 2026, researchers described a related technique dubbed “HalluSquatting” that chains a hallucination with a prompt injection: an AI coding agent fetching a hallucinated resource on a user’s behalf can be hijacked into running attacker-supplied code. That extends the slopsquatting evolution from a passive install risk into an active remote-code-execution vector inside agentic development workflows.

Why “vibe coding” expanded the attack surface

Slopsquatting wouldn’t matter much if AI-generated code were niche. It isn’t. The rise of coding assistants, autonomous agents, and “vibe coding” workflows, where developers review less of the code before running it, has shifted the attack surface in two concrete ways.

First, the entry point is no longer just the developer. A typosquatting attack depended on one person mistyping. Now the mistake originates inside the model and propagates to hundreds of developers who ask similar questions and get the same hallucinated recommendation.

Second, the attack surface moved up the chain. It’s no longer enough to watch the code a human writes. Teams have to watch the dependencies an AI assistant suggests, the MCP servers it connects to, and the agents that install packages with no human in the loop. Traditional AppSec, built to review repositories and human commits, was never designed to observe that interaction between developer, AI, and registry, which is exactly where slopsquatting now hides.

What this means for prevention

None of this makes generative AI inherently insecure. It introduces a supply chain risk that traditional tooling wasn’t built to catch, and it calls for the verification principles we already apply to any external dependency: don’t trust by default, verify the source, and automate that verification instead of relying on every developer’s memory. The full defensive playbook is in our guide to AI supply chain security, but the short version is that manual verification, while still necessary, stops scaling the moment a hallucinated name can reach thousands of developers at once, or an agent can install it with no human review at all.

Stop hallucinated packages before an agent installs them

The 2026 cases share one trait: the dangerous install happens without a human in the loop. That’s the exact gap Xygeni Shield is built for. Shield is a lightweight agent on the developer’s endpoint that blocks malicious packages at install time, using Malware Early Warning (MEW) verdicts that work before any signature exists. When an AI assistant or autonomous agent tries to install a hallucinated, freshly registered package, Shield evaluates it as it’s fetched and blocks it, so the install script never runs, whether or not a human was watching. Every block flows into the same Xygeni console as your code, build, and runtime findings, and Shield runs alongside your existing EDR rather than against it.

Start free. Xygeni’s Developer plan is €0: 10 repositories, 200 scans a month, up to 5 contributors, no credit card. Sign up with GitHub, GitLab, or Google and run your first scan in under 10 minutes; Shield endpoint protection is coming to the Developer plan soon. 

FAQ

Can a package manager prevent slopsquatting on its own?

Not fully. npm’s collision detection blocks names too similar to existing packages, which helps against typosquatting, but a hallucinated name is a brand-new string with no collision to detect. If an attacker registers the hallucinated package before a developer installs it, the install completes without error because the package genuinely exists. Prevention needs verification of the package’s origin and behavior, not just the registry’s own checks.

What makes the 2026 agent cases different from earlier slopsquatting?

Earlier incidents depended on a human copy-pasting a suggested install command. In the 2026 cases, autonomous agents installed or attempted to install hallucinated packages with no human reviewing the step, and the HalluSquatting technique went further by chaining a hallucination with a prompt injection to achieve remote code execution inside the agent’s workflow.

sca-tools-software-composition-analysis-tools
Prioritize, remediate, and secure your software risks
Get your Free Account.
No credit card required.

Secure your Software Development and Delivery

with Xygeni Product Suite