Forget typosquatting; slopsquatting is the software supply chain threat created by AI coding tools
Our take
The emergence of “slopsquatting” as a significant software supply chain threat underscores a critical and rapidly evolving vulnerability introduced by the widespread adoption of AI coding tools. This isn’t simply a refinement of existing risks like typosquatting; it represents a fundamental shift in how attackers can exploit the development process. As developers increasingly lean on AI assistants like those described in US cybersecurity agency CISA had to build its incident playbook during the incident, agency reveals, they inadvertently create new attack vectors that are far more difficult to detect than traditional typosquatting. The core issue isn’t just the generation of misspelled package names, but the creation of entirely fabricated ones that *sound* plausible and legitimate, fooling even experienced developers—a problem exacerbated by the increasing reliance on “vibe coding” and AI assistance, as detailed in the article about developers estimating that over 40 percent of the code they commit includes AI assistance. The accelerating pace of vulnerabilities, highlighted in the recent analysis of open-source packages, further emphasizes the urgency of addressing this new threat landscape.
The sophistication of the attack lies in the AI’s ability to hallucinate package names that are statistically likely and contextually relevant, making them far more convincing than simple typographical errors. Traditional defenses against typosquatting, which rely on registry protections and anomaly detection, are rendered largely ineffective against this new threat model. The fact that proprietary AI models are still less prone to generating these malicious suggestions, as demonstrated by the research comparing GPT-4.0 Turbo and DeepSeek 1B, offers a temporary reprieve but also highlights the potential for attackers to adapt and target those seemingly safer systems. Furthermore, the increasing prevalence of AI-assisted coding, with 72% of users reporting daily use, significantly expands the attack surface, making it essential for organizations to proactively implement preventative measures. It’s worth noting that even OpenAI is actively exploring new avenues for user engagement, as seen in OpenAI bets on families as ChatGPT goes deeper into households, which, while not directly related to security, underscores the broader integration of AI into daily workflows and the need for constant vigilance.
The implications of slopsquatting extend beyond immediate malware injection. The potential for long-term, passive compromise is particularly concerning, with malicious packages potentially remaining undetected in production environments for months or even years. This protracted exposure allows attackers to silently gather sensitive data or manipulate systems without immediate detection. Similarly, the financial and reputational damage resulting from a successful slopsquatting attack could be substantial, particularly for organizations that rely heavily on open-source software. The ease with which malicious actors can create seemingly legitimate packages, as demonstrated by the ability to mimic commonly hallucinated libraries with minor variations, further amplifies the risk and necessitates a fundamental shift in how developers approach dependency management and code verification. The issues raised by Phia’s accusations of “cookie stuffing,” as reported in Phia accused of ‘cookie stuffing,’ taking affiliate credit on purchases it didn’t earn, highlight a broader pattern of trust being misplaced in automated systems, reinforcing the critical need for human oversight and robust security practices.
Looking ahead, the challenge lies not only in detecting existing slopsquatting attacks but also in preventing them from occurring in the first place. Automated checks that validate package names against trusted registries are a crucial first step, but organizations must also prioritize developer education and foster a culture of security awareness. More sophisticated approaches, such as incorporating AI-powered threat intelligence into the development workflow and actively monitoring for anomalous package installations, will be essential. Ultimately, the rise of slopsquatting forces us to re-evaluate our assumptions about the trustworthiness of AI-generated code and to embrace a more proactive and skeptical approach to software development. The question now becomes: how can we adapt our development processes and security practices to effectively mitigate this emerging threat and maintain the integrity of the software supply chain in an increasingly AI-driven world?
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 their software from day one.
Understanding what slopsquatting is
Slopsquatting is a new type of supply chain attack that uses large language model (LLM) hallucinations to inject malicious code into development workflows. The term combines "AI slop" and "typosquatting," a deceptive practice where attackers register misspelled or lookalike versions of popular domains to prey on users who enter URLs incorrectly.
This novel attack vector exploits LLMs' tendency to generate fictitious software package names, which threat actors can then register and populate with malicious code.
During AI-assisted coding, the model may generate fake open-source packages — bundled 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 gets incorporated directly into a developer's codebase.
How AI creates a supply chain risk
Traditionally, AI safety risks stem from hallucinations, which can adversely affect users who treat misinformation as valid. However, those same hallucinations have evolved into exploitable security vulnerabilities.
Typosquatting is a deceptive practice where a cybercriminal registers a mispelled version of a popular package to trick developers. It has existed for decades, so registries have built protections against it.
However, AI has changed the threat model. It recommends fictitious packages that sound plausible rather than making simple misspellings. Once attackers learn which hallucinated packages models tend to invent, they can register malware-filled packages under those names.
Since the hallucinated packages are not simply typoed versions of popular libraries, there are no protections against this practice at scale. For example, the registry protects against an attacker publishing "crossenv," a squat of the popular "cross-env" package. However, it would not identify "mpn install cross-env file" or "cross-env-extended" as threats.
Hallucinations are persistent and severe
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 passively inject malware across countless environments.
One research team analyzed 31,267 vulnerabilities belonging to 14,675 packages across 10 programming languages. They discovered 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 lifespan of vulnerabilities, indicating a decline in security.
Real-world dangers of AI hallucinations
Malicious actors can create open-access packages under the same name as commonly hallucinated libraries. Instead of standard code, they are filled with malware. The models believe 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 trick tens of thousands of developers.
These packages appear legitimate. String similarity to real libraries makes them recognizable. One-character typos suggest simple mistakes rather than malicious intent. Even fully fabricated names remain believable when the AI presents them in proper context. Detection is challenging, as developers trust their coding assistants to recommend valid dependencies.
Why are LLMs hallucinating packages?
LLMs generate the statistically most likely answer rather than prioritizing accuracy. Hallucinations are relatively common as a result. One study found hallucination rates range from 50% to 82%, depending on the model and prompting method. Even GPT-4o, the best-performing model, goes no lower than 23%, even with prompt-based mitigation.
Adversarial hallucination attacks could worsen this problem. Threat actors can leverage token-level manipulation or retrieval poisoning to force models to hallucinate in ways they want, increasing the likelihood that models recommend their malicious packages.
Which LLMs are prone to slopsquatting?
While all LLMs are prone to slopsquatting, some are more vulnerable than others. The likelihood of producing hallucinated packages during code generation depends on the model. Proprietary models are four times less likely to generate hallucinated packages than open-source models.
One research group proved this by conducting 30 tests across 30 different systems. Out of the 576,000 code samples and 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 relying on open-source AI tools for code generation are roughly four times more exposed to slopsquatting attacks. That doesn’t necessarily mean proprietary tools will always remain safer, though. Once attackers realize this disparity, they may manipulate proprietary LLMs to take advantage of perceived safety.
Vibe coding contributes to the problem
Software developers who use AI tools estimate that over 40 percent of the code they commit includes AI assistance. They expect that percentage will increase considerably within the next few years. Already, 72% of those who have tried AI use it daily.
The uptick in vibe 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 assist with coding, double-checking output 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 registries can help catch hallucinated packages before they enter production code. Security teams should also monitor for unusual package installations and maintain up-to-date threat intelligence on known slopsquatting campaigns.
Zac Amos is the Features Editor at ReHack.
Read on the original site
Open the publisher's page for the full experience