Slopsquatting turns AI coding hallucinations into malware supply chain access for attackers

Slopsquatting is the software supply chain threat hiding inside AI coding assistants. The core idea is brutally simple: when an LLM recommends a dependency that does not actually exist, a cybercriminal can register that exact fake package name and populate it with malware. Developers, trusting the AI to be helpful, can end up incorporating the attacker’s code directly into their codebase from day one.

This is not a theoretical “someday” problem. Slopsquatting takes inspiration from typosquatting, a decades-old trick where attackers register misspelled or lookalike versions of popular domains to catch users who type URLs incorrectly. But where typosquatting is constrained to small spelling mistakes that registries can often guard against, slopsquatting exploits a different failure mode: LLM hallucinations. The models generate plausible-sounding software package names that are not merely typoed versions of real libraries. That matters because protections tuned to spot common typos can miss the broader class of fabricated names.

To understand why this becomes an attack path, it helps to map the workflow. In AI-assisted coding, a model may output a “fake open-source package,” meaning a bundled collection of files, programs, and installation tools that looks like it belongs in the ecosystem. Alone, that recommendation is just bad information. The moment an attacker registers the hallucinated package name, the fake recommendation turns into an invitation. The attacker’s registered package can then contain malicious code, and the developer’s normal dependency installation process becomes the delivery mechanism.

The reason slopsquatting can scale is that LLM hallucinations are not random noise. They are statistically patterned. The source describes how the same hallucinated package names can be repeated across model outputs, especially when models “believe they are referring to existing packages.” Attackers can learn which names are likely to show up, then pre-position malware under those names. Classic registries may catch a squat like publishing “crossenv,” a misspelling of “cross-env.” But they may not identify variants such as “mpn install cross-env file” or “cross-env-extended,” because those are not simple typo equivalents. When the naming space is expanded from “misspelled library” to “plausible fabricated library,” the registry protections designed for typosquatting do not automatically transfer.

There is also a time dimension boards should care about. Malicious packages could remain undetected in production for months or even years. That creates a low-and-slow compromise model: the attacker’s injection lands early, then evades until it has already spread across countless environments. The source points to a study analyzing 31,267 vulnerabilities across 14,675 packages in 10 programming languages. It found reported vulnerabilities increasing at an annual rate of 98%, faster growth than the 25% annual increase in the number of open-source software packages. It also observed an 85% increase in the average lifespan of vulnerabilities, indicating a decline in security. Put together, slopsquatting arrives in an ecosystem where detection and remediation are already under pressure.

So why are LLMs hallucinating packages in the first place? The mechanism described is that LLMs generate the statistically most likely answer rather than prioritizing accuracy. That behavior produces hallucinations at meaningful rates. One study cited in the source reports hallucination rates ranging from 50% to 82% depending on the model and prompting method. Even GPT-4o, described as best-performing, does not go below 23% even with prompt-based mitigation. Adversarial tactics can worsen this. The source notes adversarial hallucination attacks using token-level manipulation or retrieval poisoning to push models into hallucinating in targeted ways, increasing the odds they recommend attacker-controlled package names.

Which tools are most exposed? The source highlights model differences that matter operationally. While “all LLMs are prone,” proprietary models are reported as four times less likely to generate hallucinated packages than open-source models. In one set of 30 tests across 30 different systems, the research produced 576,000 code samples and 2.23 million packages, with 19.7% being hallucinations overall. The hallucination rate for GPT-4.0 Turbo was 3.59%, while DeepSeek 1B reached 13.63%. That implies organizations using open-source AI tools for code generation could be roughly four times more exposed to slopsquatting. It does not guarantee proprietary tools are safe, because attackers could adapt once they learn about perceived safety gaps and attempt to manipulate proprietary LLMs in the same direction.

Finally, the “vibe coding” adoption wave makes the threat surface larger. The source states that over 40% of the code developers commit includes AI assistance, and that percentage is expected to increase considerably. It also says 72% of those who have tried AI use it daily. The second-order implication is clear: the more developers treat AI recommendations as ground truth, the more frequently attacker pre-positioned dependencies can be introduced. For execs and security leaders, verification becomes non-optional. The source recommends double-checking output by verifying recommended packages exist in official repositories before incorporating them into projects, using automated checks that validate package names against known registries, and monitoring unusual package installations. It also calls for maintaining up-to-date threat intelligence on known slopsquatting campaigns.

For boards and leadership teams, the strategic stakes are straightforward: slopsquatting shifts supply chain risk upstream into the coding assistant itself. If your development process is ingesting AI-generated dependencies without verification, you are effectively widening the front door to your software factory. In a world already tracking fast growth in reported vulnerabilities and declining security posture, this is the kind of “small” workflow change that can become a big operational failure. The companies that build guardrails around AI output now will spend less time cleaning up the malware they accidentally let in later.