Slopsquatting Is Now a Documented Attack Class: Why AI Coding Agents Create a Package-Verification Security Blind Spot

Your AI coding agent hallucinates a package name. An attacker registers it first. Your build pipeline installs it without asking. This is slopsquatting, and it has moved from theoretical risk to actively exploited security vulnerability in the span of about eighteen months. If your engineering team uses any AI-assisted code generation (and statistically, it does), you have a supply-chain exposure that traditional defenses were never designed to catch.

Key Takeaways

• Slopsquatting exploits a structural property of language models: they confidently recommend packages that do not exist, and attackers register those names preemptively. A USENIX Security 2025 study found that 19.7% of 2.23 million AI-generated code samples referenced at least one hallucinated package.
• 43% of hallucinated package names recur on every run of the same prompt, making them predictable and farmable. This is not a random glitch. It is a stable, enumerable attack surface.
• Nation-state actors (specifically North Korea's Famous Chollima group) are now engineering malicious packages to deceive AI coding agents, not humans. The documentation is written for the model's retrieval system.
• Traditional typosquatting defenses (name-collision detection in npm, PyPI namespace rules) provide zero coverage here because the hallucinated names are novel strings with no legitimate package to collide against.
• The fix is architectural, not aspirational. Verification must sit inside the agent loop, gating installs against a live registry check before code runs, regardless of which model suggested the dependency.

What exactly is slopsquatting?

Slopsquatting is registering a package name that an AI model is known to hallucinate, then waiting for automated pipelines to install it. The term was coined by Seth Larson of the Python Software Foundation in April 2025, combining "AI slop" (low-quality model output) with "typosquatting" (registering misspelled domain or package names). The mechanism is straightforward: a language model generates code that includes an import or pip install for a package that has never existed on any registry. An attacker identifies that hallucinated name and publishes a package under it. The next developer or autonomous agent that runs the generated code pulls the attacker's payload.

The difference from classic typosquatting matters. Typosquatting relies on a human making a keystroke error: reqeusts instead of requests. npm and PyPI have built collision-detection systems to flag names that are suspiciously close to popular packages. Slopsquatting bypasses this entirely. The hallucinated name is not a misspelling of anything. It is a plausible-sounding but wholly invented string, so there is no existing package for the collision detector to compare it against.

How big is the hallucinated-package problem?

Bigger than most teams assume. Researchers at the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech generated 2.23 million code samples across 16 code-generation models and catalogued 205,474 unique fabricated package names. Nearly one in five samples contained at least one phantom dependency. Open-source models were worse (averaging 21.7% hallucination rates, with some CodeLlama configurations exceeding 33%), but commercial models were not clean either, with the best measured rate sitting at 3.59%.

A separate analysis from Versa Networks found that 58% of hallucinated packages appeared repeatedly across runs. The USENIX study was more specific: when identical prompts were re-run ten times each, 43% of hallucinated names appeared on every single run. This repeatability is what makes the attack farmable. An attacker does not need to guess. They run a few dozen prompts against a popular model, collect the stable hallucinations, and register them. The model does the targeting for them.

In March 2026, researchers identified 127 package names (109 on PyPI, 18 on npm) that every major frontier model consistently hallucinated. That is not a statistical tail. That is a pre-built target list sitting in the open.

Has anyone actually been harmed, or is this still theoretical?

It is not theoretical. Multiple documented cases exist in the wild.

In January 2026, a security researcher registered an npm package called react-codeshift, a name that does not exist but that a language model had generated by conflating two real tools (jscodeshift and react-codemod). Before the researcher could defensively claim the name, the hallucinated reference had already spread to 237 GitHub repositories via AI-generated agent skill files. Daily download attempts from autonomous agents were recorded immediately after registration. Nobody typed that name. No human made a typo. An AI agent wrote it, another AI agent propagated it, and a third AI agent tried to install it.

The npm package unused-imports is another documented case. AI models hallucinate this name instead of the legitimate eslint-plugin-unused-imports. As of early February 2026, the malicious package was still available on npm, recording approximately 233 weekly downloads despite having been security-held. "Security-held" means npm flagged it. It was still being downloaded.

Why does the PromptMink campaign matter more than a typical supply-chain attack?

Because it represents a qualitative shift in targeting. PromptMink is the first documented campaign engineered to deceive AI coding agents rather than human developers. ReversingLabs attributes PromptMink to Famous Chollima, a North Korean state-sponsored threat group. The campaign operated across a seven-month window from September 2025 through April 2026, with researchers tracking more than 60 packages and over 300 versions. A parallel effort distributed more than 1,700 malicious packages across npm, PyPI, Go, and Rust ecosystems.

What makes PromptMink different from standard supply-chain compromises is the audience for the social engineering. The attackers wrote documentation, README files, TypeScript type definitions, and semantic package structure specifically to rank higher in AI coding agent recommendations. ReversingLabs calls this "LLM Optimization abuse," and the analogy to SEO is apt: the target audience is not a human scanning search results but a language model's retrieval and recommendation system evaluating which dependency to suggest. The package's documentation was crafted to look ideal to a model, not to a person reading npm.

A February 28 commit to an autonomous trading agent included a tainted dependency introduced in a commit co-authored by an AI large language model. The malicious code landed in a production codebase through an AI-assisted workflow, not through a human clicking the wrong link.

What is HalluSquatting, and why is it an escalation?

HalluSquatting takes slopsquatting from passive to active. Where slopsquatting relies on naturally occurring hallucinations that attackers discover and squat, HalluSquatting uses a universal, transferable adversarial trigger to force AI agents to hallucinate a specific attacker-chosen resource on demand. Described in the July 2026 paper "Beware of Agentic Botnets," the technique chains the triggered hallucination with indirect prompt injection to achieve remote code execution and spread botnet malware.

The reported success rates are stark: hallucinated-resource rates up to 85% for repository cloning and 100% for skill installation across nine coding assistants including Cursor, Windsurf, Copilot, Cline, and Gemini CLI. This is not a fragile proof-of-concept that works once in a lab. It is a transferable technique that works across multiple agent platforms, turning each compromised agent into a propagation node.

Why don't existing defenses catch this?

Three reasons, each structural.

Does npm or PyPI collision detection help?

No. Collision detection compares a new package name against existing popular names to flag suspicious similarity. A hallucinated name like react-codeshift or unused-imports is not similar to anything that already exists. It is a plausible new name. The collision detector has nothing to compare it to, so it provides no defense.

Can code review catch hallucinated dependencies?

Sometimes, if a human is reviewing. But the trend is toward autonomous agent workflows where the AI writes the code, selects the dependencies, and commits them, sometimes with no human reviewing the diff before the CI pipeline runs npm install. The react-codeshift case spread to 237 repositories through agent skill files. Nobody read those diffs. The agents wrote and consumed them in a closed loop.

Will better models fix this?

Not sufficiently. Newer frontier models do hallucinate less. But "less" is not "zero," and the remaining hallucinations are often the stable, repeatable ones that are most dangerous. A 2026 Sonatype analysis found that nearly 27.8% of dependency recommendations from a leading LLM were hallucinations, including versions that do not exist. Even the best commercial model in the USENIX study still hallucinated at 3.59%. When you are running thousands of prompts per day across a development team, 3.59% produces a steady stream of phantom dependencies. And the 127 names that all major models agree on remain available for registration regardless of how much the average rate improves.

What has the government said about this?

On May 1, 2026, CISA, the NSA, and their Five Eyes partners jointly published "Careful Adoption of Agentic AI Services," explicitly confirming that poor or deliberately misleading tool descriptions can cause agents to select tools unreliably. The guidance recommends that organizations maintain trusted registries of approved components, restrict agents to allow-listed tools and versions, and require human approval before high-impact actions. This is not theoretical concern from a research paper. It is formal guidance from signals-intelligence agencies to defense and critical-infrastructure operators.

What does an effective defense look like?

The fix is architectural, not a matter of prompt engineering or model selection. Verification has to sit inside the agent loop, gating any install or execute action against a live check before code runs, regardless of which model suggested the dependency.

Should teams use allowlists or blocklists?

Allowlists. Blocklists are reactive; you add a name after it has already been identified as malicious. With 205,474 unique hallucinated names catalogued and growing, you will never enumerate the blocklist fast enough. An allowlist of vetted, approved packages is smaller, auditable, and fails closed: if the agent suggests something not on the list, the install does not happen.

This aligns with the Five Eyes guidance. It also matches a broader design principle we believe in: any AI agent action that reaches outside the local environment (network calls, package installs, credential access) should default to deny, with allowlisting by exception. Treating this as a core architectural constraint rather than a compliance checkbox changes how you build the system, not just how you audit it.

What should the verification step actually check?

At minimum: does this exact package name and version exist on the registry right now? When was it first published? How many maintainers does it have? What is its download history? A package registered last week with a single maintainer and twelve downloads is not the same risk profile as a package with three years of history and a known maintainer. These signals are cheap to query and easy to gate on. The hard part is making the gate mandatory, not optional, inside your CI/CD pipeline and inside any agent framework that can run npm install or pip install autonomously.

Do lockfiles help?

Lockfiles help with reproducibility, not with initial introduction. If an AI agent generates code that adds a new dependency and you run npm install to update the lockfile, the malicious package gets resolved and locked in at that moment. The lockfile then faithfully reproduces the compromise on every subsequent build. Lockfiles are necessary but not sufficient. The verification has to happen before the lockfile is updated.

How should teams think about the "hallucination is a bug" framing?

Reframe it. Hallucination is a property of how language models work, not a defect that a patch will eliminate. Models predict the next plausible token. A package name that sounds right, that combines fragments of real package names in a natural way, is exactly the kind of thing a model will produce. This is not a bug to fix. It is an attack surface to mitigate.

The PromptMink campaign makes this concrete. Attackers are not waiting for models to accidentally hallucinate useful names. They are writing package documentation specifically optimized for how models evaluate and recommend dependencies. They are attacking the retrieval and ranking layer, not the generation layer. Even a model that never hallucinates can be tricked into recommending a real but malicious package if that package's documentation is sufficiently well-crafted to score high in the model's evaluation.

This means your defense cannot depend on "better models." It has to be structural: verified provenance, reputation signals, gated installs, and human approval for anything that crosses a trust boundary.

What about the "phantom domain" variant?

Packages are not the only hallucinated resource. Palo Alto Networks' Unit 42 has described "phantom squatting" for URLs and domains, identifying roughly 250,000 hallucinated domains sitting unregistered and available for anyone to claim. If your AI agent generates code that fetches a configuration file from a URL the model invented, and someone registers that domain, the same class of attack applies. The package manager is just the most common entry point because install commands execute arbitrary code by design (postinstall scripts in npm, setup.py in older Python packaging).

What is the agent-to-agent propagation risk?

This may be the least understood and most concerning dimension. The react-codeshift case spread through AI-generated agent skill files, meaning one AI agent wrote a reference to a hallucinated package, another AI agent consumed that reference as training or context, and the hallucination propagated without any human touching the chain. On platforms where AI agents post autonomously, an attacker can seed a hallucinated reference once and let agent-to-agent propagation do the distribution work.

The HalluSquatting paper explicitly models this as a botnet propagation mechanism: a compromised agent hallucinates a resource, another agent consumes that hallucination, installs the malicious package, and itself becomes a propagation node. At 100% skill-installation success rates across tested assistants, the chain is efficient.

What we build around, and what we do not claim

At Selina, we route requests through a stack of frontier models, routed per task. We are not exempt from the underlying dynamics described here. Models hallucinate. That is a property of the technology, not a vendor-specific failing.

What we can control is architecture. Our memory is encrypted at rest but is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. We state that plainly because the alternative (implying more protection than exists) is worse than the honest limit. Files and transfers through SelinaSEND are end-to-end encrypted. Non-content operational metadata is kept for a short retention window. These are design choices, not marketing claims.

The principle that applies to slopsquatting defense is the same one that drives our architecture: do not trust the model's output as ground truth. Verify at the boundary. Gate actions that cross trust boundaries. Default to deny. These are not novel ideas. They are the same zero-trust principles that network security adopted twenty years ago, applied to a new class of autonomous software agent.

Concrete steps to take this week

1. Audit your AI-assisted commits from the last 90 days. Search for import and require statements referencing packages that do not appear in your lockfile or your organization's approved-package list. If you find hallucinated references that were committed but never resolved, you are lucky. If they were resolved, check what you installed.
2. Add a pre-install verification step to your CI pipeline. Before npm install or pip install runs, validate every new dependency against the registry. Check publication date, maintainer count, and download history. Fail the build if a dependency was published less than 30 days ago and has fewer than a threshold number of downloads.
3. Restrict your AI coding agents to an allowlisted set of packages. This is operationally painful. It is less painful than incident response.
4. Require human approval for any agent action that installs a new dependency. If your workflow lets an AI agent run npm install some-new-package autonomously, you have already lost the ability to prevent slopsquatting. Put a human in that loop. The Five Eyes guidance says the same thing, and they are not known for overcaution.
5. Monitor for the 127 known cross-model hallucinated names. Multiple security vendors have published lists. Use them as canaries. If any of those names appear in your dependency tree, investigate immediately.

If you are looking for an AI assistant built with these architectural constraints in mind: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io