Slopsquatting: How to Stop Your AI Installing Fake Packages

Ask an AI coding tool for help and it will often suggest a package to install. Most of the time the package is real. Sometimes it is not, and the invented name sounds so plausible that an attacker has already registered it, with malware inside. The attack has a name, slopsquatting, and coding agents make it easier to fall for, because the agent is often the one typing the install command.

Below: what slopsquatting is, the numbers behind the "one in five" headline, why agents raise the stakes, and the checks, gates and lockfile habits that close the hole.

What slopsquatting is

Typosquatting waits for a human to mistype a real package name, such as reqeusts instead of requests. Slopsquatting does not wait for a mistake; it predicts one. The attacker collects package names that AI models invent, registers the ones that keep coming back, and waits for someone to paste the model’s suggestion into a terminal.

The term was coined in 2025 by Seth Larson of the Python Software Foundation, according to this write-up on dev.to, which is a good overview of both the attack and the defences.

What makes it work is predictability. If models invented a different fake name every time, there would be nothing worth registering. They do not.

The numbers behind "one in five"

The figure comes from a study presented at USENIX Security 2025, We Have a Package for You!, which analysed package hallucinations by code-generating models. As summarised in the dev.to article:

• 576,000 code samples generated by 16 models were analysed.
• 19.7% of the packages the models recommended did not exist.
• Those included 205,474 unique non-existent package names.
• When the same prompt ran ten times, 43% of hallucinated names came back every time.
• Open-source models hallucinated far more, up to around 22%, than the best commercial model tested, GPT-4 Turbo at 3.59%.

The 43% repeat rate is the number to remember. An attacker does not need to guess. They can run popular prompts, collect the names that keep appearing, and register them before anyone else does.

The same article reports a 2026 re-evaluation of frontier models with lower rates, between 4.6% and 6.1%, and 127 package names that five different frontier models hallucinated identically. Lower is better, but it is not zero, and identical hallucinations across vendors are exactly what an attacker hopes for.

Where the fake names come from

Hallucinated package names are not random strings. Models learn the naming habits of each ecosystem, the -sdk and -utils suffixes, the framework prefixes, the way helpers are named after the library they extend, and they generate new names that fit those habits perfectly. The dev.to article gives aws-helper-sdk and fastapi-middleware as examples of the kind of names models produce: each one sounds like something that should exist.

According to the same write-up, about 38% of hallucinated names were conflations of two real packages and about 13% were simple typos of real ones. The rest were plausible inventions. That mix is why a quick glance does not protect you: a conflated name looks familiar precisely because both halves are real.

Why coding agents raise the stakes

A person copying a suggestion has a moment of friction: they read the name, perhaps search for it, then paste. An agent with shell access has no such moment. It decides a dependency is needed, runs the install, and moves on, often in the middle of a long task you are not watching line by line.

Volume matters too. Even at a 5% rate, an agent that proposes 40 packages across a project is likely to propose at least one that does not exist: if each suggestion were independent, the odds would be about 87%. Most of those will simply fail to install. The danger is the one that installs fine because someone registered it first.

Agents also write documentation. A hallucinated package that lands in a README or a setup guide gets copied by the next person and read by the next model, which is how one invented name spreads.

Check a package before it touches your machine

These checks take seconds once they are a habit, and they are exactly what you should ask your agent to do before any install.

• Does it exist, and since when? For npm, npm view <package> time.created prints the date the package was first published. For PyPI, the JSON API at pypi.org/pypi/<package>/json lists every release with its upload time.
• Is anyone using it? npm’s public downloads API at api.npmjs.org/downloads/point/last-week/<package> returns last week’s downloads. A brand-new package with a handful of downloads that your model calls the standard way to do something is a red flag.
• Does it point to a real repository? npm view <package> repository.url should lead to source code with a history, issues and more than one contributor.
• Does the name blend two popular names? Many hallucinations are plausible mash-ups of real packages. If the name sounds like a helper for a famous library, check whether that library already does the job.

The dev.to article also recommends age-gating: rejecting any package first published within about 90 days unless a human approves it. Almost every dependency you genuinely need is older than that.

Gate the agent, not just the human

The strongest fix is to make dependency changes a decision the agent has to ask for. In Claude Code, permission rules in settings.json can require your approval for specific commands. Rules use the same wildcard form as the documented example Bash(npm run test *), so an ask list such as Bash(npm install *), Bash(pnpm add *) and Bash(pip install *) makes every install pause until you approve it.

Pair it with one rule in your AGENTS.md or CLAUDE.md:

"Never add a dependency without first confirming it exists on the registry and telling me its first publish date, weekly downloads and repository."

The permission makes the pause mandatory. The rule makes sure the agent arrives at the pause carrying the evidence. Other coding agents have equivalent approval settings, and the principle is the same whatever you use: an agent can suggest a dependency, but a human adds it.

Lock it down in your project and CI

• Install from the lockfile. Commit it, and use npm ci in CI: it installs exactly what the lockfile says and fails if the lockfile and package.json disagree.
• Pin with hashes in Python. Install with pip install --require-hashes so a package cannot change under a familiar name and version.
• Turn off install scripts by default. Use npm install --ignore-scripts, or npm config set ignore-scripts true, and allow scripts only for packages that need them. Many malicious packages do their damage in a postinstall script.
• Review new dependencies. A pull request that adds a package should say why, and someone should look at that package, not only at the diff.
• Scan the supply chain. Tools such as Socket flag new, suspicious or lookalike packages before they merge.
• Use an allowlist for teams. Route installs through a private registry or proxy such as Verdaccio with a list of approved packages.

A five-minute setup if you build alone

Most of the list above assumes a team with CI and code review. If it is just you and an agent, this is the short version, and it takes about five minutes:

1. Add ask rules for npm install, pnpm add and pip install to your user-level Claude Code settings, so every project inherits them.
2. Add the one-line dependency rule to the AGENTS.md or CLAUDE.md of each project you work in.
3. Run npm config set ignore-scripts true once, and re-enable scripts only for the packages that genuinely need them.
4. Commit your lockfiles, and reinstall with npm ci rather than npm install when you set up a fresh machine.
5. Once a week, look at what changed in package.json or requirements.txt in your git history. A dependency you do not remember adding is worth a minute of checking.

If you think you already installed one

Treat it like any other compromise, quickly and in order:

1. Remove the package, delete node_modules or the virtual environment, and reinstall from a lockfile you trust.
2. Rotate every secret that was available in that environment: API keys in .env files, cloud credentials and tokens in your shell. Install scripts run with your user’s permissions and can read them.
3. Check what the package’s install scripts did, and look for new files, startup items or scheduled jobs on the machine.
4. Report the package to the registry so it is taken down before the next person installs it.

Practical takeaways

• Models invent package names, and many invented names repeat, which is what lets attackers register them in advance.
• Rates are falling with newer models, but not to zero, and agents install far more packages than people paste.
• Check age, downloads and repository before any new install, and make your agent show you that evidence.
• Make installs an approval step for your agent, never an action it takes on its own.
• Lockfiles, hashes, disabled install scripts and dependency review close most of the remaining gap.

Conclusion

Slopsquatting is a new name for an old lesson: never run code you have not checked, even when a confident assistant tells you to. What changed is the volume and the speed. Your agent can add a dependency faster than you can read its name, so the checks have to live in your settings and your CI, not in your attention.

For more practical notes like this, get the HelloBuilder newsletter. It lands every Monday.