What is slopsquatting? How AI package hallucinations become attacks

Slopsquatting is a software supply-chain attack that begins with an AI model inventing a package name. If developers repeatedly receive the same plausible suggestion, an attacker can publish a malicious package under that name and wait for someone to install it.

The danger is easy to miss because nothing looks obviously broken. The package may exist. The registry may serve it normally. The code may import cleanly. The problem is that the package became “real” only after a model hallucinated it.

How the attack works

1. A developer asks a model to solve a programming problem.
2. The model recommends a package with a credible but nonexistent name.
3. The same hallucinated name appears often enough to be predictable.
4. An attacker registers that package name in a public registry.
5. The package contains malicious install behaviour or runtime code.
6. A later developer follows the model’s suggestion and installs it.

This differs from classic typosquatting. The victim did not mistype a known package. The model supplied the attacker’s chosen name correctly.

Why package hallucinations are exploitable

Hallucinated package names are not always random. Models learn naming conventions and may repeat the same plausible combination across similar prompts. That repeatability gives attackers something to target.

A large USENIX Security study evaluated 16 code-generation models across 576,000 samples. The researchers reported package hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models in their experiments. They identified 205,474 unique hallucinated package names.

The exact rate will vary by model, ecosystem and prompt. The operational lesson is stable: generated dependency names require verification before installation.

What a slopsquatting package can do

A package may execute code during installation, import or application runtime. Depending on the developer environment, it could:

• Read environment variables and local credential files
• Modify shell profiles or persistent agent instructions
• Download a second-stage payload
• Steal source code or private package tokens
• Alter build output before deployment
• Open a reverse shell or establish persistence

Development machines are valuable targets because they often have source access, registry credentials, cloud CLIs and signing tools in one place.

How to verify an AI-suggested package

1. Find the official project independently

Do not trust the model’s link or installation command. Search the ecosystem documentation and registry. Confirm the repository, publisher and project website agree.

2. Check age and release history

A package published yesterday with one version deserves more scrutiny than a maintained project with years of releases. Age is not proof of safety, but a mismatch between the model’s confidence and the package’s short history is a strong signal.

3. Inspect ownership

Compare the registry publisher with maintainers named by the project. Look for recent ownership transfers and newly added publishers. Compromise of a legitimate project is a separate supply-chain risk.

4. Review install behaviour

Inspect lifecycle scripts, native binaries and remote downloads. Ask whether the package needs those capabilities for its stated purpose. A formatting helper should not need to collect environment variables or start a background process.

5. Compare the package with established alternatives

Search official framework documentation and reputable repositories for the normal solution. Hallucinated names often resemble real packages or combine familiar terms in an unfamiliar way.

6. Pin the reviewed artifact

Use a lockfile, digest or exact version. Re-run checks when the resolved artifact changes. Approval of a package name should not grant permanent trust to every future release.

Detection signals worth combining

Signal	Why it matters
Name similarity	Finds typosquatting and names designed to resemble popular packages
Registry existence	Separates nonexistent suggestions from installable artifacts
Package age	Highlights names registered after model recommendations became common
Publisher history	Reveals new or unexpected ownership
Repository provenance	Checks whether code, releases and registry metadata align
Install scripts	Surfaces code that executes before normal use
Dependency graph	Shows what the package brings in transitively
Local context	Explains whether the package is expected for this framework and task

No one signal is decisive. New legitimate packages exist. Old packages can be compromised. A strong decision combines provenance, behaviour and repository context.

Where ordinary vulnerability scanning falls short

A CVE scanner answers whether a known version has a known vulnerability. A slopsquatting package can be malicious from its first release and have no published advisory. The security decision must happen before vulnerability history exists.

Use several layers:

• Registry and provenance checks before installation
• Malware and install-script analysis
• Known-vulnerability scanning after resolution
• Lockfile monitoring for unexpected changes
• Runtime containment for package installation and execution
• Human review when evidence conflicts

Policies teams can adopt immediately

1. Require justification for every new direct dependency.
2. Block nonexistent package suggestions from automated installation.
3. Escalate newly published packages and unexpected publishers.
4. Require lockfile changes in the same review as manifest changes.
5. Disallow unreviewed lifecycle scripts in sensitive build environments.
6. Record whether a dependency was suggested by an agent.
7. Continuously re-evaluate provenance after ownership or artifact changes.

The same principles extend beyond package registries. An agent can invent a Docker image, GitHub Action, MCP server, plugin or skill. Every new component should earn trust through evidence rather than inherit it from the model’s confidence.