Resolve every dependency version an AI assistant gives you against the registry before it reaches a lockfile. Models produce version strings the same way they produce everything else, by predicting plausible text rather than querying a registry, so a number that looks exactly like a real release can be one that was never published. Most of the time that breaks your install and costs you ten minutes. The reason it belongs in an AI code security conversation rather than a build-tooling one is what happens when somebody is waiting at the other end of that invented name.
Three ways a suggested version can be wrong
It helps to separate the failure modes, because they need different responses. A Codacy analysis of dependency version selection splits the problem into three: stale, bleeding edge, and non-existent.
A stale version is real but old. The model has anchored on whatever release was most widely documented when its training data was collected, which is often a version with public advisories against it by the time you install it. A bleeding edge version is real but premature: a release candidate or a brand new major that your other dependencies have not caught up with. A non-existent version has never been published to any registry at all. The number is syntactically perfect, it follows the project’s own versioning pattern, and resolving it returns nothing.
Only the third one is a hallucination in the strict sense, and it is the one this piece is mainly about. The first two are judgement problems you fix by reading the changelog. The third is a different category, because a version that does not exist today can be made to exist tomorrow by somebody who is not you.
What the measurements actually show
As BleepingComputer reported, a large share of the recommended packages did not exist, producing a long list of unique fabricated names. The detail that matters more than the headline rate is the repeatability: when the researchers re-ran prompts that had produced a fake package, many of the hallucinated names came back on repeat runs. These are not random noise. They are stable, predictable outputs that an attacker can enumerate.
Version hallucination specifically is where the numbers are worst, and that is not surprising. A package name is a thing a model has seen thousands of times in prose. A version string is a short, highly patterned token that a model can generate convincingly without ever having seen that particular release.
Where this becomes an AI code security problem
A broken install is an inconvenience. AI code security becomes the issue at the point where the invented name stops being invented.
Slopsquatting is the name for registering a package under a name that a model reliably hallucinates, so that the next developer who copies the suggestion installs something an attacker controls. It differs from typosquatting in one important way: there is no misspelling to notice. The name looks right because the model generated something plausible, and plausible is precisely what gets waved through in review.
The proof that the attack path works predates the attack itself. Security researchers have shown that simply registering a package under a name a model reliably hallucinates is enough: once it is live, developers who copy the model’s suggestion install it without ever searching for it themselves. Nobody installed it because they found it. They installed it because a model told them to.
As of the current research, there is no confirmed large-scale slopsquatting campaign attributed to a threat group. What exists is the groundwork: enumerable targets, repeatable hallucinations, and a workflow in which people install what they are told without checking. Treating that as safe because nothing has happened yet is the same reasoning that leaves credentials in a repository because nobody has cloned it.
For versions, the attack surface is narrower but the same shape. An attacker who sees a model consistently recommend a version of a real package that the maintainer has never published can, in some registries and some circumstances, publish it. Your install stops failing, which is the worrying part, because a failing install is the only signal most teams have.
Check before you install, not after
The cheapest control is also the dullest. Before you run the install, resolve the exact name and version against the registry and look at what comes back. For npm that is a view of the published versions; for PyPI it is the release history on the project page. You are asking two questions: does this version exist, and does it come from the project you think it does.
It takes seconds, and it is the one habit that makes the rest of the problem small. The reason it does not happen is not difficulty. It is that an AI assistant producing an install command feels like a tool reporting a fact, when it is a tool producing a guess. The same mistake shows up with method signatures, which is why AI coding tools invent APIs that do not exist in exactly the same way and for exactly the same reason.
A few other things reduce the hit rate without much effort. Lower temperature for code generation: industry reporting links higher randomness settings to higher hallucination rates, so there is no reason to leave a creative setting switched on for dependency work. Pin exact versions rather than ranges, so that what you reviewed is what gets installed.
Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-10-30. Some passages are the author's opinion. Spotted an error? tell us.
Frequently asked questions
- How do I check whether a version an AI suggested actually exists?
- Look it up in the registry before installing. For npm, view the published version list for the package; for PyPI, check the release history on the project page. You are confirming two things: that the version exists, and that the package belongs to the project you expected.
- Is this the same as typosquatting?
- No. Typosquatting relies on you mistyping a real name, so a careful reader can spot it. Slopsquatting uses a name a model reliably invents, which means the name looks entirely plausible and there is no misspelling to catch.
- Do newer models still invent package versions?
- Yes, at lower rates. The 2026 PyPI Security and Socket preprint found package hallucination rates between 4.62% and 6.10% across five frontier models, down from the 19.7% average in the 2025 USENIX study but not close to zero. Version numbers specifically fare worse than package names.
- Can I just let CI catch unresolvable versions?
- A clean install from the lockfile in CI will catch versions that do not resolve, and that is worth having. It will not catch a version that resolves because somebody published it to exploit the pattern, which is why dependency scanning and a registry allowlist sit alongside the build check rather than behind it.