The AI told me to install a package. Is it real?

Guide · checked against the docs on Oct 16, 2026

AI coding tools often tell you to run npm install something or pip install something. Usually that's fine. But sometimes the package name is made up. And a made-up name is a gift to an attacker, who can register it and fill it with bad code. People online call this "slopsquatting". That's an informal name: the research below calls it "package hallucination". Everything here comes from that research paper and from npm, pip and GitHub's own docs, read on October 16, 2026. We haven't tested these steps ourselves.

Not affiliated with or endorsed by npm, GitHub, the Python Packaging Authority or the paper's authors.

What the risk is

A 2024 research paper by Spracklen and others (arXiv) defines it: "Package hallucination occurs when an LLM generates code that recommends or contains a reference to a package that does not actually exist." (checked Oct 2026)

Then the attack: "An adversary can exploit package hallucinations, especially if they are repeated, by publishing a package to an open-source repository with the same name as the hallucinated or fictitious package and containing some malicious code/functionality." (checked Oct 2026)

Why that matters at install time: "Research has shown that installing open source Python or JavaScript packages allows the execution of arbitrary code by an attacker" (checked Oct 2026). pip's own secure installs page says the same about pip: "By default, pip does not perform any checks to protect against remote tampering and involves running arbitrary code from distributions." (checked Oct 2026)

How often it happens

The paper found that "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models" (checked Oct 2026). Many fake names come back again and again: "43% of hallucinated packages were repeated in all 10 queries, while 39% did not repeat at all across the 10 queries." (checked Oct 2026)

Treat those numbers with care. The authors say so themselves: "Since the writing of this paper, several more advanced models have emerged for code generation. These newer models may offer improved performance and different hallucination tendencies and characteristics, which we may have been unable to capture in our study." (checked Oct 2026) We don't know the rate for the tool you use today.

Why "it exists" isn't enough

You might think: just check the name is real. The paper warns that's not enough: "Open-source repositories make no guarantee about the safety of hosted content; the mere presence of a package in an open-source repository does not confirm its credibility." (checked Oct 2026)

And: "Trivial cross-referencing methods (i.e., comparing a generated package name with a list of known packages) are ineffective for detecting a package hallucination attack, as an adversary may already have published the hallucinated package with malicious code." (checked Oct 2026)

It's not only typos, either. The paper found "the majority of hallucinations are not merely trivial typographical errors but are substantively different from existing package names." (checked Oct 2026) So a fake name can look perfectly sensible.

Step 1: Don't install straight away

Our advice, not a vendor quote: when an AI suggests a package you don't know, stop before you run the install. Copy the name and look it up first. If your tool asks permission to run an install command, say no until you've checked.

Step 2: Look the package up yourself

Our advice, not a vendor quote: search for the name on the registry's own site (npmjs.com for JavaScript, pypi.org for Python). Then ask: does it have a real description, a linked source repository, more than one release, and a history longer than a few days? Is it the package the library's own docs tell you to install? If anything feels off, ask the AI for a well-known alternative, and check that one too.

On npm, look for provenance. npm's search docs say: "The package homepage also displays provenance information when available." (checked Oct 2026) The provenance docs explain it: "This allows developers to verify where and how your package was built before they download it." (checked Oct 2026)

But provenance isn't a safety stamp: "When a package in the npm registry has established provenance, it does not guarantee the package has no malicious code. Instead, npm provenance provides a verifiable link to the package's source code and build instructions, which developers can then audit and determine whether to trust it or not." (checked Oct 2026)

Step 3: Commit your lockfile and read its diff

For npm, package-lock.json records exactly what got installed. The npm docs say it "describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates." And: "This file is intended to be committed into source repositories" (checked Oct 2026)

That also helps you spot new packages. One of its purposes is to "Facilitate greater visibility of tree changes through readable source control diffs." (checked Oct 2026) For how to read a diff, see How to review AI-written code before you keep it.

For Python, pip has a hash-checking mode. The pip docs say to "Enable Hash-checking Mode, by passing --require-hashes" and that "This mode uses local hashes, embedded in a requirements.txt file, to protect against remote tampering and network issues." (checked Oct 2026) Our advice, not a vendor quote: hashes protect the packages you already chose. They won't tell you if the name you chose was a fake one.

Step 4: Run the audit tools, and know their limits

For npm, the npm audit docs say: "The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities." (checked Oct 2026)

npm audit
npm audit signatures

About the second one, the same page says: "Registry signatures can be verified using the following audit command:" npm audit signatures. (checked Oct 2026)

Be careful with npm audit fix --force. On --force, npm says: "If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!" (checked Oct 2026)

On GitHub, dependency review "lets you catch insecure dependencies before you introduce them to your environment, and provides information on license, dependents, and age of dependencies." It shows "Which dependencies were added, removed, or updated, along with the release dates" and "How many projects use these components". (checked Oct 2026)

Our advice, not a vendor quote: these tools look for known problems. The docs say audit reports "known vulnerabilities" and dependency review tells you about "known vulnerabilities". A brand-new fake package may have no report yet. So the age and use counts in dependency review are as useful here as the vulnerability check.

Step 5: Tell the AI your rules

Our advice, not a vendor quote: put a line in your project instructions file like "Don't add new packages without asking me first, and name the package's official docs page when you suggest one." Then check that page yourself. For instructions files and do-not lists, see How to stop AI coding tools breaking your code.

A quick checklist

Our advice, not a vendor quote:

Don't run the install yet.
Look the name up on the registry and in the library's own docs.
Check its age, source link, releases and (on npm) provenance.
Install, then read the lockfile diff.
Run npm audit (or your ecosystem's audit tool) and, on GitHub, read the dependency review.
If it's wrong, undo with git. See Git basics for AI coders.

We haven't tested these steps hands-on. This guide collects what the research and the package tools' docs say.

Not affiliated with or endorsed by npm, GitHub, the Python Packaging Authority or the paper's authors.