New 2026 research found 127 package names hallucinated by five frontier models, turning AI coding into a repeatable supply-chain risk. Read now.
What "ghost packages" actually are
When you ask an AI model to write code, it often suggests importing libraries by name. Most of those names are real. But models sometimes invent a package that sounds plausible and does not exist in any registry — a confident, well-formatted reference to nothing. These are ghost packages, and 2026 research catalogued 127 such hallucinated names produced by five frontier models. The problem is not that the code fails to run; it is that the missing name is a blank slot anyone can fill.
The danger comes from repeatability. If a model reliably hallucinates the same package name for the same kind of request, an attacker only has to register that name once. From then on, every developer who accepts the suggestion and runs an install command pulls the attacker's code instead of an error.
Why AI turns a typo into a supply chain
Classic "typosquatting" relies on humans fat-fingering a real package name. Ghost packages remove the randomness. A hallucination is a stable output of a model given a stable prompt, so the same fake name surfaces across many users, sessions, and projects. That converts a one-off mistake into a predictable target with a built-in stream of victims who trust the suggestion because it came from their coding assistant.
Trust is the mechanism that makes this work. Developers paste model output, see a clean import, and assume the dependency is legitimate. Package managers happily install whatever name resolves in the registry, and the installed code often runs with the developer's own permissions during setup — reaching credentials, source, and internal networks.
How to defend against it
The core defense is simple: never install a dependency just because a model named it. Verify every suggested package against its real source and history before it enters your environment. A few habits close most of the gap:
- Check that the package exists on the official registry and links to a real, maintained repository — not a bare page created days ago.
- Look at download history, release count, and maintainers; a "core" library with almost no track record is a red flag.
- Pin exact versions and use lockfiles so an unexpected new name cannot slip in unnoticed.
- Run installs in a sandbox or container first, so setup scripts cannot touch real secrets.
- Maintain an allowlist of approved dependencies for critical projects, and require review to add to it.
Automated checks help at scale. A CI step that flags any newly introduced dependency, or that rejects packages missing a verifiable repository and reasonable age, catches ghost packages before they reach production.
Treat AI suggestions as drafts, not decisions
The practical takeaway is a mindset shift. Model output is a starting point that still needs the same scrutiny you would give code from an unknown contributor. The assistant is optimizing for a fluent answer, not for whether each named dependency is real and safe.
Because the same hallucinated names recur, the risk compounds across a team the more people lean on AI without a verification step. Building that check into your workflow — a quick lookup, a lockfile, a sandboxed install — is cheap insurance against handing an attacker a name your tools were already trained to suggest.