AI hallucinations now enable 'slopsquatting' attacks, say security experts
Serge Bulaev
Security experts say AI tools sometimes invent fake package names, which attackers might quickly register to trick automated coding systems. These so-called "slopsquatting" attacks may allow bad actors to silently add malicious software when teams use AI to pick code dependencies. Tests in 2025 and 2026 show that many fake names created by AI were actually downloaded or used widely, even though they did not include harmful code. Experts suggest multiple security steps may reduce, but not fully stop, these risks. It remains unclear how often these attacks lead to real harm, since there is little direct evidence so far.

The threat of 'slopsquatting' attacks, fueled by AI hallucinations from large language models (LLMs), has become a practical reality. Security experts warn that this new form of supply chain poisoning exposes a critical blind spot in automated coding, as attackers register fake package names invented by AI to distribute malicious code. The attack pattern is straightforward: an LLM hallucinates a dependency, an attacker quickly registers it, and automated systems are silently compromised. Development teams using agentic tools to manage dependencies risk automatically pulling and installing malicious code disguised as a legitimate package.
Documented incidents, 2025-2026
Slopsquatting is a software supply chain attack where malicious actors register nonexistent package names that AI models have 'hallucinated.' When developers or automated tools use AI-generated code containing these names, they inadvertently download and install the malicious package, compromising their systems and software projects.
According to industry reports, a widely cited test involved a researcher registering the hallucinated PyPI package huggingface-cli. According to DevOps.com, the package received significant downloads from corporate networks within a short timeframe. Although it contained no malicious payload, the incident demonstrated how rapidly a fabricated dependency can infiltrate production environments.
Similarly, Aikido Security reported the hallucinated npm package react-codeshift had propagated to a significant number of public repositories before being registered. By claiming the name, Aikido highlighted the risk that threat actors could have easily done the same to distribute malware (Aikido Security).
Other potential slopsquatting examples identified by security vendors include unused-imports, aws-helper-sdk, and fastapi-middleware. While registration of these names doesn't confirm malicious intent, the pattern of opportunistic registrations following AI hallucinations suggests adversaries may be actively probing this attack surface.
Why hallucinations make ideal bait
The scale of this problem is significant. Academic studies of public LLMs have found they generate substantial numbers of unique, fictitious package names. A significant portion of the code samples produced by these models reference at least one nonexistent dependency. Because these hallucinations are often consistent and repeatable, attackers can predict them, monitor coding forums for new ones, and preemptively register them as malicious packages.
The risk is amplified in agentic workflows where AI assistants have permissions to automatically update project manifests and trigger CI/CD pipelines. A single hallucinated dependency committed to a repository can propagate rapidly through forks and mirrors, outpacing manual review and security checks.
Hardening the dependency path
Securing the software supply chain against slopsquatting requires a defense-in-depth strategy, as no single solution is foolproof. Experts recommend a combination of controls, including signed package provenance, strict registry curation, and dynamic software bills of materials (SBOMs). Key mitigation steps include:
- Use Private, Gated Registries: Enforce policies that require all external packages to be vetted through a private registry.
- Validate Signatures and Provenance: Mandate cryptographic signature and provenance checks before any package is used in a build or deployment.
- Pin and Lock Dependencies: Use lockfiles to pin exact package versions and prevent automatic, unreviewed upgrades.
- Enforce Least Privilege for AI Agents: Treat AI coding assistants as low-trust entities with minimal permissions and comprehensive audit trails.
- Isolate Runtimes: Run AI agents in sandboxed environments and implement kill switches to halt unexpected behavior.
While these measures can significantly reduce exposure to slopsquatting, security professionals emphasize that they do not eliminate the risk entirely. The goal is to introduce friction into the automated process, creating opportunities for human verification.
Open questions for the next audit cycle
To date, documented slopsquatting incidents have been preempted by security researchers who registered the hallucinated names before attackers could. However, it remains unknown how many malicious packages leveraging this technique already exist undetected. Security vendors report seeing upload patterns consistent with slopsquatting but often lack the direct evidence needed to link these packages to specific exploits. This highlights a critical visibility gap. The true impact of slopsquatting will remain unclear until organizations can effectively monitor for the use of hallucinated dependencies and correlate that data with malware intelligence.
What exactly is "slopsquatting" and how does it exploit AI hallucinations?
Slopsquatting is an emerging supply-chain attack where attackers register package names that large language models hallucinate during code generation. Once the name exists in a public registry, agentic build tools and CI pipelines silently install the malicious payload. The technique turns an AI's confident-but-wrong suggestion into a direct path for poisoning production systems.
Which documented incidents show the real-world impact?
Two early cases stand out:
- huggingface-cli - A researcher registered this hallucinated name after seeing it appear in multiple LLM outputs. Industry reports indicate the package recorded significant downloads from corporate IP ranges, proving that phantom dependencies attract real installs (source).
- react-codeshift - Aikido observed this nonexistent npm package had already propagated into a significant number of repositories via forks and translations before anyone claimed the name (source).
Secondary reporting cites additional high-risk names such as unused-imports, aws-helper-sdk, and fastapi-middleware that fit the same pattern.
How common are hallucinated package names?
Academic studies have examined generated code samples across popular LLMs and found:
- A significant portion referenced at least one nonexistent package
- Commercial models showed lower rates of hallucinated names compared to open-source models
- Many unique fictitious package names were produced overall (source)
These findings confirm that hallucinations are predictable and repeatable, which makes them reliable targets for attackers.
How can teams block slopsquatting inside agentic workflows?
Implement a defense-in-depth pipeline:
- Curated private registry - ingest every upstream package through an internal proxy that enforces policy
- Mandatory provenance & signing - require Sigstore or similar signatures before admission
- Lockfiles + version pinning - prevent silent upgrades of hallucinated or unreviewed packages
- Living SBOMs - continuously inventory what agents actually fetch and scan for new risk
- Least-privilege agent identities - treat every AI worker as an untrusted service account with appropriate security controls
What immediate steps should developers take today?
- Disable auto-install for any package suggested by an AI assistant
- Verify existence and authenticity in the official registry before each new dependency
- Add a human verification step in CI jobs that request packages not already on the approved list
- Subscribe to security advisories for the exact list of names above (
huggingface-cli,react-codeshift, etc.) and block them in firewall/gateway rules until proven safe