Slopsquatting represents an emerging supply chain threat made possible by AI hallucinations. As developers increasingly rely on AI coding assistants, they unknowingly grant cybercriminals access to your software from day one.
Understanding what slopsquatting is
Slopsquatting is a new type of supply chain attack that uses a large language model (LLM) hallucinations to inject malicious code in development workflows. The term combines "pending AI" and "write squat," a deceptive practice in which attackers register misspelled or similar versions of popular domains to take advantage of users who enter URLs incorrectly.
This novel attack vector exploits the tendency of LLMs to generate fictitious software package names, which threat actors can then record and populate with malicious code.
During AI-assisted coding, the model can generate fake open source packages: packaged collections of files, programs, and installation tools. This alone is not necessarily harmful. However, if an attacker registers that fake package name, they can inject malware that is incorporated directly into the developer’s code base.
How AI creates supply chain risk
Traditionally, AI Safety risks come from hallucinations.which can negatively affect users who consider misinformation valid. However, those same hallucinations have become exploitable security vulnerabilities.
Typosquatting is a deceptive practice in which a cybercriminal registers a poorly written version of a popular package to trick developers. It’s been around for decades, so registries have created protections against it.
However, AI has changed the threat model. Recommends dummy packages that look plausible rather than simple spelling errors. Once attackers learn what crazy package models they tend to invent, they can register malware-filled packages with those names.
Since hallucinated packages are not simply typed versions of popular libraries, there are no protections against this large-scale practice. For example, logging protects against an attacker publishing "crossed," a popular squat "cross environment" package. However, I would not identify "mpn install cross-env file" either "cross-env-extended" as threats.
The hallucinations are persistent and severe.
Even if many LLMs recommend the same mind-blowing package, widespread compromise is still possible. Malicious packages could go undetected in production for months or even years, allowing threat actors to passively inject malware into countless environments.
an investigation The team analyzed 31,267 vulnerabilities. belonging to 14,675 packages in 10 programming languages. They found that reported vulnerabilities are increasing at an annual rate of 98%, faster growth than the 25% annual increase in the number of open source software packages. The team also observed an 85% increase in the average lifetime of vulnerabilities, indicating a decrease in security.
Real-world dangers of AI hallucinations
Malicious actors You can create open access packages with the same name as commonly used libraries. Instead of standard code, they are filled with malware. The models think they are referring to existing packages, so they often repeat the same hallucinated names. Since the hallucinations are not random, attackers could theoretically register packages that fool tens of thousands of developers.
These packages look legitimate. The similarity of strings to real libraries makes them recognizable. Single-character typos suggest simple errors rather than malicious intent. Even completely made-up names are still believable when the AI presents them in the right context. Detection is challenging as developers rely on their coding assistants to recommend valid dependencies.
Why do LLMs have hallucination packages?
LLMs generate the statistically most likely answer rather than prioritizing accuracy. As a result, hallucinations are relatively common. Study found rates of hallucinations range between 50% and 82%depending on the model and request method. Even GPT-4o, the best performing model, does not go below 23%, even with rapid mitigation.
Attacks of adverse hallucinations could make this problem worse. Threat actors can leverage token-level manipulation or recovery poisoning to force models to manipulate the way they want, increasing the likelihood that models will recommend their malicious packages.
Which LLMs are prone to slopsquatting?
While all LLMs are prone to slopsquatting, some are more vulnerable than others. The probability of producing hallucinated packets during code generation depends on the model. Proprietary models are four times less likely to produce amazing packages than open source models.
A research group demonstrated this by performing 30 tests on 30 different systems. Outside the 576,000 code samples and of the 2.23 million packages it produced, 19.7% were hallucinations. GPT-4.0 Turbo had a hallucination rate of 3.59%, while DeepSeek 1B, the best performing open source model, reached 13.63%.
This research suggests that organizations that rely on open source AI tools for code generation are approximately four times more exposed to slopsquatting attacks. However, that doesn’t necessarily mean that proprietary tools are always safer. Once attackers realize this disparity, they can manipulate proprietary LLMs to take advantage of perceived security.
Vibe coding contributes to the problem
Software developers who use artificial intelligence tools estimate that more than 40 percent of the code that they undertake includes AI assistance. They expect that percentage to increase considerably in the coming years. 72% of those who have tried AI already use it daily.
Increased vibration coding and AI-assisted coding amplifies the threat surface. As more developers integrate AI tools into their workflows without implementing proper verification processes, the attack surface for slopsquatting continues to expand.
For those using AI to help with coding, verifying the results is essential. Verifying that recommended packages actually exist in official repositories before incorporating them into projects reduces risk.
Navigating AI-assisted development
Implementing automated checks that validate package names against known records can help detect corrupted packages before they enter production code. Security teams should also monitor unusual package installations and maintain up-to-date threat intelligence on known slopsquatting campaigns.
Zac Amos is the features editor at Rehack.
