Slopsquatting: New AI Hallucination Threats & Mitigation Strategies

Summary

Slopsquatting is an emerging software supply-chain threat in which attackers weaponize recurring large language model (LLM) package hallucinations. Because coding assistants repeatedly invent the same plausible-but-nonexistent dependency names, attackers can pre-register those names on public registries such as npm and PyPI and wait for developers to install them. Recent research found that 19.7% of packages generated across tested LLMs were hallucinated, and that 43 percent of repeated prompts produced the same hallucinated name on every run.^{[1][2][7][8][10]}

This Snyk-sourced interview and article frame slopsquatting as a low-cost attack that requires no maintainer compromise, no build-server poisoning, and no vulnerability discovery — the attacker simply observes model output, registers the name, and waits. The technique maps to MITRE ATT&CK T1195.001. The piece cites real supporting incidents, including the Aug. 4 keyv compromise and Anthropic's July 30 disclosure of a model referencing a nonexistent PyPI package that an attacker registered and weaponized.^[1][2][11]

The core guidance is that verification of AI-suggested dependencies must be automated and independent of the model, executed inside developer tooling at the moment a package is proposed and at the installation path — checking maintenance activity, provenance, adoption and known-malicious behavior — rather than relying on manual human review or on code detonation, which itself becomes an attack surface.^[1]

Attack chain

1. Observe hallucinations: Attackers monitor AI code-generation output across popular assistants to identify frequently and consistently hallucinated package names; because 43% of repeated prompts reproduce the same fabricated name, the namespace is predictable.^[1][2][10]
2. Pre-register the namespace: Attackers register the hallucinated package name on npm, PyPI or similar repositories at no cost, with no maintainer to compromise; the package appears clean because it is brand new.^[1][2]
3. Developer or agent trusts and installs: A developer (or an autonomous agent that resolves and installs dependencies) accepts the AI-recommended package without verification, pulling the attacker-controlled package into the codebase.^[1][2]
4. Execution: The malicious package executes when installed or run; secondary execution paths such as planted .claude and .vscode config files (as seen in the keyv compromise) can fire the moment a project is opened, with no install required.^[1][11]
5. Induced hallucination (evolution): Rather than merely observing hallucinations, attackers seed tutorials, sample repos and forum answers that models train on, so an already-registered attacker-owned name becomes the statistically obvious suggestion.^[1]

Disclosure timeline

How it works

Slopsquatting exploits the fact that LLM package hallucinations are systematic and repeatable rather than random. When developers ask an assistant for help, it frequently suggests realistic-sounding packages that do not exist (e.g., 'jwt-secure-validator', 'aws-helper-sdk', 'fastapi-middleware'). Because the same fabricated names recur across runs (43% reproduced on every one of ten repeats), attackers can register those names in advance on npm or PyPI and wait for installation.^{[1][2][7][10]}

The attack succeeds by exploiting developer trust in AI recommendations and the absence of automated validation. Registration is free, requires no maintainer compromise or vulnerability, and the malicious package looks clean because it is new. Models also resurrect real but dormant packages — nearly 90% of the open-source ecosystem (about 6.3 million abandoned forks) shows zero CVEs simply because nobody has examined them. Attack surface expands to any name-addressed unit of trust in agentic development, including MCP servers, skills, tools and config files, with config files (as in keyv) executing on project open.^[1]

Key takeaways

• Slopsquatting turns predictable, repeatable LLM package hallucinations into a pre-registerable namespace, making it a cheap supply-chain attack that needs no maintainer compromise or vulnerability — only that the developer be right about everything except the one unverified package name.^[1]
• Verification must be independent of the generating model, automated, and applied at the moment of package selection and at the installation path — not via manual review queues or code detonation, which itself leaks credentials.^[1]
• The threat expands beyond packages to any name-addressed unit of trust in agentic development (MCP servers, skills, tools, config files), and as agents remove the human who once at least saw the package name, the review point that catches slopsquatting is being engineered out.^[1]

Defensive actions

• Run automated dependency health checks at the moment a model proposes a package, inside the developer's own tools, rather than as a manual review bolted on afterward.: The generator cannot be the validator; asking the model that proposed a package whether it is safe re-asks the same system the same question. Checks against maintenance activity, provenance, adoption and known-malicious behavior at the point of decision catch slopsquatted packages before install.^[1]
• Enforce policy at the installation path via a proxy governing npm and PyPI pulls, blocking anything under a published malware advisory and imposing a cooling-off period on new releases.: Slopsquatted packages are new by definition, so a cooling-off period on newly published releases and blocking advisory-flagged packages directly counters the technique without adding review-queue delay.^[1]
• Treat 'package not found' as a security signal and give any new, unfamiliar AI-suggested dependency the same scrutiny as any other unknown dependency.: AI assistants suggest nonexistent or dormant packages; treating a missing package as suspicious catches hallucinated names before an attacker's registration is trusted.^[1]
• Do not verify packages by executing (detonating) them; use static examination instead.: Anthropic's disclosure showed a security vendor's scanner that installs and runs packages to test them executed attacker malware within an hour, exposing that vendor's credentials — detonation-based verification is an attack surface, not a defense.^[1]
• Keep humans in oversight roles setting policy and monitoring behavior, using independent (potentially AI-powered) validation rather than approving every action or trusting AI to check its own work.: Requiring a human to approve every action does not scale at machine speed, but blind trust in AI is what created the exposure; independent validation with clear policy and human oversight is the balance advocated.^[1]