Summary: Models invent plausible package names; attackers register them and wait. A USENIX Security 2025 study found >205,000 unique hallucinated package names across 576,000 generated code samples.
Sources: raw/Secure-coding-patterns/Best AI Code Security Solutions 2026...md (Orca, citing USENIX Security 2025); AI Code Security_ Complete Guide.md (Cycode)
Last updated: 2026-07-29
The mechanism
“The sharpest new risk is the package that does not exist. Code-generating models routinely invent plausible library names, then import them in the code they produce.”
“Attackers… register the hallucinated package name on a public registry, point it at malware, and wait. The next developer whose assistant suggests that same fictional name installs the attacker’s code instead. Security researchers call this slopsquatting, a generative-AI twist on typosquatting.”
(source: Orca)
Cycode describes the same thing as enabling “dependency confusion attacks where adversaries register those names with malicious payloads.”
The numbers
From a USENIX Security 2025 study of 576,000 AI-generated code samples (Spracklen et al., cited by Orca):
| Model class | Outputs containing hallucinated packages |
|---|---|
| Commercial models | 5.2% |
| Open-source models | 21.7% |
Producing more than 205,000 unique fake package names.
Cite the population, not just the number. OpenSSF cites the same study for a single figure of 19.7% (see AI assistant instructions) — a different slice of one dataset, not a conflicting result. Neither source in the vault reproduces the paper directly.
Two things make these numbers unusually actionable:
- The 4× gap between commercial and open-source models is a procurement input, not just a research finding.
- Hallucinations are repeatable. The attack only works because the same model suggests the same fictional name to different developers. A one-off hallucination is a broken build; a consistent one is a registerable attack surface. That repeatability is what converts a model quality problem into a supply-chain vulnerability.
Why this is the vault’s most concrete supply-chain material
Two other sources in the vault call supply chain the worst class:
- The health care poisoning review: “the highest-impact threat class, as demonstrated by the SolarWinds precedent” (poisoning defences).
- Snyk’s matrix: supply chain needs low resources and has very high detection difficulty — the worst quadrant (model theft).
Slopsquatting fits that profile exactly. Registering a package name is trivially cheap, and the install looks like any other dependency resolution. It also has a property the other supply-chain attacks in the vault lack: the victim’s own tooling recommends the malicious package.
Adjacent problems from the same cause
Orca groups two more consequences of assistants pulling dependencies freely:
Dependency explosion. “A small feature can arrive trailing a dozen transitive packages no one chose deliberately.”
Stale libraries. Packages “pinned to whatever version the model last saw in training, which may be months behind the patched release.” The model’s training cutoff becomes your dependency floor — a failure mode with no human-authored equivalent.
Defences
Orca’s, and they are conventional supply-chain hygiene rather than anything AI-specific:
- Pin and verify dependencies.
- “Treat any unfamiliar import suggested by an AI assistant as untrusted until verified.”
- SCA (software composition analysis) “that flags stale and vulnerable libraries before they compound.”
The check that actually catches slopsquatting is the cheapest one: does this package exist, and did it exist before today? A newly-registered package matching a model’s suggestion is the signal.
Where it maps
| Framework | Placement |
|---|---|
| OWASP LLM03 Supply Chain | Third-party model and package risk; LoRA/PEFT hub exposure |
| OWASP LLM04 | Adjacent — malicious pickling, code execution on model load |
| ATLAS | Resource Development — attacker builds capability before contact |
| AI Act Art 15(5) | Closest fit is “model poisoning” (pre-trained components); not named directly |
| Palo Alto | Recommends “cryptographic signing of models and datasets” — the control that would cover this |
Note the AI Act gap again: a supply-chain compromise delivered through a coding assistant’s suggestion is not among the five attack classes Art 15(5) enumerates.
The connected attack
Slopsquatting poisons what the assistant recommends. PITAX T46 Agent Instruction-File Injection poisons what the assistant is told — hiding instructions “often via invisible Unicode, in repository configuration the coding agent automatically trusts (CLAUDE.md, .cursor/rules, copilot-instructions, README) or in a dependency, steering AI coding agents to emit backdoored or vulnerable code.”
Together they bracket the coding assistant: one corrupts its inputs, the other its outputs. Both end with attacker-controlled code in your repository, and neither requires touching your infrastructure.