Your agent — Cursor, Claude Code, Lovable, Replit, whichever — tells you to run npm install some-plausible-package or pip install some-plausible-package to fix an import error. It sounds exactly like every other dependency it’s ever suggested. You run it. It installs. No error, no warning.
The problem: that package doesn’t officially exist yet — or it does, but someone other than its “real” maintainer registered it after watching AI tools recommend it. Either way, you just ran code from a stranger with API keys, cloud tokens, and your .env file sitting right there in the environment.
If you searched “npm install package doesn’t exist AI,” “ai suggested a fake package,” or “is slopsquatting real,” this is that problem, and it’s not a one-off glitch in one tool. It’s a measured, repeatable failure mode of how these models generate code.
Why agents invent package names with a straight face
A model writing code isn’t looking anything up in real time by default — it’s predicting the next plausible token based on patterns in its training data. Most of the time that produces a real, correctly-spelled package name, because real package names are what it saw most. But when your exact use case doesn’t map cleanly onto anything in its training data, it fills the gap with something that looks like it could exist: right naming convention, right prefix, right general shape as a solution to your problem. It’s not lying — it has no internal “does this exist” check to fail. It’s pattern-completing, and sometimes the completion is fiction.
This has been measured directly. A 2025 USENIX Security study ran 16 different code models — commercial and open-source — across 576,000 generated code samples and found that roughly 1 in 5 recommended packages didn’t exist on the registry the model implied (npm, PyPI, crates.io, Go modules). It’s not evenly random noise either: 58% of the hallucinated names repeated across multiple, differently-worded prompts. The same fake package gets suggested again and again — which is exactly what makes it exploitable.
Why a “harmless” typo became a supply-chain attack
Security researchers watched this pattern and named it slopsquatting — the AI-era cousin of typosquatting. Instead of registering lodash- with a typo and hoping for a fat-fingered install, an attacker watches which fake names models repeatedly hallucinate, registers that exact name on the real registry, and ships it with a malicious postinstall script. No typo required — the AI already did the work of pointing thousands of developers at the name.
This isn’t hypothetical. Security researcher Bar Lanyado registered a package under a name he’d watched multiple LLMs hallucinate — huggingface-cli — as an experiment. It picked up over 30,000 downloads in three months, from real developers whose agent had confidently recommended it. A clean pip install or npm install with no errors is not evidence a package is legitimate or safe — it just means the registry accepted the name and the install script ran, which is also exactly what a credential-stealing payload needs to happen.
The three checks, before you run the install
1. Confirm the package actually exists on the registry — not just that the install command didn’t error. npm install and pip install will happily install a package that was registered five minutes ago by nobody you’d trust. Before running what the agent suggests, look it up yourself: npm view <package> repository homepage (a real, actively maintained package has both — a hallucination-turned-squat often has neither, or fields that were filled in yesterday) or check the PyPI project page directly for maintainer history and release cadence, not just “does a page exist.”
2. Check the numbers, not just the name. A package with 40 downloads and no repository link that supposedly does exactly what you need, with a name that sounds like it was built for your prompt, is the profile to be suspicious of — legitimate packages that solve common problems tend to have thousands of downloads and a maintained GitHub repo behind them, not a name that materialized to match your exact phrasing.
3. Read what the agent is about to run, not just the result. Skim the actual install command and the package.json/requirements.txt diff before accepting it, the same way you’d review any other code change the agent proposes. If a name is unfamiliar and the agent can’t point you to real docs for it (ask it directly: “link me the official docs for this package” — a hallucinated package has no real docs to link, and a model will often reveal the gap when pushed instead of asked to just reassure you), treat that as the flag it is rather than assuming the agent verified it for you. It didn’t — it can’t, not from inside the same generation pass that produced the suggestion.
If you already ran the install
Don’t just remove it and move on — assume the postinstall script already ran with your environment’s access. Rotate any credentials that were reachable from that shell (API keys in .env, cloud CLI tokens, npm/PyPI auth tokens) before you do anything else. Then remove the package and its lockfile entry, and re-lock (npm ci against a corrected package.json, or a fresh pip freeze after reinstalling from known-good names) so the bad entry doesn’t silently survive in a cached lockfile.
Make it hard to repeat
Pin your lockfile and commit it (package-lock.json, poetry.lock, or equivalent) so a future agent suggestion can’t silently swap in a different resolved version without you seeing the diff. When an agent proposes a new dependency, treat the suggestion the same way you’d treat a PR from someone you’ve never worked with: check the registry page, check the maintainer, check the download count — then install. It costs you thirty seconds. A credential-stealing postinstall script costs a lot more.
Comments
Sign in to join the conversation.
No comments yet — be the first.