Slopsquatting: Building a Scanner That Catches AI-Hallucinated Packages Before They Reach Production

In this article, I will examine an emerging security problem in AI-assisted development: slopsquatting, a supply-chain attack that exploits hallucinated software package names generated by large language models.

As developers increasingly rely on AI coding assistants to accelerate development, hallucinated dependencies can slip into real projects. Attackers can register those phantom package names in public registries and distribute malicious code through them.

The article will introduce a practical defense mechanism, an open-source dependency scanner that I developed to detect potentially hallucinated or suspicious packages before they are installed. The goal is to move the conversation from awareness of the risk to practical mitigation that developers can implement today.

When AI Starts Inventing Dependencies

AI coding assistants have become a routine part of modern development workflows. Tools capable of generating boilerplate code, configuration files, and dependency lists are now widely used by developers to speed up prototyping and development.

However, these tools sometimes generate package names that do not actually exist. Research has shown that code-generating language models frequently hallucinate dependencies when producing code examples.

These hallucinations create a new attack surface: if a developer copies and installs the suggested dependency, an attacker who has registered that package name can distribute malicious code through it. 

This emerging attack pattern is known as slopsquatting, a form of cybersquatting that exploits AI-generated package hallucinations. I will frame this as a new category of software supply-chain risk introduced by AI-assisted development.

What Slopsquatting Looks Like in Practice

I will explain the mechanics of a slopsquatting attack. The typical sequence is straightforward:

1. A developer asks an AI assistant to generate code.
2. The model produces code that references a package that does not exist.
3. An attacker registers that package name in a public repository.
4. The developer installs the dependency, unknowingly executing malicious code.

Unlike typosquatting, which relies on human spelling errors, slopsquatting exploits AI hallucinations.

Because LLMs generate plausible-sounding library names, the resulting dependencies can appear legitimate to developers who trust the generated code.

Why AI Coding Assistants Amplify the Risk

AI assistants are designed to generate convincing outputs even when they are incorrect. In code generation tasks, this often results in package names that appear realistic but do not exist.

The problem is amplified by the speed of AI-assisted workflows. Developers may paste generated code directly into projects without manually verifying each dependency.

As a result, phantom packages can enter codebases surprisingly easily.

This section will also connect the issue to a broader problem in dependency management: every new dependency introduces additional maintenance and security risk; something I previously explored when discussing the hidden costs of third-party libraries.

Dependency Attacks Are Already a Major Problem

To provide context, I will briefly discuss how software supply-chain attacks increasingly target dependency ecosystems such as npm and PyPI.

Modern applications often rely on dozens, sometimes hundreds, of external packages. Each dependency introduces another potential attack vector.

Recent research into package hallucinations demonstrates that these errors occur across many code-generation models and can produce thousands of unique hallucinated package names. This means attackers have a large and constantly evolving set of potential targets.

Building a Tool to Detect Slopsquatted Packages

I will now introduce a tool I built to detect these risks automatically.

The tool is an open-source CLI utility and GitHub Action designed to scan dependency files and identify packages that may be hallucinated or suspicious. It supports common dependency formats, including:

• package.json
• requirements.txt
• go.mod

For each dependency, the scanner verifies whether the package exists in the relevant registry and evaluates its metadata. The objective is simple: detect suspicious dependencies before they are installed.

Detection Strategy and Heuristics

The detection process includes several signals:

• Registry validation. The tool checks whether the package exists in official registries such as npm or PyPI.
• Package age and adoption metrics. Packages that are extremely new and have minimal downloads may indicate opportunistic registrations.
• Naming pattern analysis. LLM-generated dependencies often follow recognizable naming patterns; generic compound names that resemble legitimate utility libraries.
• Community blocklists. The scanner also compares packages against a curated dataset of hallucinated package names collected from research and community reports.
• These checks help identify packages that match common characteristics of slopsquatting attacks.

The False Positive Problem

Any automated detection system must balance security with developer productivity.

Some legitimate packages may appear suspicious simply because they are newly published or used by a niche community.

For this reason, the scanner uses a risk-scoring approach rather than strict blocking rules. Developers can review flagged dependencies and decide whether they should be installed.

This design keeps the tool practical for real development workflows.

Integrating the Scanner Into CI/CD Pipelines

The tool can run automatically whenever a pull request is opened or a build pipeline starts.

If a suspicious dependency is detected, the pipeline can notify developers or pause the installation step until the package is reviewed.

This introduces a pre-installation security checkpoint in the development workflow.

Testing the Scanner on AI-Generated Projects

To illustrate the problem, I will describe running the scanner on several repositories that relied heavily on AI-generated code.

In these experiments, the scanner identified dependencies that showed patterns consistent with hallucinated packages. The results demonstrate how easily phantom dependencies can appear in real projects when AI assistants are involved.

What This Means for AI-Assisted Development

AI assistants are rapidly becoming core tools for developers. At the same time, attackers are adapting their strategies to exploit weaknesses introduced by automated code generation.

Developers should treat AI-generated output the same way they treat any external input, it must be verified before being trusted.

Security tools designed to detect AI-specific risks, such as hallucinated dependencies, will likely become an essential part of modern software development practices.