The problem in one sentence
Next time an AI assistant recommends a package to install, are you going to actually check whether that package exists? Most developers haven’t. That gap between suggestion and verification is exactly where slopsquatting attacks begin, and it’s why understanding both the evolution of slopsquatting and practical slopsquatting prevention has become a real priority for AppSec and DevSecOps teams.
What is a slopsquatting attack?
A slopsquatting attack is a variant of tipografiere (the practice of registering a domain or package name that mimics a legitimate one through a common misspelling, such as reqeusts în loc de cereri de, hoping a user’s own typo delivers them straight to it), but with an important difference in where the mistake originates. Typosquatting exploits human typing errors. A slopsquatting attack exploits the mistakes large language models make: an LLM “hallucinates” a package name that sounds perfectly legitimate but doesn’t exist in any public registry, and an attacker gets there first by registering that exact name before anyone with good intentions does.
The mechanism behind a typical slopsquatting attack is simple, and that simplicity is exactly what makes it effective:
- A developer asks an AI assistant to help solve a coding problem.
- The model generates a solution that imports or recommends installing a package that has never existed.
- An attacker who has noticed that several models keep repeating the same hallucinated name registers that package on npm, PyPI, or another public registry, with malicious code inside. This is the moment the hallucination turns into an actual slopsquatting attack.
- The next developer who gets the same suggestion and doesn’t verify it, installs the now-real package, which is a backdoor into their environment.
The term “slopsquatting” was coined by Seth Larson, Security Developer-in-Residence at the Python Software Foundation, and popularised by Andrew Nesbitt, to describe exactly this pattern: a “package hallucination” turned into an attack vector.
Slopsquatting evolution: how a research curiosity grew into a real threat
What’s notable about the evolution of slopsquatting isn’t just the concept; it’s how quickly it moved from a research observation to a documented, measurable class of attack.
2023: The first warning sign. Security researcher Bar Lanyado noticed that several LLMs repeatedly recommended a package called huggingface-cli, which doesn’t exist (the real package is installed with pip install -U “huggingface_hub[cli]”). To demonstrate the risk, he uploaded an empty version of that package to a public registry. Within three months, it had received over 30,000 downloads, with zero promotion. The hallucinated name even turned up in the README of a repository tied to research from Alibaba, showing early on how these “fake” names could leak into real documentation and set the stage for the slopsquatting attacks that would follow.
2024: The risk moves from a researcher’s blog post to mainstream tech coverage. În martie 2024, Registrul reported on how AI models were confidently inventing software package names that developers were then downloading, some of them potentially poisoned with malware. That coverage mattered less for what it revealed technically and more for what it signalled: the huggingface-cli case was no longer a one-off curiosity; it was the first sign of a pattern serious enough for mainstream tech press to flag, ahead of the large-scale academic study that would confirm the scope a year later.
2025: The first rigorous, large-scale measurement of the problem. Hârtia “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” (Spracklen et al., presented at the Securitate USENIX Symposium) tested 16 code-generation models, both commercial (GPT-4, GPT-3.5) and open source (CodeLlama, DeepSeek, WizardCoder, Mistral), across 576,000 Python and JavaScript code samples. The findings mark a clear point in the evolution of slopsquatting, moving it from anecdote to data:
- 19.7% of the packages recommended by the models didn’t exist.
- Open-source models hallucinated far more often (21.7% on average) than commercial models (5.2%).
- The worst offenders, CodeLlama 7B and CodeLlama 34B, hallucinated in more than a third of their outputs.
- Across all models tested, researchers logged over 205,000 unique hallucinated package names, a pool large enough to fuel sustained slopsquatting attacks across multiple ecosystems.
- One detail especially relevant for prevention: roughly 38% of hallucinated names closely resembled real packages, which lowers the odds that anyone spots them at a glance.
A critical detail from the study, and probably the reason the evolution of slopsquatting has accelerated rather than fizzled out, is that hallucinated names aren’t random, and they don’t change on every attempt. The same models tend to repeat the same invented names when given similar prompts, which means an attacker doesn’t need to guess. They just need to observe model behaviour, identify the names that keep recurring, and register them before a real developer does. Follow-up analysis of this repeatability found that when researchers re-ran identical prompts ten times each, 43% of hallucinated package names showed up on every single run, and 58% recurred more than once, evidence that most hallucinations are repeatable artefacts rather than one-off noise. That repeatability is what turns a one-off hallucination into a scalable slopsquatting attack.
2026: From isolated packages to autonomous agents. This year has produced the clearest evidence yet that slopsquatting is no longer confined to a developer copy-pasting a suggested pip install or npm install command. In January 2026, researcher Charlie Eriksen at Aikido Security found that AI coding agents had already spread instructions referencing a hallucinated npm package, react-codeshift (a name that plausibly conflates two real tools, jscodeshift și react-codemod), across 237 repositories, with agents still attempting to install it daily. Eriksen registered the name himself, defensively, before an attacker could weaponise it. Separately, a real malicious package named unused-imports, hallucinated in place of the legitimate eslint-plugin-unused-imports, was still recording roughly 233 weekly downloads in early 2026 despite npm placing it under a security hold, a sign of how long a slopsquatting attack can keep drawing victims even after it’s been flagged. More recently, in July 2026, researchers described a related technique, dubbed “HalluSquatting,” that chains an AI hallucination with a prompt injection so that an AI coding agent fetching a hallucinated resource on a user’s behalf can be hijacked into running attacker-supplied code, extending the evolution of slopsquatting from a passive install risk into an active remote-code-execution vector inside agentic development workflows.
Why “vibe coding” expanded the surface for slopsquatting attacks
Slopsquatting attacks wouldn’t matter much if AI-generated code were a niche practice. It isn’t. The rise of coding assistants, autonomous agents, and “vibe coding” workflows, where developers review less and less of the code before running it, has shifted the software attack surface in two concrete ways, and both are accelerating the evolution of slopsquatting:
- The entry point is no longer just the developer. A typosquatting attack used to depend on a single person making a typing mistake. Now the mistake can originate inside the model itself and propagate to hundreds of different developers who ask similar questions and get the same hallucinated recommendation, multiplying the reach of a single slopsquatting attack.
- The attack surface has moved further up the chain. It’s no longer enough to watch the code a human writes. Teams also need to watch the dependencies an AI assistant suggests, the MCP servers it connects to, and the agents that install packages autonomously with no direct human review. Traditional AppSec, built to review repositories and human commits, was never designed to observe this new interaction between developer, AI, and package registry, which is exactly where slopsquatting attacks now hide.
None of this means generative AI is inherently insecure. It means it introduces a new type of supply chain risk that traditional security tooling wasn’t built to catch, and one that calls for the same 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 or vigilance. That automation is the foundation of any real slopsquatting prevention strategy.
Slopsquatting prevention: what teams can do today
The good news is that slopsquatting prevention doesn’t require exotic tooling. It requires systematically applying dependency hygiene practices that already exist, but that many teams relax the moment an AI they trust “suggests” the code. An effective slopsquatting prevention approach usually combines the following:
- Manually verify any new package before installing it, especially when it comes from an AI assistant’s suggestion. Confirm it exists in the official registry, who maintains it, when it was published, and whether its download numbers look real. This single habit is the cheapest form of slopsquatting prevention available to any team.
- Never assume AI-generated code is safe by default. A code snippet that “works” doesn’t mean its dependencies are legitimate. Dependency review should be part of code review, not an exception to it.
- Use lockfiles and hash verification to pin exact versions and stop a silent update from swapping in a different package than the one that was originally audited.
- Deploy dependency scanning that flags risk patterns beyond known CVEs: anomalous packages, names suspiciously similar to existing ones, new maintainers with no track record, or install scripts with unusual behaviour. A newly published package with almost no history that closely mimics the name of something “almost” familiar is exactly the pattern behind most slopsquatting attacks documented so far.
- Treat public registries with the same scepticism as any other unverified external source. Faptul că pip install or npm install doesn’t throw an error is not proof of legitimacy.
- Train development teams on the fact that AI-assisted coding doesn’t remove the responsibility to verify what gets installed; it just adds a step that needs to be built into the workflow as part of any serious slopsquatting prevention plan.
None of these measures is new on its own. What’s changed is the scale: when a dependency suggestion no longer comes from Stack Overflow or a colleague, but from a model that can repeat the same hallucinated error to thousands of different developers, manual verification, while still necessary, stops being enough on its own. That’s why more teams are automating this layer of slopsquatting prevention within their Analiza compoziției software (SCA) tooling, rather than leaving it to individual developer discipline.
Aceasta este precisely why ASPM platforme precum Xygeni build suspicious-dependency detection, covering typosquatting, dependency confusion, and known malicious packages, into the same open-source and AI-dependency analysis pipeline, so slopsquatting prevention doesn’t depend on every developer remembering to check it each time an AI assistant suggests a new dependency.
FAQ
Is a slopsquatting attack the same as a typosquatting attack?
Not quite. Both involve registering a fake package name to trick whoever installs it, but the source of the error differs. Typosquatting exploits human typing mistakes. A slopsquatting attack exploits package names invented (hallucinated) by AI models, which an attacker then registers before it ever exists legitimately.
Can a package manager automatically prevent this kind of attack?
Not fully, which is exactly why slopsquatting prevention can’t stop at the package manager level. If an attacker registers the hallucinated package before a developer tries to install it, the installation will complete without any error because the package genuinely exists, even though it’s malicious. Effective prevention needs additional verification of the package’s origin and behaviour.
Does this only affect open-source models?
No. The Spracklen et al. study found hallucinations across every model tested, including commercial ones, though at a significantly lower rate (5.2% versus 21.7% for the open-source models evaluated). No model is entirely free of the problem, which is part of why the evolution of slopsquatting keeps pace with the growth of AI-assisted coding overall.
Is this a theoretical risk, or has it already been exploited?
huggingface-cli case, an empty package uploaded by a researcher that was downloaded more than 30,000 times in three months with zero promotion, shows the risk isn’t just theoretical: a hallucinated name only needs to be consistent enough across different prompts for someone to turn it into a real slopsquatting attack.
