Hallucinated Dependencies: The Supply Chain Risk in AI-Written Code
Last updated October 2026
Hallucinated package dependencies are libraries an AI coding tool imports or installs that do not exist on npm or PyPI. In a USENIX Security 2025 study, 19.7% of 2.23 million AI-suggested packages were fake, and 43% of those fake names came back on every repeat run. Attackers register those predictable names, so one unchecked install runs their code.
Key takeaways
- Package hallucination is common and repeatable. Commercial models averaged a 5.2% hallucination rate and open source models 21.7% in a USENIX Security 2025 study of 16 models.
- Repeatability is what makes it an attack. A name a model invents once is noise. A name it invents every time is a domain an attacker can buy.
- It is already happening. A hallucinated PyPI name drew more than 30,000 downloads in three months, and in 2026 a fake npm name spread to 237 repositories through AI-generated agent skills.
- Most hallucinated names are not typos, so typosquat filters miss them. Only 13.4% sit within two edits of a real package.
- Lockfiles do not save you. A lockfile pins the malicious package as faithfully as a real one.
What are hallucinated package dependencies?
When a language model writes code, it predicts plausible text. A made-up package name, or a real-sounding blend such as react-codeshift, is plausible text. The model has no live view of the registry, so it cannot know whether the name is real. It writes the import, the install command, or the package.json entry with the same confidence it uses for requests.
The attack built on this is usually called slopsquatting. The attacker does not need to guess what developers will mistype. They ask the same models the same questions, collect the names that do not exist, and publish packages under them. Then they wait for an AI assistant, or a developer copying its output, to install one.
The largest public measurement so far is “We Have a Package for You!” by Spracklen and colleagues, published at USENIX Security 2025. The researchers generated 576,000 code samples across Python and JavaScript using 16 code generation models, then checked every suggested package against PyPI and npm.
How often do AI models hallucinate package dependencies?
Often enough that any codebase written with heavy AI assistance should be assumed to contain at least one candidate until it has been checked. These are the paper’s headline figures:
| Measure | Result |
|---|---|
| Package suggestions that did not exist | 440,445 of 2.23 million (19.7%) |
| Unique invented package names | 205,474 |
| Average rate, commercial models | 5.2% |
| Average rate, open source models | 21.7% |
| Lowest rate of any model tested (GPT-4 Turbo) | 3.59% |
| Invented names repeated in all 10 re-runs of a prompt | 43% |
| Invented names repeated more than once | 58% |
| Invented names within 1 to 2 edits of a real package | 13.4% |
| Invented names 6 or more edits from any real package | 48.6% |
| Invented Python names that exist on npm | 8.7% |
Two of these numbers matter more than the headline rate. The 43% repeat figure means hallucinations are not random noise. They are stable outputs an attacker can harvest. The edit distance figures mean most invented names look nothing like a real package, so tooling that flags near-misses of popular names will not see them.
The 8.7% cross-language figure is its own trap. A model writing Python sometimes reaches for a name that is real on npm. A reviewer who searches the name, finds a package, and moves on has checked the wrong registry.
The paper also found that raising sampling temperature increased hallucination sharply. Treat the 5.2% commercial average as a floor for an unsupervised agent, not a ceiling.
Has anyone actually been attacked through a hallucinated package?
Yes, and the documented cases show the path from a model’s guess to code running on a machine. Aikido Security’s write-up of slopsquatting incidents collects three:
huggingface-clion PyPI. In early 2024, Bar Lanyado of Lasso Security noticed models repeatedly recommending this name, while the real tool installs throughhuggingface_hub[cli]. He published an empty package under the invented name. It received more than 30,000 downloads in three months, and the hallucinated install command had been copied into a public Alibaba repository README.react-codeshifton npm. In January 2026, Aikido researcher Charlie Eriksen found this conflation ofjscodeshiftandreact-codemodinside a batch of 47 LLM-generated agent skills. Through forks it had spread to 237 repositories. After he claimed the name, it kept receiving daily downloads, which Aikido attributes to agents running install commands straight from skill files.unused-importson npm. A likely slopsquat ofeslint-plugin-unused-imports, confirmed malicious, still drawing 233 downloads a week in early February 2026 before npm placed it under a security hold.
The research has also moved past package names. In July 2026, The Hacker News reported on HalluSquatting, work from Ben Nassi’s group at Tel Aviv University with collaborators at the Technion and Intuit. The researchers showed coding assistants including Cursor, Windsurf, GitHub Copilot, Cline, and Gemini CLI reaching for the same wrong repository or skill name in up to 85% of repository requests and up to 100% of skill installs, then running attacker-supplied code. The payloads were harmless placeholders, and vendors were notified before publication.
Why do hallucinated package dependencies get past code review?
Because every signal a reviewer relies on says the dependency is fine. The import resolves. The tests pass, since the attacker’s package can export whatever the code expects, or nothing at all if the payload runs at install time. The lockfile is committed and the hash verifies, because the lockfile faithfully records whatever was installed. A diff that adds one line to requirements.txt is the least reviewed line in the pull request.
Agents widen the gap. A human copying an install command from a chat window at least sees it. An agent with shell access runs npm install or pip install as one step among forty, and the only record is a line in a transcript nobody reads. We cover this pattern of locally correct, globally unsafe output in our pillar on why AI-generated code compounds technical debt, and supply chain gaps sit on our list of the security flaws we find most often in AI-generated code.
How do you check an existing codebase for hallucinated package dependencies?
Most coverage of slopsquatting stops at prevention advice for new code. If the code is already written, you need an audit. Here is the check to run, in order:
- Build the full dependency list. Pull every direct and transitive dependency from the lockfiles, not the manifests. Include every ecosystem in the repo: a Python service in a JavaScript monorepo is where cross-registry mistakes hide.
- Grep for install commands outside manifests. Search Dockerfiles, CI workflows, setup scripts, READMEs, and agent skill or rules files for
pip install,npm install,npx, anduvx. These bypass the lockfile entirely and are wherereact-codeshiftlived. - Check each name against the correct registry. Confirm it exists on the registry for its own language, not just somewhere.
- Pull registration and publisher history. Flag any package first published within 90 days of the commit that added it, with a single maintainer, few versions, or no linked source repository.
- Read install scripts. For every flagged npm package, read
preinstallandpostinstall. For flagged Python packages, readsetup.pyor the build backend hooks. Install-time code is the payload path. - Trace who added it. Use
git blameon the manifest line. A dependency added in a large AI-assisted commit with no linked ticket deserves the most suspicion. - Replace, do not just remove. The code that imported the fake package still needs the function it expected. Find the real library the model was reaching for and confirm the API matches.
Dependency verification is one part of a wider review. Our 10-day plan to audit an AI-generated codebase shows where it fits alongside security, data model, and test checks.
What controls stop hallucinated dependencies in new code?
The controls that work move the check from the reviewer’s attention to the toolchain:
- A release age gate. pnpm’s
minimumReleaseAgesetting, added in v10.16.0, refuses any version published fewer than a set number of minutes ago, transitive dependencies included, and defaults to 1,440 minutes from v11. uv’sexclude-neweraccepts durations such as7 days. This blocks freshly registered names. It does not block a name an attacker registered months ago, which is whyhuggingface-cliwould have passed. - An allowlist for agents. An agent with shell access should install only from an approved list. Anything else becomes a pull request a human approves.
- A dependency diff gate in CI. Any pull request that adds a new package fails until a named reviewer signs off on it specifically, separate from code approval.
- An internal registry proxy. Route installs through a proxy that only serves packages someone has vetted once.
- Provenance where it exists. Prefer packages with build provenance linking the published artifact to a public source repository.
None of these is expensive. The expensive part is discovering after a breach that the control was never there.
Frequently asked questions
What are hallucinated package dependencies?
Libraries an AI coding tool imports or installs that do not exist on npm or PyPI. The model has no live view of the registry, so it writes a made-up but plausible package name with the same confidence it uses for real ones.
What is slopsquatting?
The attack built on hallucinated dependencies. Attackers ask the same models the same questions, collect the package names that do not exist, publish packages under those names, and wait for an AI assistant or a developer copying its output to install one.
How often do AI models hallucinate package names?
In the USENIX Security 2025 study “We Have a Package for You!”, 19.7% of 2.23 million AI-suggested packages did not exist. Commercial models averaged 5.2% and open source models 21.7%, and 43% of invented names came back in all 10 re-runs of a prompt.
Do lockfiles or typosquat filters protect against hallucinated dependencies?
No. A lockfile pins a malicious package as faithfully as a real one. And only 13.4% of hallucinated names sit within two edits of a real package, so filters that flag near-misses of popular names miss most of them.
What controls stop hallucinated dependencies in new code?
Move the check into the toolchain: a release age gate (such as pnpm’s minimumReleaseAge or uv’s exclude-newer), an allowlist for agents with shell access, a dependency diff gate in CI, an internal registry proxy, and preferring packages with build provenance.
How TopDevz handles dependencies in AI-written code
If you want this check done by someone outside the team that wrote the code, that is what a Rescue Audit is for. It costs $4,950 and the fee is credited toward remediation if you have us fix what we find. The review is done by senior engineers who average more than 10 years of experience, not by a scanner alone, because the hard calls are judgment calls: whether a young single-maintainer package is a fake or just new.
Book a Code Review
If your codebase was written with heavy AI assistance and nobody has checked every dependency against its registry, send us the repository. A senior engineer will run the check above, read the install scripts on anything suspicious, and tell you what is real, what is unverified, and what to replace. Book a Code Review.