Why does AI-generated code import packages that do not exist?

What is a package hallucination?

A package hallucination is an import or install command that names a package which is not published in the registry the code expects, such as npm for JavaScript or PyPI for Python. The paper that measured it, We Have a Package for You! by Spracklen and colleagues (arXiv 2406.10279, revised 2 March 2025, listed to appear at the 2025 USENIX Security Symposium), generated 576,000 code samples in Python and JavaScript with 16 models and found 205,474 unique invented package names. The authors describe the problem as "a novel form of package confusion attack", which means an attack that relies on you installing the wrong package by name.

Why do models invent package names?

A model writes the most likely next text given your prompt and what it saw in training. Package names follow patterns (flask- something, react- something, a verb plus "js"), so a name can look right without existing. The model has no registry lookup unless the tool you use gives it one, and even then it may not call it. The study calls these "fact-conflicting errors": the code is fluent, the fact behind it is wrong.

The paper's abstract also says the authors tested mitigation strategies that "significantly reduce" hallucinated packages while keeping code quality. That is useful, but it does not reach zero, so the check stays on your side.

What is slopsquatting?

Slopsquatting is the attack that turns a hallucination into a compromise: someone registers a name that models tend to invent and waits for a developer to install it. Socket, a supply chain security vendor, wrote on 8 April 2025 that the term was coined by Seth Larson, the Python Software Foundation's Developer-in-Residence, and described it as "a twist on typosquatting: instead of relying on user mistakes, slopsquatting relies on AI mistakes." Typosquatting is registering a misspelling of a popular package name.

OWASP lists the same risk in LLM05:2025 Improper Output Handling, which warns that a model "may also hallucinate non-existent software packages, potentially leading developers to download malware-infected resources."

What do the bad names look like?

What you see	What it may be	How to tell
Install fails with "not found"	A plain hallucination, nobody has registered it yet	The registry has no page for the name
Install succeeds, package is days old, no repository link	A squatted name, possibly registered to catch this mistake	Check the first publish date and the repository.url field
Name close to a well-known package	A typo or a typosquat	Compare letter by letter with the package the docs name
Name that exists in a different language's registry	A cross-ecosystem mix-up	Confirm the registry matches your language

How do you check a dependency before you install it?

Do this for every package an assistant adds, before npm install or pip install runs. If an agent runs commands for you, turn on approval for install commands so you see the name first.

1. Read the name out of the code. List every new import, require or entry in package.json or requirements.txt that you did not add yourself.
2. Look it up in the registry. For npm, run npm view <name>. The npm view documentation (CLI v11, read 16 October 2026) shows how to read single fields, for example npm view <name> repository.url and npm view <name> time. For Python, open https://pypi.org/project/<name>/.
3. Check that it is the package you think it is. Follow the repository link, check that the project's own README names the package the same way, and check the publish history. A package first published last week, with no repository and no readme, deserves a second look even if the install works.
4. Prefer the library's own docs. If the official docs for the framework name a different package for the job, use that one and tell the assistant why.
5. Pin what you approved. Commit package-lock.json, and install in CI with npm ci, which the npm ci documentation says "will never write to package.json or any of the package-locks". In Python, pin with == and hashes, covered below.
6. Keep install scripts on a short leash. The same page documents the ignore-scripts setting: when true, npm does not run the scripts in packages' package.json files, so a preinstall or postinstall script in a package you have not checked does not run on your machine.

The lookup takes seconds. It is the cheapest check in the whole review routine for AI-generated code.

What can you put in the prompt or rules file?

Prompts lower the rate; they do not remove it. Lines that help:

• "Use only packages listed in package.json. If you need a new one, name it, link its registry page, and stop for approval."
• "Prefer the standard library and the framework's built-in features over new dependencies."
• "Do not run install commands."

Put them in AGENTS.md or your tool's rules file so every session reads them. The same rules file is where you keep the lines from the thread on keeping API keys out of a vibe-coded app, since a malicious package that does get installed will look for exactly those secrets.

If the code came from somewhere other than an assistant, such as an old tutorial, the same lookup applies; see is it safe to paste a script from an old tutorial site?. CodeLifter's longer write-up on vibe coding security puts the package check alongside secret scanning and output handling.

Short version

• Models predict package names; they do not look them up. Spracklen et al. measured at least 5.2% (commercial) and 21.7% (open-source) hallucinated packages.
• Slopsquatting is registering those invented names so someone installs them.
• Look up every new dependency with npm view or on pypi.org before you install it.
• Pin approved dependencies and install with npm ci in CI.
• Rules files help, but the registry check is the control.