Slopsquatting: attackers register package names that AI agents hallucinate

AI coding assistants occasionally invent package names that were never published, and attackers have noticed. According to a recent post on dev.to, they are registering those hallucinated names on public registries and then simply waiting for someone, increasingly an autonomous agent, to run the install command. The practice has been dubbed "slopsquatting", a younger sibling of typosquatting.

How the attack works

Typosquatting counts on a human mistyping a popular package name. Slopsquatting counts on a model inventing one. The assistant proposes a library with complete confidence, the generated code includes an install command, and whatever now occupies that name on npm or PyPI gets pulled onto the machine. The risk grows when an agent in the workflow is allowed to execute npm install or pip install without a human in the loop, the dev.to post points out.

What to check before an install

For each name an agent proposes, the post recommends a short screening routine:

• Existence. If the registry has never heard of the package, that is the hallucination scenario — stop there.
• Age and history. A package published days ago with a single version warrants scrutiny, especially if its name sits close to a popular one.
• Maintenance. The date of the last release shows whether anyone still looks after it.
• Advisories. Public databases list known security advisories per version.
• Adoption. On npm, weekly download figures make it easy to tell the actual lodash apart from a copycat.

All of these checks can be run by hand against each registry's API. The snag, the post notes, is that every registry formats its answers differently, which gets tedious across npm, PyPI, crates.io, Go, Maven and NuGet.

A single normalized check

To avoid that tedium, the post's author built "Package Safety Checker", an endpoint on RapidAPI that returns one response shape for all six ecosystems. The answer covers whether the package exists, its latest version and release date, its age in days, version count, npm weekly downloads, licences, deprecation status, and any known advisories with their severity. It ends with a verdict — ok, caution or not-found — plus the reasons behind it. A second endpoint screens up to ten packages in a single call, suited to an agent queuing a batch of dependencies at once. The free tier allows 50 checks per month. Since the service is the author's own, it is one option among several; the same checks remain possible directly against the registries.

A simple policy for agents

Wiring the check into an agent takes one rule, the post suggests: if the verdict is not-found, refuse to install; if it is caution, surface the reasons to a human before proceeding.

Screening is not a guarantee

The post is candid about its limits. A package can be old, widely used and free of advisories today and still be compromised tomorrow. Version pinning, lockfiles and healthy suspicion of install scripts all still matter. What the check does remove is the most common failure mode: installing a dependency that never existed at all.

Why it matters

Slopsquatting inverts the economics of package attacks. An attacker no longer needs victims to make a typo; they only need to register the names that models tend to invent, knowing the same fabrication is likely to reach many developers. As coding agents gain permission to run installs autonomously, the gap between a hallucinated import and an executed install shrinks to nothing. A registry check before every install is a cheap, automatable gate — and according to the dev.to post, it blocks the most common way this new attack vector succeeds.