Slopsquatting: When AI Hallucinates Package Names and Attackers Move In

TL;DR

• Slopsquatting is a software supply chain attack in which an attacker registers a package name that AI coding assistants hallucinate, causing developers who accept the suggestion to install malicious code.
• In a USENIX Security 2025 study, at least 5.2% of packages suggested by commercial models and 21.7% by open-source models did not exist.
• Slopsquatting is similar to typosquatting, but exploits the tendency of LLMs to confidently output fictitious package names that resemble legitimate packages, with a level of consistency and predictability. 
• Slopsquatting has been proven to be practical and effective. Malicious packages can be difficult to detect, and may persist in public repositories long enough to be downloaded thousands of times. Once in your supply chain, they can persist in caches, development environments, CI/CD, and production.
• AI is safe to use provided you secure your software development lifecycle (SDLC). The OX AI-native application protection platform (AINAPP) provides protection against slopsquatting by securing every stage in the development process, including a multi-dependency graph that helps developers track and understand the dependencies in their software stack.

The effectiveness of AI coding has now been proven in the field, is being widely adopted, and developers who don’t use it are missing out on great efficiency and productivity gains. However, it introduces unique challenges that are not yet fully recognized or addressed by many developers. ‘Slopsquatting’ is one of these novel threats that allows attackers to slip malicious code into your software products, affecting both you and your users.

This guide details what developers and AppSec engineers need to do to protect the software supply chain from slopsquatting.

What Is Slopsquatting?

Slopsquatting is a software supply chain attack in which an attacker registers a package name that AI coding assistants hallucinate, causing developers who accept the suggestion to install malicious code

Here’s how slopsquatting works in practice:

1. You generate code using AI tools, including dependency package names (e.g., for NPM, PyPI)
2. Your AI assistant gets a package name wrong in a predictable way (e.g., mypackage-mypackage instead of developername-mypackage)
3. An attacker, having predicted that this could occur, has claimed mypackage-mypackage and seeded it with malicious code. The package may even be fully functional to help evade detection.
4. Your software supply chain is now compromised, along with any systems that execute the affected code.

This doesn’t just impact you; your users and their systems are also at risk. Guarding against slopsquatting is now a key requirement for securing your software supply chain.

Why Large Language Models (LLMs) are Hallucinating Package Names

Due to how the LLMs that power modern AI tools work, they do not accurately reproduce their training data, but create output derived from it. What ‘makes sense’ to them may not be correct, but it will be produced with absolute confidence. This includes package names, particularly newer packages that may not have strong training data or be in training datasets yet.

Just because a package name makes sense syntactically and refers to its purpose doesn’t mean it’s a real package. Hallucinated dependencies are one of the recurring risks of using AI-generated code, alongside insecure defaults and hardcoded secrets. Hallucinated package names are not random and are likely to be consistently reproduced, so attackers don’t have to guess them. They can use the same public models that you use and can prompt them with common software development tasks to see what package names they get wrong. 

Slopsquatting vs. Typosquatting

Slopsquatting is the AI-era form of typosquatting. Instead of relying on a developer to mistype a package name, it relies on an AI assistant to hallucinate one. An example of typosquatting would be a developer typing the package name imageresizrtool instead of imageresizertool (by not pressing the ‘e’ key all the way down on the third instance). 

The purpose and practical outcomes of slopsquatting and typosquatting are largely the same; however, slopsquatting presents additional ways for a package name to be consistently wrong. Beyond simple typos, package names can also be conflated or fabricated in multiple ways that may be hallucinated by an LLM.

The Real Impacts of Slopsquatting

The risk of slopsquatting to your software supply chain is not theoretical: cybersecurity researchers have demonstrated the practicality and effectiveness of slopsquatting attacks using the AI models and software repositories you rely on in your SDLC. According to a USENIX Security 2025 study, at least 5.2% of packages suggested by commercial models and 21.7% by open-source models were hallucinated, 205,474 unique names in total. Koi Security’s PhantomRaven campaign alone used 126 malicious npm packages with over 86,000 downloads. Malicious packages can continue to exist in public repositories, despite efforts to eliminate them. And, even once removed, they can live on in your local caches, undetected.

The security, privacy, and compliance impacts of this are obvious: it only takes one dependency containing malicious code to give an attacker access to systems and data.

There are also productivity impacts. If not properly understood, hallucinated package supply chain attacks undermine trust in AI-assisted development. While AI code cannot be assumed to be safe, unnecessary re-checking and rework of AI code slows down development and reduces its efficiency gains for your business. 

Slopsquatting Examples: The Campaigns That Made the News

One of the earliest publicly proven and documented incidents of slopsquatting is the fake huggingface-cli package on PyPI, which was downloaded over 30,000 times in three months before the researcher pulled it (thankfully, they were just testing the concept, and the package contained no code).

The unused-imports NPM package has also made the news. Don’t use it: it’s malware, part of Koi Security’s PhantomRaven campaign, but AI was suggesting it rather than the legitimate eslint-plugin-unused-imports.

Public awareness is increasing on the issue. For trust and compliance, you must demonstrate that your software supply chain is secure, whether from careless developer typos or AI hallucinations, or other sophisticated means of infiltration.

OX Security’s efforts to identify and combat software supply chain threats have made the news, too. The OX Research team recently discovered polymarket-kit, an impersonation package that is part of a multi-stage cryptocurrency theft and credential exfiltration campaign that also deployed a Remote Access Trojan (RAT). This kind of payload could easily ride a hallucinated name, and having this kind of malware surreptitiously downloaded as a dependency due to an AI hallucination could completely sink a major software project.  

Is AI Safe to Use in Development?

No practical development strategy, tools, or environment is totally risk-free. Whether you are hand-coding or using AI as an intuitive linter or for total vibe-coding, it’s still easy to overlook a single typo in a package name. To maintain control and security, you need to vet every dependency.

Slopsquatting and typosquatting can also affect the dependencies of your dependencies, and as AI continues to be widely adopted in development pipelines, keeping your supply chain 100% AI-free will become practically impossible. Instead, businesses are embracing the ability of AI to build complex projects from scratch, while ensuring they have full oversight of the security of all code used, whether written or generated in-house or by a third party. 

How to Defend Against Slopsquatting

Supply chain attacks, including slopsquatting, can be stopped at several stages in your SDLC. Auto-installed dependencies greatly increase the risk, but disabling them or requiring manual checks reduces the efficiency of AI-driven development processes.

• Cooldowns and Package Quarantining: Only allowing for the use of dependencies that have been published for a certain amount of time (giving security researchers a chance to vet them and have them pulled) prevents slopsquatting packages from being consumed, and also helps protect against zero-day attacks.
• Software Bill of Materials (SBOM) and Package Allow Lists: An SBOM makes dependencies visible and enables ownership and vetting. Limiting installations to only pre-approved packages and registries or your own private mirror also prevents malicious packages from making it into your supply chain. The OX dependency graph can be used to gain full insight into your dependencies (and their dependencies) without the need for complex infrastructure.
• Verification and Audits: IDEs, CI/CD pipelines, and production deployments must be protected. Signed packages should be verified, and all commits and running code should be audited for vulnerabilities using an application security platform.
• AI Agent Guardrails and Policy Enforcement: Develop your own policies that suit your needs, and enforce them with layered AI guardrails including permissions, system prompts, and restricted access to external software sources. Sandboxing test environments is also effective if malicious code does make it into your supply chain, preventing lateral movement and access to sensitive data.
• Version Pinning: This is generally good practice for securing dependencies, and helps combat your dependencies falling for a slopsquatting trap, preventing unvetted updates from introducing threats from further up the chain.

You should have an incident response plan in place, so that if you fall victim to a software supply chain attack, a planned, coordinated, and timely response can be made that meets data security and privacy compliance requirements.

How OX Secures Your Entire Software Supply Chain

Securing your SDLC from prompt to production requires an end-to-end AINAPP solution that maintains context and allows for correlation across all stages. Guardrails should be embedded into development workflows, and security tools should focus on exploitable risks and detect suspicious behaviour in your environment, rather than just focusing on CVEs. 

This provides additional protection against slopsquatting, typosquatting, and other supply chain attacks that can be difficult to detect and that can introduce malicious code that lies dormant in development, testing, and production environments. It also protects against unsafe patterns in generated code, and the uncontrolled agentic use of APIs, data, and other actions.

You should never assume that AI-generated code is safe, but you can make sure that it is safe. The AINAPP is the successor to the traditional ASPM tools that developers rely on for centralized application security, addressing the emerging concerns of AI-driven development and AI-powered attacks.

Security Risk	Traditional ASPM Controls	AINAPP Controls
Slopsquatting	Standard SCA scans, but lacking context, assume packages are real	OX VibeSec is built for AI-enabled development workflows and can detect AI-generated vulnerabilities and govern every AI user and process
Prompt injection	Not equipped to deal with this threat as it focuses on traditional development workflows	OX is embedded in your AI toolchain and governs from prompt input to prevent malicious instructions from reaching models
Sensitive data exposure, credential theft	Covers code, configurations, and dependencies, but does not account for agent-driven actions that can expose data	AI risk assessment and runtime monitoring that identifies security risks
Excessive agent autonomy and permissions	ASPM predates autonomous AI agents	Native features designed to directly address agent-specific risks with additional guardrails, controls, and monitoring

OX Code secures your supply chain with supply chain validation and PBOM, Software Composition Analysis (SCA) and SBOM, plus continuous monitoring.

Get the OX supply chain defense guide or contact us to learn more about how OX keeps you ahead of constantly evolving AI threats.