Slopsquatting

Slopsquatting is a software supply-chain attack in which an attacker publishes a malicious package under a name invented by an AI coding assistant, then relies on developers or automated tools to install it. The trap turns a plausible-sounding dependency recommendation into executable third-party code. It connects hallucinations in LLMs—fabricated information presented as factual—with the package managers used to build software.

Security researcher Seth Larson coined the term in April 2025, and Andrew Nesbitt popularized it through his original slopsquatting definition, crediting Larson. The name combines AI slop with "squatting," referring to claiming a software name that other people will seek.

How Slopsquatting Works#

A large language model generates code containing an invented package name or installation command. An attacker identifies that name and publishes a package under it on a registry such as PyPI or npm. When the recommendation appears again, installation retrieves the attacker's package. Package hallucinations can recur across prompts and models, concentrating demand on names attackers can claim.

The registry's state determines the outcome. An unregistered name produces an installation failure; an attacker-controlled name resolves successfully and introduces malicious code into the environment. The developer's trust in the assistant becomes a route into the software supply chain.

This risk reaches both human-assisted development and agentic coding. An AI agent with tool-use capabilities can turn a generated dependency into an installation action. Malicious package code can execute during installation or subsequent use, exposing files, credentials, and build outputs according to the environment's permissions.

How an Invented Package Reached Developers#

Bar Lanyado published an empty Python package named huggingface-cli after AI models recommended that nonexistent dependency. By March 28, 2024, the hallucinated package had received more than 30,000 authentic downloads over three months. Installation instructions also appeared in an Alibaba research repository's README. The empty package's adoption demonstrated that an invented dependency name could reach real development workflows.

Package naming adds another source of confusion: a command-line executable, an importable module, and an installable distribution can have different names. This matters in computer vision development when assistants generate environment setup instructions. Ultralytics YOLO supports YOLO26 through the ultralytics Python package, which provides training, prediction, and export workflows; checking generated installation instructions against that package identity addresses the dependency-selection stage where slopsquatting enters.

Slopsquatting and Related Attacks#

These terms describe distinct mechanisms that affect dependency security:

• Package hallucination: The model invents a dependency. Slopsquatting weaponizes that naming error through adversarial registration.
• Typosquatting: An attacker registers a name resembling an existing package to capture spelling mistakes. Slopsquatting targets names generated by AI.
• Dependency confusion: A package manager retrieves a public package when a private dependency was intended.
• Prompt injection: Attacker-controlled content redirects an AI system's behavior. Slopsquatting exploits a generated package recommendation through the registry.

Preventing Slopsquatting in Build Pipelines#

Dependency approval establishes the intended project, publisher, source repository, and release history before installation. Security-focused dependency review applies to AI-generated additions just as it applies to human-written code. Registry availability establishes that a name exists; checking its ownership establishes whose software will run. Grounding an assistant in approved package documentation supplies package identities for this review.

In continuous integration, review gates control dependency changes before they enter a build. Pinned versions identify approved releases, while artifact hashes identify their exact files. Agent sandboxing, restricted network access, and least-privilege credentials limit the resources available to dependency code, reducing its access to sensitive data and deployment credentials.

Python's hash-checking installation mode uses --require-hashes to check downloaded package files against hashes recorded in a requirements file. Every dependency, including transitive dependencies—the libraries required by other libraries—must have an exact version and permitted artifact hashes. When a downloaded package's hash differs from every permitted hash, pip rejects the file and stops installation.