AI suggested an npm or PyPI package that doesn't exist: what to do

An AI assistant tells you to run npm install react-pdf-fast-viewer. You run it and it works. But did the AI know about a real package, or did it make up a name that someone else then registered?

Why this happens

Language models write package names that sound right. Usually they’re real, but sometimes the name is invented: a plausible mix of words that no one ever published. Researchers have documented this and given it the name package hallucination. Nothing stops an attacker from asking AI tools for code, noticing which package names they invent, and registering those names with malware inside. This is called slopsquatting.

The old version of the same trick is typosquatting: a package named one character away from a popular one, waiting for someone to mistype it.

Installing a package means running someone else’s code. npm packages can run scripts during install, and anything you import runs with the full access of your app. On your laptop that can mean your files and tokens. In a build it can mean your deployment secrets. On the server it can mean your production database.

How to check your own app

Do this for each package the AI added, and for anything already in your project that you don’t recognise.

1. Is there an official source telling you to use it? Search the name together with the tool it claims to work with. The framework’s own documentation is the best source, since it will name the real package.
2. Look it up on the registry. On npmjs.com, check:
   • when it was first published and how often it releases
   • weekly downloads (a package that “everyone uses” doesn’t have 12 downloads a week)
   • a repository link that opens a real project with real history
   • who maintains it, and whether the name on the package matches the project
3. Ask npm directly. For a name that doesn’t exist, this prints a 404:

npm view some-package-name
npm view some-package-name time.created maintainers repository.url
npm view some-package-name scripts

The last command lists install scripts such as preinstall or postinstall. A small utility with an install script that does something unexplained deserves a closer look.

4. Check download counts without opening a browser.

curl https://api.npmjs.org/downloads/point/last-week/some-package-name

5. For Python, open https://pypi.org/project/some-package-name/ and look at the release history, the project links and the maintainer. pip index versions some-package-name also tells you whether the name exists.
6. Review what the AI changed. After a session with an AI tool, run git diff package.json and look at every added line. List the full tree with npm ls --all if you want to see what each new package pulled in.
7. Check spelling against the docs. Compare the exact name, character by character, with the project’s own install instructions.

Warning signs: created in the last few weeks, a version number like 0.0.1, almost no downloads, no repository, a repository that doesn’t mention the package, or a README that is mostly generic text.

The fix

1. Verify before you install

Make “look it up first” a habit, particularly when the AI uses a package name you’ve never seen. If the real library has a different name, use that. If you can’t find any official source, write that small piece of code yourself or ask the AI for an approach that uses standard libraries.

2. Commit your lockfile and install from it

Commit package-lock.json (or the lockfile for pnpm or yarn). In builds and on your host, use:

npm ci

npm ci installs exactly what the lockfile says, and fails if package.json and the lockfile disagree. Plain npm install in a build can pull in a different version than the one you tested. Pin the versions of anything you add by hand, and review lockfile changes in pull requests like you would review code.

3. Consider turning off install scripts

npm ci --ignore-scripts

This blocks preinstall, install and postinstall scripts in your dependencies, which is where much malware runs. Some packages, such as those that compile native code, need their scripts, so you may need to run them for those packages only. pnpm 10 and later skips dependency install scripts by default and lets you list the packages that are allowed to run them.

4. Turn on automated checks

• Dependabot (or a similar tool) opens pull requests for outdated and vulnerable dependencies. Enable it in the repository’s security settings.
• npm audit lists known advisories in your dependency tree.
• Behaviour-based scanners look at what a package does, such as install scripts, network calls, obfuscated code and brand-new maintainers, rather than only matching known advisories. Several vendors offer these as GitHub apps or command line tools. They are the one category that can flag a package before it appears in any advisory.

None of these replace step 1 for a package you’re adding for the first time.

5. Keep secrets away from install steps

Don’t keep production keys in the environment where you run installs on your laptop. In CI, give the install step only the variables it needs. If a package does turn out to be bad, there will be less to steal. See secrets committed to GitHub if any key might already have leaked.

Mistakes to avoid

• Trusting a package because the AI sounded sure. Confidence isn’t evidence that the package exists.
• Installing the first search result. Typosquats can rank for the real name plus a word like “official”.
• Using npm install in your deploy pipeline when a lockfile is available.
• Ignoring lockfile changes. A new package you didn’t add on purpose is worth a question.
• Treating npm audit as a safety certificate. A clean report means there are no known advisories, not that every package is safe.