In certain instances, we may earn revenue when a reader makes a purchase or completes a form through our pages or on a partner’s website. We adhere to a strict Slopsquatting is a growing cyber threat, and it doesn’t need you to make a mistake.
This attack goes after developers who trust AI coding tools. When these tools suggest fake package names, attackers move quickly – they register the name first and upload harmful code.
Slopsquatting is already slipping into open-source projects, and many teams don’t see it coming. Here’s what it is and why it matters.
Key Takeaways
- Slopsquatting exploits AI hallucinations by turning fake package suggestions into real malicious code.
- Unlike typosquatting, slopsquatting doesn’t rely on human error – it hijacks trust in AI coding tools.
- Open-source LLMs have significantly higher hallucination rates, with some exceeding 35%.
- Traditional filters often miss slopsquatting attacks because the fake package names don’t resemble real ones.
- Techniques like retrieval-augmented generation (RAG) and self-refinement can sharply reduce AI hallucinations.
- Slopsquatting is already affecting open-source ecosystems. Developers need proactive defenses, not reactive ones.
- Show Full Guide
What Is Slopsquatting & How Is It Different From Typosquatting?
Slopsquatting is an emerging attack strategy that builds on AI-generated hallucinations.
It may sound unusual, but this threat is already starting to show up in real-world developer workflows. While typosquatting is based on human mistakes, like misspelling a package name, slopsquatting takes advantage of something else entirely: hallucinations made by AI coding tools.
Let’s break it down.
- Typosquatting happens when someone creates a fake package with a name that looks almost like a real one (for example, swapping two letters). It depends on users making a typo and installing the wrong package by accident.
- Slopsquatting, on the other hand, doesn’t wait for a typo. Instead, it relies on an LLM hallucination, when an AI suggests a package name that doesn’t actually exist. Attackers then register that fake name and fill it with harmful code.
Here’s what makes it dangerous:
- Developers using AI tools often copy and paste code directly into their projects.
- If that code includes a fake package name, and the attacker has already uploaded a malicious version, it can slip into the project without anyone noticing.
This tactic is especially worrying because it doesn’t rely on human error – it relies on misplaced trust in the tool itself. The attacker doesn’t need to trick the user. They just need to stay one step ahead by watching for hallucinated names and claiming them first.
So while typosquatting is about catching people off guard, slopsquatting is about turning the weaknesses of AI coding tools into an open door. And right now, that door is wide open.
Hallucinations in AI Code: A New Attack Surface
A recent study tested 16 different code-generating LLMs across Python and JavaScript. What they found was eye-opening:
- Around 19.7% of all package names generated were completely made up.
- For open-source models, the average was even higher – 21.7%.
- One model, CodeLlama 7B, had a hallucination rate of 35.7% on JavaScript tasks.
- In total, the researchers found 205,474 unique hallucinated package names across 576,000 completions.
Here’s why that matters: each of those fake package names could be picked up by someone with bad intentions. Once registered in public repositories like npm or PyPI, they’re no longer just hallucinations. They become real and dangerous.
And the issue isn’t random either. The study showed that LLM hallucination is often consistent:
- 43% of hallucinated packages showed up in all 10 repeated prompts.
- 58% appeared more than once, even when the questions were slightly changed.
- Many hallucinated names weren’t even close to real ones – almost half had spelling differences of six or more characters.
That means developers using AI coding tools might see the same fake packages come up again and again. And unless they check closely, they might end up installing something harmful without even realising it.
LLM Hallucination Rates: Which Models Are Most at Risk?
Not all large language models hallucinate equally.
In a recent study, researchers tested 16 popular models on their ability to generate code in Python and JavaScript. The results showed a clear pattern: commercial models like GPT-4 Turbo made fewer mistakes, while open-source models had much higher rates of hallucinated package names.
Let’s take Python as the first example:
- GPT-4 Turbo hallucinated only about 3.6% of the time, and GPT-4 followed close behind at just over 4%. GPT-3.5 Turbo also kept its rate under 6%.
- But many open-source tools struggled. Models like WizardCoder, DeepSeek, and CodeLlama had hallucination rates between 14% and 26%.
- The worst performer was CodeLlama 7B, which hallucinated more than a quarter of the time.
Things got even more extreme in JavaScript:
- While GPT-4 Turbo still kept its hallucination rate low, around 4%, CodeLlama 7B hallucinated in more than 35% of its outputs.
- Other open-source models like MagiCoder and DeepSeek weren’t far behind, often generating fake packages at rates above 20%.
So why does this happen? Researchers found that LLM hallucination is linked to a few specific factors:
- Higher temperature settings lead to more randomness, which increases errors.
- Longer code completions give models more chances to make things up.
- And while larger models sometimes help, size alone isn’t a guarantee of better accuracy.
Why Traditional Filters Can’t Stop Slopsquatting
Filtering fake package names isn’t enough, especially if they’re published.
Why don’t traditional filters catch this?
- Hallucinated names aren’t obvious fakes: Nearly half of the hallucinated package names (48.6% to be exact) were nothing like any real package name. They weren’t simple typos. In fact, the average difference (measured by Levenshtein distance) was more than six characters, meaning that traditional filters, which look for close matches or small spelling errors, are likely to miss them completely.
- Reactive tools work too late: They can only stop packages once they’ve already been published, not before.
- The threat is entirely new: Hallucinations in AI produce packages that don’t copy, they create. That’s why tools designed for older attacks aren’t enough anymore.
In short, slopsquatting avoids the usual red flags. It turns AI-generated fiction into a real threat, and by the time it’s noticed, someone might’ve already installed it.
Mitigation Techniques That Actually Reduce AI Hallucinations
If traditional filters aren’t working, what can we do? Researchers tested a few approaches to reduce generative AI hallucinations, and the good news is they saw real improvements.
Let’s look at what helped most:
Together, these methods offer a practical way forward. Each one improves how AI coding tools work, and combining them gives the best results. While there’s no perfect fix yet, using strategies like RAG and refinement makes it much harder for generative AI hallucinations to slip through.
The Bottom Line
Slopsquatting is a growing security risk that hides in plain sight. Instead of waiting for human error, it takes advantage of AI hallucinations when coding tools suggest package names that don’t exist. Attackers register these names before anyone notices, turning code suggestions into real threats.
Since traditional filters often miss them, developers need better safeguards and smarter tools to stop these fake packages before they spread.
