Slopsquatting: when your AI assistant installs a package that does not exist

Ask a coding assistant for help and it will often suggest a library along with the code. Most of the time the library is real. Sometimes it is not: the model produces a name that sounds right, follows the naming conventions of the ecosystem, and simply does not exist on npm or PyPI. If you run the install command without looking, one of two things happens. The install fails, which is annoying but harmless. Or someone has already published a package under that exact name, and you just ran their code.

What slopsquatting is

Slopsquatting is the name for that second case: registering package names that AI models tend to invent, and waiting for people to install them. The term is usually credited to Seth Larson, the Python Software Foundation’s security developer-in-residence, and it plays on typosquatting, where attackers register misspellings of popular packages. The difference is who makes the mistake. With typosquatting a person mistypes. With slopsquatting a model confidently suggests the wrong name, and a person trusts it.

The risk is not hypothetical. In a widely reported experiment, a researcher noticed that models kept recommending a package called huggingface-cli, which is not how the real Hugging Face tool is installed. He published an empty package under that name to see what would happen, and it was downloaded tens of thousands of times. The package was harmless. A malicious one would not have been.

How often models invent packages

The most thorough study so far is “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”, presented at USENIX Security 2025. The authors generated 576,000 code samples in Python and JavaScript with 16 popular models and checked every package the code referred to. They found that the average share of hallucinated packages was at least 5.2% for commercial models and 21.7% for open-source models, and they collected 205,474 unique package names that did not exist.

Two details from the paper matter more than the headline numbers. First, the invented names are often repeatable: when the authors re-ran prompts that produced a hallucination ten times, 43% of those names came back every single time. Predictable names are exactly what an attacker needs. Second, most of them are not near-misspellings of real packages, so a typo check will not catch them. Only about 13% were within one or two characters of an existing name.

Models have improved since those experiments, and assistants that search the registry before suggesting a package make the problem rarer. Rarer is not the same as gone, especially for niche tasks where the model has seen few real examples.

Why the attack is practical

Publishing to npm or PyPI is free and takes minutes. An attacker does not need to compromise anything; they only need to guess names that models produce and register them first. Install scripts then do the rest: npm runs preinstall and postinstall scripts by default, and a Python package can run code when it is built or imported. A single install on a developer laptop or a CI runner can expose SSH keys, cloud credentials and tokens in environment variables.

Agents make this sharper. When an assistant can run npm install or pip install itself, there may be no human looking at the package name at all.

Check a package in a minute

Before you add a dependency you did not choose yourself, look it up in the registry:

# npm: does it exist, who publishes it, when was it first released?$ npm view some-package name version time.created repository.url # PyPI: same questions, from the JSON API$ curl -s https://pypi.org/pypi/some-package/json | jq '.info | {name, version, home_page, project_urls}'

Then ask a few quick questions:

• Does it exist at all? A 404 means the name was invented. Do not create it, and do not install a “close enough” alternative without checking that one too.
• Is it brand new? A package first published in the last few weeks, with one version and no history, deserves a second look, especially if its name matches what your assistant suggested.
• Does it point to a real project? A linked repository with commits, issues and other users is a good sign. An empty or missing repository is not.
• Is it the package the docs tell you to install? The real tool’s own documentation is the best source for the correct name. huggingface-cli versus the documented install command is a good example of why.

Habits that help

• Use lockfiles and install from them in CI (npm ci, pip install -r with pinned versions and hashes), so a new name cannot slip in during a build.
• Review dependency changes in pull requests as carefully as code changes. A diff that adds three packages deserves three lookups.
• Ask your assistant to link the package’s registry page or official docs when it suggests something new. It is a cheap way to surface a made-up name.
• If your agent can run installs on its own, give it an allowlist or require confirmation for new dependencies.
• Consider disabling install scripts by default (npm config set ignore-scripts true) and enabling them only for packages that need them. It breaks some packages, so test it first.

Automate the boring part

Manual lookups work for one package. They do not scale to a repository with hundreds of dependencies, or to imports buried in code an assistant generated last week. This is a good job for tooling.

vetkit’s AI code risks suite looks up the dependencies and imports in your manifests on public registries such as npm and PyPI. It flags names that do not exist, versions that were never published, and packages first released in the last 30 days. Only package names and versions are sent to the registries, never your source code, and packages from private registries or your own workspaces are not looked up. The vetkit MCP server also exposes a package check, so an assistant can verify a name before it installs anything.

Whatever you use, the principle is the same: a package name that came from a model is a claim, and claims are cheap to verify before you run them.