Slopsquatting: How AI Package Attacks Work and How to Stop Them

Slopsquatting is a software supply-chain attack that starts when an AI coding tool invents a package name. An attacker registers that name in a public package registry and publishes malicious code. A developer or autonomous coding agent later accepts the same recommendation and installs it. The model's mistake has become an execution path.

Security researchers describe this as a form of package confusion created by code-generating models. Their attack model is simple: generate a plausible but nonexistent dependency name, claim that name in a registry, and wait for a later recommendation to send someone to the attacker's package. ¹

That definition matters. A package hallucination by itself is an accuracy failure. Slopsquatting requires a second act: someone claims the invented name and uses it as bait. Not every nonexistent package is malicious, and the published evidence does not show that every hallucination becomes a breach. It shows a repeatable attack surface.

What the research actually found

The strongest broad measurement comes from a 2025 USENIX Security paper that tested 16 code-generating models across Python and JavaScript. The researchers generated 576,000 code samples. In their test conditions, the average share of hallucinated package recommendations was at least 5.2% for commercial models and 21.7% for open-source models. They collected 205,474 unique nonexistent package names. ¹

Those numbers are serious, but their scope matters. They are measurements from a defined model set, prompt set, and experimental design. They are not a universal rate for every AI coding assistant, and they do not measure how many developers installed malicious packages. A blanket claim that "22% of all AI package suggestions are fake" overstates the evidence.

Package hallucination is also only one form of model error. Our broader guide to preventing LLM hallucinations covers why confident output still needs retrieval, validation, and an explicit failure path. Slopsquatting adds a sharper security consequence: the false answer names something a machine can install.

The five-step attack path

1. A model invents a dependency. The name sounds normal because it is assembled from familiar framework, task, and package naming patterns.
2. The name is available. No legitimate project owns that exact namespace in the registry the developer will query.
3. An attacker publishes under the name. The package can imitate the expected description while carrying unwanted behavior.
4. A human or agent accepts the recommendation. The install command is copied into a terminal, build file, or automated tool call without independent verification.
5. The package crosses the execution boundary. Installation, build hooks, imports, or later application use give the package an opportunity to run.

The final step is why this is not merely a documentation error. The pip maintainers state plainly that package installation involves running arbitrary code from distributions. Their secure-install guidance recommends hash checking and, where appropriate, refusing source distributions. ²

Slopsquatting is related to typosquatting and dependency confusion, but the initial signal is different. Typosquatting waits for a person to mistype a real name. Dependency confusion exploits how private and public namespaces are resolved. Slopsquatting starts with a model confidently creating demand for a name that had no legitimate package behind it.

Why autonomous coding raises the stakes

A developer who reads an answer may pause before installing a new dependency. An agent with shell access can collapse recommendation, selection, and installation into one run. The risky event is no longer a person typing a command; it can be a tool call made inside a larger plan.

That does not make multi-agent development inherently unsafe. It means authority has to be narrower than capability. An agent may be allowed to suggest a dependency without being allowed to install it, change a lockfile, or merge the resulting code. Our discussion of quality control for multi-agent systems makes the same distinction: independent output is useful only when evidence and approval gates survive the handoff.

A dependency intake gate that teams can use

The safest rule is straightforward: an AI recommendation can start dependency review, but it cannot complete dependency review. Every new direct dependency should produce an admission record before it reaches a shared environment.

new_dependency:
  requested_name: ""
  purpose: ""
  authoritative_registry_url: ""
  exact_version: ""
  source_repository: ""
  publisher_identity_matches: false
  provenance_or_attestation_checked: false
  lockfile_diff_reviewed: false
  hashes_or_signatures_verified: false
  isolated_install_passed: false
  security_review_owner: ""
  decision: "hold"

The fields force the reviewer to answer the questions that an install command hides:

1. Does the project exist in the intended registry? Check the exact normalized name on the authoritative registry. Existence is necessary, but it is not proof of legitimacy; an attacker can create the record you find.
2. Does the package identity make sense? Compare the registry publisher, linked source repository, organization, release history, documentation, and purpose. Do not substitute download count or a plausible README for ownership evidence.
3. Can you trace the artifact? npm provenance can link a release to its source commit and build workflow, and the npm CLI can verify registry signatures and attestations. npm also warns that provenance does not prove the code is benign. ³ PyPI makes the same boundary explicit: an attestation can show where a package came from, not whether you should trust it. ⁴
4. Is the dependency change visible in review? Put new dependencies through a pull request that shows the manifest and lockfile diff. GitHub's dependency review can surface newly added direct and transitive packages and known vulnerabilities before merge. ⁵
5. Is installation reproducible? Pin resolved versions. For Python, pip's hash-checking mode requires every dependency to be pinned and hashed, and its secure-install guidance supports binary-only installs when that fits the project. ² For npm, commit the lockfile and use the clean-install workflow in CI.
6. Can the first install fail safely? Test new dependencies in a disposable runner without production credentials. Review install scripts, built artifacts, and unexpected network or filesystem activity before the package enters a developer image or deployment pipeline.
7. Who owns the exception? Unknown publisher identity, missing provenance, or an unexplained package-name change should leave the decision on hold until a named reviewer accepts or rejects it.

Controls that look useful but are not enough

Asking the model whether the package is real. The same system can repeat or rationalize its first error. Verification has to leave the model and reach the registry, source repository, and build evidence.

Checking only whether the name now exists. Slopsquatting works precisely because an attacker can make the hallucinated name exist after observing it.

Using popularity as a pass/fail threshold. Download counts, stars, and package age can support an investigation, but fixed thresholds create false confidence and can penalize legitimate new projects.

Running a vulnerability scanner after installation. Known-vulnerability scanning is valuable, but a newly malicious package may have no advisory. Scanning complements identity, provenance, and review; it does not replace them.

Letting an agent install first and explain later. Once untrusted package code runs with credentials or network access, the important boundary has already been crossed.

Where AetherLab fits

AetherLab's connection to this topic is indirect: our systems assess AI behavior and enforce content policies, but they do not verify package ownership, inspect registry provenance, or secure a software build pipeline. Those controls remain with the engineering and security teams that own dependency intake. The shared principle is narrower: AI output should not cross into an action without a policy check and an evidence trail.

The operating rule

Treat every AI-proposed package as untrusted until a separate system and a named reviewer establish what it is, where it came from, and exactly what will run. Models can propose dependencies. Registries can distribute them. Only your dependency gate should authorize them.