Slopsquatting is the emerging supply chain threat that treats an AI coding assistant’s “hallucination” like a gift wrap for attackers. Instead of just misspelling a real package name the way traditional typosquatting does, attackers exploit LLM behavior to generate fictitious software package names that sound plausible. Then they register those exact names and populate them with malware, so the “helpful” dependency gets pulled into a developer’s codebase during normal development workflows.

The stakes are immediate for anyone building software with AI assistance. The threat model changes because the registry defenses built for typosquatting often assume the attack will look like a simple lookalike of an existing library. In the slopsquatting world, the attacker is not squatting a known name. They are betting that the model will invent something new but believable, and that developers will trust the model’s output enough to install it.

To understand why this is different, start with the definition. The term “slopsquatting” combines “AI slop” with “typosquatting.” Typosquatting is a long-running practice where attackers register misspelled or lookalike versions of popular domains or packages to prey on human mistakes. Registries have spent years building protections against this style of deception.

Slopsquatting uses large language model hallucinations to inject malicious code into development workflows. During AI-assisted coding, models may generate fake open-source packages, meaning bundled collections of files, programs, and installation tools that do not actually exist. On their own, hallucinated names are not automatically harmful. The harm arrives when a threat actor registers that fake package name. If the developer then installs or incorporates it, malicious code can be pulled directly into production-facing software.

This also helps explain why detection is hard and why compromise can linger. The article notes that even if many LLMs recommend the same hallucinated package, widespread compromise is still possible. Malicious packages could remain undetected in production for months or even years, allowing threat actors to inject malware across countless environments. One research team analyzed 31,267 vulnerabilities across 14,675 packages in 10 programming languages, finding reported vulnerabilities increasing at an annual rate of 98%. That growth rate was faster than the 25% annual increase in the number of open-source software packages. The same team observed an 85% increase in the average lifespan of vulnerabilities, suggesting security was declining rather than improving.

Now connect that to what AI changes in practice. Traditional protections may cover obvious typos, but they are less prepared for packages that the model invented in the first place. The source gives a concrete example: a registry would protect against an attacker publishing “crossenv,” a squat of the popular “cross-env” package. But it would likely not identify “mpn install cross-env file” or “cross-env-extended” as threats, because those are not simple misspellings of known libraries.

So why are LLMs hallucinating packages in the first place? The article points to how LLMs generate statistically likely answers rather than prioritizing accuracy. Hallucinations are common, and the rates can vary dramatically depending on the model and prompting approach. One study found hallucination rates range from 50% to 82%. Even GPT-4o, described as a best-performing model, goes no lower than 23% even with prompt-based mitigation. That means “just be careful with prompts” is not enough, because the failure mode is baked into how the system produces likely output.

Threat actors can also make hallucinations worse. The source notes that adversarial hallucination attacks could worsen this problem through techniques like token-level manipulation or retrieval poisoning, aiming to force models to hallucinate in specific ways that increase the probability of recommending malicious packages. In other words, the attacker is not only betting on randomness. They can influence the model’s behavior.

Not all models have equal exposure. The article states that proprietary models are four times less likely to generate hallucinated packages than open-source models. This is supported by research that conducted 30 tests across 30 different systems, producing 576,000 code samples and 2.23 million packages, with 19.7% hallucinations overall. It also reports model-specific hallucination rates: GPT-4.0 Turbo at 3.59% and DeepSeek 1B at 13.63%. The practical implication for decision-makers is straightforward: organizations relying on open-source AI tools for code generation may be roughly four times more exposed to slopsquatting attacks. And the article adds a caveat that matters for procurement and security planning: once attackers learn that disparity, they may try to manipulate proprietary LLMs to take advantage of perceived safety.

Then there is “vibe coding,” which turns theory into an operational risk. Developers using AI tools estimate that over 40 percent of the code they commit includes AI assistance, and that share is expected to increase. The article also says 72% of users who tried AI use it daily. When large portions of code come from AI-assisted workflows and verification processes are inconsistent, the threat surface expands.

What should executives and boards take from this? The core message is that you cannot treat AI-generated dependencies like a benign productivity boost. The source recommends double-checking output, including verifying that recommended packages exist in official repositories before incorporating them into projects. It also suggests automated checks that validate package names against known registries, plus monitoring unusual package installations and maintaining up-to-date threat intelligence on known slopsquatting campaigns. Slopsquatting sits at the intersection of software supply chain risk and AI reliability, which means it can spread quickly through modern development teams that are moving fast and trusting tools by default.

For leaders, the second-order stakes are about governance. If your organization accelerates delivery by embedding AI coding assistants, you also need controls that understand AI’s specific failure mode: plausible but nonexistent dependencies. The advantage goes to teams that treat AI output as untrusted input until proven real, not as a shortcut that bypasses security hygiene.