When a developer asks an AI coding assistant to solve a problem, the assistant often reaches for a third-party library to do it — and increasingly, that library doesn't exist. A slopsquatting attack begins exactly there: an attacker notices that large language models repeatedly invent the same plausible-sounding but fake package names, registers those names on real package registries, and waits for developers to copy-paste the AI's suggestion straight into a pip install or npm install command. The malicious package installs cleanly, runs its payload, and the developer never questions it, because the name came from a tool they trusted. Unlike phishing, this attack doesn't need a human to make a careless mistake — it needs an AI model to hallucinate, which happens far more often than most engineering teams assume.
What is a slopsquatting attack?
A slopsquatting attack is the practice of registering a software package under a name that an AI coding assistant hallucinates, then loading that package with malicious code so that any developer who trusts the AI's suggestion installs the attacker's software instead of a legitimate library. The term was coined in 2024 by security researcher Seth Larson, a Python Software Foundation maintainer, to describe a variant of dependency confusion built specifically around AI hallucinations rather than typos or human error. The mechanics are simple and that's what makes them dangerous: a developer prompts an LLM for code, the model suggests import fast-json-parser or a similarly named PyPI or npm package, the developer trusts the suggestion because it reads as legitimate, and installs it without checking whether the maintainer or the package itself is real. If an attacker got there first, that install is now a supply chain compromise.
How do AI hallucinated packages end up in production code?
AI hallucinated packages end up in production because developers increasingly treat LLM output as verified fact rather than a suggestion to check. A March 2025 academic study published at USENIX Security — conducted by researchers at the University of Texas at San Antonio, Virginia Tech, and the University of Oklahoma — ran 16 popular code-generating LLMs, including GPT-4, GPT-3.5, CodeLlama, DeepSeek, and Mistral, against 576,000 code generation tasks in Python and JavaScript. The result: 19.7% of the more than 2.23 million package references produced by these models pointed to packages that simply do not exist, totaling 205,474 unique hallucinated package names. Commercial models fared better than open-source ones — GPT-4 hallucinated in roughly 5.2% of samples versus an average of 21.7% for open-source models, with some, like CodeLlama 7B, hallucinating in over a third of outputs. When that suggested import statement flows straight from a Copilot-style autocomplete into a CI pipeline without a human questioning the package's provenance, the hallucination becomes a real dependency.
Why does package name confusion make slopsquatting so effective?
Package name confusion works because hallucinated names aren't random noise — they're eerily consistent and follow predictable naming conventions that mimic real packages closely enough to pass a glance-test. The same USENIX study found that 43% of hallucinated package names reappeared across ten repeated queries of the same prompt, and 58% showed up more than once across multiple runs, meaning an attacker doesn't need to guess blindly. They can query the same models the rest of the developer population is using, harvest the most frequently repeated hallucinations, and register those specific names on PyPI or npm before anyone else does. This is a meaningfully different threat model than classic typosquatting, where an attacker bets on a human fat-fingering "reqeusts" instead of "requests." With slopsquatting, the attacker is exploiting a systematic, reproducible blind spot in the model itself, and the resulting name often looks more legitimate than a typo would — things like python-json-logger-utils or bardapi variants that sound exactly like something that should already exist.
How big is the LLM dependency risk in real numbers?
The LLM dependency risk is now large enough that it rivals traditional typosquatting as a primary vector for supply chain attacks, with hundreds of thousands of exploitable name candidates generated by mainstream tools every month. Socket's research team and other supply chain security groups have separately confirmed hallucinated package names appearing in real GitHub repositories and Stack Overflow answers that were themselves AI-generated, creating a feedback loop where hallucinated names get cited enough times online that later models treat them as legitimate training signal. Because code-generation tools like GitHub Copilot, Cursor, and ChatGPT are now used by a majority of professional developers day-to-day — GitHub reported in 2023 that Copilot was writing on average 46% of code in files where it was enabled — even a 5-20% hallucination rate across millions of daily completions adds up to an enormous number of opportunities for an attacker to have already claimed the exact name a developer is about to install.
Which incidents show slopsquatting attacks are already happening?
Slopsquatting attacks are no longer theoretical — security researchers have already demonstrated the full attack chain and found evidence of squatted names live on public registries. In 2023, before the term "slopsquatting" existed, researchers at Vulcan Cyber demonstrated the concept directly by asking ChatGPT for npm and PyPI package recommendations, identifying a fictitious package it repeatedly suggested called huggingface-cli, and publishing a proof-of-concept package under that exact name to show how easily it could have been weaponized. Separately, security firm Lasso and other researchers have documented real hallucinated names later found registered — sometimes benignly by researchers racing to squat them defensively before an attacker could, and sometimes by unknown actors whose packages were pulled only after community reports. Because there is no registry-wide mechanism that flags "this package name was recently hallucinated by GPT-4," the window between a name being hallucinated at scale and someone registering it maliciously can be measured in days, not months.
How does slopsquatting compare to other supply chain attacks?
Slopsquatting compares to typosquatting and dependency confusion in outcome but differs sharply in how the target list is generated, which makes it harder to defend against with older tooling. Traditional typosquatting defenses work by diffing a requested package name against a known list of popular packages and flagging near-matches — a technique that catches "reqeusts" but does nothing for a wholly invented name like fast-json-parser that isn't a misspelling of anything. Dependency confusion attacks exploit mismatches between internal and public registries, which is a configuration problem; slopsquatting exploits a trust problem, where the developer's own tooling recommended the malicious dependency in the first place. That means defenses built purely around registry namespace hygiene or known-typo databases miss slopsquatting entirely, and organizations need visibility into what AI tools are actually suggesting versus what dependencies are already verified as legitimate before code ever reaches a lockfile.
How Safeguard Helps
Safeguard closes the gap that slopsquatting attacks exploit by verifying every dependency against real registry provenance, maintainer history, and publish-time behavior before it's allowed into a build — not just checking whether a name looks similar to something popular. Our platform continuously scans manifests, lockfiles, and CI pipelines for newly introduced packages, flags dependencies with suspiciously recent publish dates, thin or nonexistent maintainer histories, and low download counts relative to how a package is being described, all classic fingerprints of a package registered specifically to catch AI-suggested installs. Because slopsquatting depends on a developer trusting an LLM's suggestion faster than they'd verify a human recommendation, Safeguard integrates directly into the developer workflow — IDE, PR, and CI checks — so that a hallucinated, squatted package gets caught at the moment it's introduced, not after it's already shipped to production. As AI-assisted development becomes the default rather than the exception, treating every AI-suggested dependency as unverified until proven otherwise isn't paranoia, it's baseline software supply chain hygiene, and it's exactly the layer Safeguard is built to provide.