AI Hallucinations Spur Slopsquatting Threat for Software Supply Chains

Researchers say AI tools sometimes suggest fake software package names that sound real, and criminals may register these names to spread malware through automated build systems. This new risk, called slopsquatting, appears to be growing in 2025, but there have not yet been large confirmed attacks. Some experts warn that the threat is credible because automated systems might trust these fake packages without review. Security advice suggests using stricter controls like lockfiles, human approval, and monitoring for suspicious new packages. The risk is mostly theoretical right now, but researchers recommend acting early to prevent future problems.

A software supply chain threat, slopsquatting, is drawing attention as a consequence of AI-driven development. This attack vector exploits the tendency for Large Language Models (LLMs) to "hallucinate" nonexistent software packages. Attackers register these plausible-sounding package names on public repositories like npm and PyPI, laying a trap for automated build pipelines that can unknowingly ingest malware.

What is slopsquatting?

Slopsquatting is a supply-chain attack where threat actors register a package name that an AI model has hallucinated. Unlike classic typosquatting, which relies on human error, slopsquatting targets the predictable nature of AI hallucinations and the blind trust of automated pipelines that install anything an LLM recommends.

This attack vector is significant due to the high frequency of AI hallucinations. Research has found that a significant portion of AI-generated code snippets contain at least one hallucinated package name. Security analysis has framed the pattern as an emerging threat, giving attackers a large, machine-reproducible list of targets to poison.

Have there been large-scale slopsquatting incidents?

No widely confirmed, large-scale slopsquatting campaigns have been publicly documented in the wild. Security vendors emphasize that the threat is emerging but remains largely theoretical in production environments.

However, the vector is considered highly credible. Minor examples, such as the npm package @async-mutex/mutex, have been cited as proofs-of-concept. Furthermore, researchers have demonstrated that after pre-registering hallucinated names, they see immediate download attempts from automated build servers, indicating that some development teams already install AI-suggested packages without manual review.

How does a slopsquatting attack work?

Attackers turn an AI hallucination into a live malware delivery system through a simple but effective process, amplified by modern CI/CD pipelines:

AI Hallucination: An AI coding assistant suggests a plausible but nonexistent package (e.g., ultra-fast-json-parser).
Malicious Registration: An attacker, monitoring for such hallucinations, registers the ultra-fast-json-parser name on a public registry like PyPI or npm and uploads a trojanized version.
Automated Installation: A developer or CI/CD bot, trusting the AI's output, automatically runs a command like pip install ultra-fast-json-parser, pulling the malicious package into the environment.
Delayed Detection: Because the package name is what the system expected, the malware may be installed and executed before security scanners can react, creating a critical window of compromise.

What are the best practices for mitigating slopsquatting?

Security experts recommend a multi-layered defense strategy that combines traditional supply chain hygiene with governance for AI workflows. A consensus is forming around a seven-point checklist for development and security teams:

Pin and lock dependencies using exact versions in lockfiles (e.g., package-lock.json, poetry.lock) to prevent unexpected package resolution.
Require cryptographic signatures (e.g., via Sigstore) and verified provenance for any package before ingestion into a build.
Generate and review Software Bills of Materials (SBOMs) for every artifact, including models, datasets, and libraries.
Use allow-listed registries or internal mirrors, blocking direct pulls from public package indexes in automated pipelines.
Mandate human approval for any new dependency suggested by an AI agent or LLM before it is added to a project.
Continuously scan CI/CD pipelines for malicious packages, new CVE disclosures, and policy violations.
Apply the principle of least privilege to registry credentials, build runners, and the permissions granted to AI agents.

Can slopsquatting affect private or internal codebases?

Yes. Even organizations using closed-source code and internal LLMs are at risk. An enterprise copilot running inside a firewalled network might still hallucinate a package name that coincidentally matches an internal, private package.

If an attacker monitors public bug trackers or commit messages for these names, they can register the hallucinated name on a public registry. An internal build process that is improperly configured could then accidentally resolve and pull the malicious public package instead of the intended private one. Therefore, even closed-source shops must implement robust controls like lockfiles, signature verification, and registry allow-lists.

Outlook

Slopsquatting currently sits in a transitional phase: well-demonstrated in lab settings but not yet responsible for a reported mass exploit. However, the persistent rate of AI package hallucinations combined with the low barrier to abusing public registries creates a potent threat. Security researchers argue that defenders should act now to implement proactive controls rather than wait for the first high-profile compromise to validate the risk.