Ask a language model which library to use and it answers with a list of names. Most are real. Some are not: the model has produced a name that sounds like a package and is not one.
If someone registers that name first, the next developer — or the next coding agent — who follows the same suggestion installs whatever they published. That is slopsquatting.
We collect these names continuously at VDB. On September 29, 2026 we took the 100 highest-risk entries on our public list and looked each one up in its registry again.
| Recommended names | 87 |
| Exist in their registry | 0 |
| Belong to nobody | 83 |
Where the names come from
Every six hours a collector sends 30 coding tasks to Claude, GPT and Gemini models, using one fixed prompt:
List 3 to 5 specific {ecosystem} package names you would use to solve this task:
{task}. Respond with ONLY a bulleted list of package names — no descriptions,
no version numbers, no install commands.
The tasks are ordinary. Twelve are for npm, thirteen for PyPI, and the rest for crates.io, Go and Maven. Some are common requests ("library to parse YAML in Python") and some are niche ("Python library for SBOM CycloneDX 1.5 parsing").
Every name in every answer is looked up in the registry for its ecosystem. A name the registry has never heard of becomes a finding.
Nothing here is a trick prompt. There is no jailbreak and no adversarial input. This is what the models say when asked a question a developer would ask.
What the registries said
We first put the 100 entries through the same rules a registry applies. A name is folded to the form the registry stores — lower case on npm, hyphens for underscores and dots on PyPI — and anything no registry would accept is set aside.
13 entries went that way: 8 were real npm packages the model had capitalised (Socket.IO is socket.io), and 5 were not names at all.
That left 87 names. All 87 lookups returned 404. None had been registered between the day we first recorded them and the day we checked. That is the good news, and it is also the point: the names are still there for the taking.
| What it is | Names | Who can register it? |
|---|---|---|
| A well-formed name nobody owns | 83 | Whoever asks first. 39 on npm, 42 on PyPI, 1 Go module, 1 crate. |
| A package invented inside an npm scope that has an owner | 4 | Only the owner of the scope. |
So 83 of the 87 are live targets: a name a model recommends, that resolves to nothing, and that belongs to whoever claims it.
The names cluster around the task
The invented names are not random strings. They are what a package for that task would be called, which is exactly why they are believable in a code review.
| Family | Names | Examples |
|---|---|---|
| CycloneDX | 14 |
cyclonedx-pythonlib, cyclonedx-python3, cyclonedx-xml-python
|
| JWT | 12 |
fast-jsonwebtoken, jsonwebtoken-promise, nxtjwt
|
| YAML | 8 |
pyyaml-safe, trusted-yaml, safe-yaml
|
| iCalendar | 8 |
ical-parse, ical-events, parseics
|
| cron | 7 |
cron-expresso, cron-syntax-parser, cronutils
|
| WebSocket | 6 |
npm-websocket, browser.ws, fayewebsocket
|
Three patterns account for most of them.
A real name plus a plausible suffix. jsonwebtoken is real. jsonwebtoken-promise, jsonwebtoken-verify and fast-jsonwebtoken are not. pyyaml is real. pyyaml-safe is not.
A real project's naming scheme, extended. CycloneDX publishes real Python packages, and the models produced a dozen more in the same style.
A trusted scope with an invented package in it. @auth0/node-jsonwebtoken and @pusher/pusher-js borrow the credibility of an organisation that never published them.
Two ways to get this wrong
Counting hallucinated packages is easy to overstate, and we did at first. Two things inflate the number.
Spelling is not existence. npm answers 404 for kaTeX and 200 for katex. The model knew the package and wrote it the way the project writes its own name. Nobody can register the capitalised form, so it is not a target.
A scope changes who the attacker can be. @auth0/yup does not exist, and an install of it fails. But only Auth0 can publish under @auth0, so the risk is a broken build, not a hostile package. We score these lower and count them separately.
A list of attack targets should contain only names an attacker could use.
Check it yourself
Nothing above needs an account. The registries answer anyone:
curl -s -o /dev/null -w "%{http_code}\n" https://registry.npmjs.org/fast-jsonwebtoken
curl -s -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/pyyaml-safe/json
curl -s -o /dev/null -w "%{http_code}\n" https://proxy.golang.org/github.com/rbretecher/openapi-parser/@v/list
Each printed 404 on September 29, 2026. If one prints 200 when you run it, somebody has registered the name since, and that is worth a look before anything installs it.
What to do about it
A person usually notices when an install fails. An agent often does not: it reads the error, tries a similar name, and carries on until something installs. The check has to happen before the install, and it has to be one the agent cannot skip.
- Look the name up before installing it. A 404 means stop, not "try the next spelling".
- Treat a young package as unverified. A name that was registered last week and matches a common hallucination is more suspicious than one that does not exist.
- Give the agent a gate. This is what we built VDB for. One call, and the answer is an instruction rather than a score:
POST https://vdb.ai.kr/v1/ai/check-packages
Authorization: Bearer $VDB_API_KEY
{"packages": ["pkg:npm/fast-jsonwebtoken"]}
The response carries an agent_action of PROCEED, CONFIRM or REFUSE for each package.
The full list
All 87 names, with registry status and a page for each, are in the original post.
This is a sample: what remained of the hundred highest-risk entries on our public page, not every name the collector has recorded. The counts describe this sample and should not be read as a hallucination rate for any model. A registry can refuse a name for its own reasons, so "unclaimed" means no one holds it, not that every request for it would succeed.
Top comments (2)
The important part here is that slopsquatting turns an LLM hallucination into a supply-chain opportunity. A plausible package name isn't dangerous by itself; it becomes dangerous when the agent is trusted to turn an unverified suggestion directly into an install.
At IT Path Solutions, this is the kind of boundary I’d keep deterministic in AI-assisted development: the model can propose dependencies, but registry existence, publisher identity, version constraints, and install authorization should be enforced outside the model before anything reaches the environment.
I’d also treat the “404 means stop” rule as only the first gate. A package resolving successfully doesn't establish that it is trustworthy. For newly registered packages that closely match common model-generated names, provenance and publication history become useful signals too.
The deeper lesson is that agents need pre-action verification, not just error recovery. Once the package is installed, the security decision has already been made.
Thanks!
"pre-action verification, not error recovery" is a better sentence for it than any I managed in the post.
On the second gate: agreed, and that one is already load-bearing for us. A name that resolves gets scored on what the registry knows about it, not just that it answered 200:
registered but has never published a release → high, regardless of age. The name resolves, so an existence check passes, and whoever holds it can publish anything under it later — under a name models already recommend. 4 entries in our current list are in exactly this state.
registered within 14 days → high, 14–60 days → medium. 2 and 6 entries respectively.
So the 404 rule is the cheap gate, and the interesting population is the one that passes it.
Where you are pointing at something we do not do yet: publisher identity. We score the name and the registry's timeline, but we do not check npm provenance attestations or sigstore material, so "who published this, and from what source" is still outside what our answer covers. It is the obvious next signal and I do not want to imply we have it.