Slopsquatting: A New Supply Chain Threat From AI Coding Agents

A new supply chain attack class is targeting the layer below your code: the dependencies your AI coding agent suggests. Researchers call it slopsquatting. It works because AI tools, even the good ones, hallucinate package names. Attackers do not need to compromise a real package anymore. They wait for a model to invent one, then register the invented name on a public registry. When your developer runs npm install or pip install, the malware lands.

This article covers what slopsquatting is, why it is different from typosquatting, the documented incidents in 2025 and 2026, and a practical defense stack you can put in your pipeline this sprint.

How AI Coding Agents Hallucinate Dependencies

Large language models do not look up packages. They predict tokens that are statistically likely to follow a coding context. When the right answer is uncertain, the model fills the gap with something that looks plausible: an author name that follows naming conventions, a DOI that is well-formed, a package name that fits the ecosystem.

A March 2025 research paper measured this directly. Researchers generated 576,000 code samples using major LLMs and checked every package name against npm and PyPI. The results:

• 19.7% of suggested packages did not exist on the target registry
• Open-source models hallucinated at 21.7%
• CodeLlama hallucinated package names in over a third of its outputs
• GPT-4 Turbo was the cleanest at 3.59%

The most important number for security teams is repeatability. When the same prompt was run 10 times against the same model, 43% of the hallucinated names appeared in every single run. The hallucinations are not random noise. They are deterministic enough to be predicted, scraped, and weaponized.

A separate report from Versa Networks found that 58% of hallucinated packages appeared repeatedly across runs. With AI now writing 25% or more of new code at leading tech firms, the attack surface is large and growing.

Why This Is Different From Typosquatting

Typosquatting relies on human error. An attacker registers cross-evn and waits for someone to mistype cross-env. Registries like npm have countermeasures: name similarity checks, blocklists, and post-publication review.

Slopsquatting bypasses all of these. The attacker does not need a name that looks like a real package. They need a name that an AI consistently invents. The two attack profiles diverge sharply:

That last row is worth highlighting. The model often gets the concept right but the language wrong. It knows a package called serverless-python-requirements exists in the JavaScript world, so it suggests the same name when the developer asked for a Python solution. The install command sends the build to a totally unrelated piece of code in a different registry. Standard registry-side defenses cannot catch this because each name is legitimate in its own ecosystem.

Documented Incidents

This is not a hypothetical risk. The exploits have already happened.

huggingface-cli (PyPI)

Bar Lanyado of Lasso Security observed that AI models consistently suggested pip install huggingface-cli. The real package installs differently: pip install -U "huggingface_hub[cli]". The shorter name was a hallucination.

To measure the impact, Lanyado registered the hallucinated name on PyPI as a harmless empty package. Within three months, it received over 30,000 downloads. Alibaba pasted the wrong install command into the README of one of their public repositories. The package was harmless because Lanyado was a researcher. Anyone else could have shipped credential exfiltration in the same slot.

react-codeshift (npm)

In January 2026, Charlie Eriksen at Aikido Security noticed AI tools recommending an npm package called react-codeshift. The package was a hallucinated mash-up of two real packages, jscodeshift and react-codemod. It had no author and had never existed.

Eriksen registered the name. Within weeks, it spread to 237 GitHub repositories through cloned and modified agent skills, and the npm registry showed real install attempts from agent tooling. His public summary: the only reason it did not become an attack vector is that he registered it first.

unused-imports (npm)

A confirmed malicious package, registered to catch developers who confuse it with the real eslint-plugin-unused-imports. Currently behind an npm security hold, but as of February 2026 it was still receiving 233 downloads per week, suggesting either AI tools are still recommending it or the malicious version made it into project lockfiles before takedown.

PromptMink (multi-registry)

Researchers at ReversingLabs attribute this campaign to Famous Chollima, a North Korean APT group. Instead of registering hallucinated names, the group uses LLM Optimization (LLMO) abuse: they craft package descriptions, README files, and embedded documentation specifically designed to make AI coding agents recommend their packages. The targets are crypto and fintech development teams. The malicious payloads have evolved from simple JS to compiled Single Executable Applications and Rust-based NAPI-RS native modules to evade detection.

CISA, the NSA, and the Five Eyes partners published a joint advisory on AI agent supply chain risk in early 2026. The Stanford AI Index lists it among the top three new attack surfaces for autonomous agents.

The Attack Pattern

The mechanics are simple and repeatable:

1. Attacker runs targeted prompts against popular coding agents to harvest hallucinated package names.
2. Attacker filters the list for names that appear consistently across runs (the 43% repeatable subset).
3. Attacker registers the most promising names on npm, PyPI, RubyGems, crates.io, or any registry that allows public publication.
4. Each registered package contains a working facade and a malicious payload, typically credential exfiltration or environment variable theft on install.
5. Developer prompts an AI agent. Agent suggests the slopsquatted name. Developer or agent runs install.
6. Payload executes inside the developer's environment, with their privileges, on their codebase.

The window between hallucination harvesting and victim install can be hours. Agents do not check publication date by default.

Defense Stack

Slopsquatting is a supply chain problem, not a code review problem. You cannot scan source files for it because the malicious code lives in dependencies your code does not yet have. Defense has to live in the pipeline.

Below is a layered approach. None of the layers alone is sufficient. Together they make the attack expensive enough that most attempts will fail.

Layer 1: Pre-Install Validation

The cheapest defense is to validate every AI-suggested package against the registry before install runs. This is a one-script change for most teams.

#!/bin/bash for pkg in $(jq -r '.aiSuggestions[]' suggestions.json); do  if ! curl -sf "https://registry.npmjs.org/$pkg" > /dev/null; then    echo "WARN: package $pkg not found on registry — possible hallucination"    exit 1  fi done

This catches the simplest case: a name that does not exist at all. It does not catch a name that exists but is malicious. That requires the next layer.

Tools that automate this:

• Slopcheck — open-source CLI that validates AI-generated dependency lists against npm, PyPI, and other registries
• Aikido Intel — package threat feed including known slopsquatted names
• MCP-based validators — Claude Code performs registry lookup before suggesting; Cursor and most other agents do not by default

Layer 2: Registry Heuristics

Past existence is not enough. A package that was registered yesterday with no download history is suspicious regardless of whether it appears on PyPI.

Three signals worth alerting on:

• Package age below 30 days for any new dependency
• Weekly download count below 1,000 for a critical-path dependency
• Package name not in your organization's previous lockfiles or approved list

Open Policy Agent (OPA) is the standard way to enforce this in CI:

package supply_chain 
deny[msg] {  input.package.age_days < 30  not input.package.allowlisted  msg := sprintf("dependency %v is less than 30 days old", [input.package.name]) }
 deny[msg] {  input.package.weekly_downloads < 1000  input.package.role == "production"  msg := sprintf("low-traffic dependency %v in production path", [input.package.name]) }

This stops the most common slopsquatting pattern, where attackers register names within a 24-48 hour window after harvesting hallucinations.

Layer 3: SBOM Generation and Verification

Every build should produce a Software Bill of Materials that records exactly what went in. The standard chain:

# generate SBOM during build syft . -o cyclonedx-json > sbom.json 
# sign it so it cannot be swapped post-build cosign attest --predicate sbom.json --type cyclonedx \  ghcr.io/your-org/your-app:$TAG 
# verify before deploy cosign verify-attestation --type cyclonedx \  ghcr.io/your-org/your-app:$TAG

The point is not the syntax. The point is that after this step, the artifact carries cryptographic evidence of its dependency tree. A swapped or substituted package fails verification before it reaches production.

For continuous tracking across builds, Dependency-Track ingests CycloneDX SBOMs and flags new components, version drift, and known vulnerabilities across every build in your organization.

Layer 4: Sandboxed Install

AI-generated install commands should not run in your developer's primary environment. They should run in an ephemeral container with no credentials, no network access beyond the registry, and outbound traffic logging.

docker run --rm \  
       --network=registry-only \  
       --read-only \  
       -v "$PWD":/work:ro \  
       node:20-alpine \  
       sh -c "cd /work && npm install --dry-run"

If the install attempts an outbound connection during postinstall scripts, the container logs it, and the build fails. This catches malicious packages that pass registry checks but execute payloads on install.

Layer 5: Lockfile Diff Enforcement

Every PR that modifies a lockfile should require explicit review of the diff. New dependencies are the highest-risk additions, and AI agents introduce them silently.

# in CI, fail the build if package.json keys diverge from package-lock.json diff <(jq -r '.dependencies | keys[]' package.json) \     <(jq -r '.packages | to_entries[].key | select(. != "")' package-lock.json) \  || { echo "lockfile out of sync — possible injected dependency"; exit 1; }

For Python projects, the equivalent is checking requirements.txt against pip freeze output, or using pip-compile with --generate-hashes and verifying the hashes in CI.

Layer 6: Model Configuration

Every defense above is reactive. The proactive defense is reducing the hallucination rate at the source.

• Lower model temperature. Hallucination rates correlate strongly with sampling randomness. For coding tasks, set temperature between 0.0 and 0.2.
• Use retrieval-augmented prompts where possible. A model with access to live registry data hallucinates fewer package names than one operating from training data alone.
• Prefer agents with built-in validation. Claude Code performs web search verification before suggesting packages. This is not a complete defense, but it materially reduces slip-through.
• Keep the model out of dependency decisions where possible. For production-critical packages, use only allow-listed dependencies that have passed organizational review.

What Detection Looks Like in Practice

Three behavioral signals that should trigger investigation:

1. An AI agent suggests a package your team has never used and is not in your approved list.
2. A package with under 1,000 weekly downloads is recommended for a production dependency.
3. An install command runs successfully, but the package cannot be found in npm view or pip show output afterward.

If your CI catches one of these, treat it as a potential incident. Pull the install logs, check the package source on the registry, and look for outbound network activity from the build environment during install.

Closing

Traditional supply chain security assumed humans choose dependencies. AI coding agents broke that assumption. They generate dependencies at machine speed, with confidence, and without verification. The registries they pull from were built for a world where the attacker had to guess what humans would mistype. That world is gone.

The defenses are not new. SBOMs, signed attestations, sandboxed installs, OPA policies, and lockfile diff enforcement are the same tools mature teams already use for supply chain security. What slopsquatting changes is the urgency. AI raises the tempo at which weak controls break.

If you are running AI coding agents in any production-adjacent workflow, the question is not whether a slopsquatted package will be suggested in your environment. It is whether your pipeline catches it before it lands in a lockfile.

If your team has detected slopsquatting attempts in your pipeline, the data would be useful to the wider security community. Anonymized incident reports are welcome in the comments.