AI coding tools suggested six fake npm package names in a 30-prompt slopsquatting test

A hands-on slopsquatting test

A developer writing on dev.to ran a small experiment to measure how often AI coding assistants recommend packages that do not exist. The risk being probed is known as "slopsquatting": a model invents a plausible package name, an attacker registers that exact name on npm or PyPI with malicious code inside, and a developer installs it because their assistant suggested it. According to the post, the term was coined by Seth Larson of the Python Software Foundation, and it differs from typosquatting in one key way — no human mistypes anything, because the error comes from the model itself, delivered with confidence.

What the test found

The author tested three tools — Claude (Haiku 4.5), GitHub Copilot running its default model, and ChatGPT with Codex defaults — against 30 everyday programming tasks such as parsing a PDF, validating an email address or rate-limiting an API, all aimed at the npm/JavaScript ecosystem. Every suggested package name was extracted and checked against the npm registry using a small lookup script written for the purpose. Nothing that failed the check was ever installed.

Across the 30 prompts, the three tools produced six nonexistent package names in total: three from ChatGPT/Codex, two from Claude and one from GitHub Copilot. The author frames the numbers as a signal rather than a verdict, given the small sample, and deliberately declined to publish the invented names, arguing that a list of unregistered names that AI tools like to suggest is effectively a shopping list for attackers.

Overlap turns a glitch into a target

The result the author found most surprising was repetition. Two of the fake names were suggested by more than one tool. If hallucinated package names were pure random noise, two independent products landing on the same nonexistent name should be rare — yet it happened twice in 30 prompts. That is what separates an exploitable pattern from an ordinary bug: a random mistake is hard to act on, but a repeatable one is a target.

The post also cites a recent preprint, not yet peer-reviewed, which reported that five different large language models invented the same 127 package names. That earlier finding points in the same direction: hallucinated package names cluster rather than scatter, which makes them predictable enough to squat on.

A successful lookup is not a safety check

Alongside the six outright fakes, two suggested packages did exist on the registry but were either very new or had almost no downloads. The author's takeaway is that "it exists" and "it is safe" are different questions. A package registered last week, sitting quietly in the registry, could itself be exactly what an attacker wants a developer to find.

A short defense checklist

The post closes with practical defenses. Never paste an AI-suggested install command without checking the package first. Inspect creation date, maintainers, download counts and repository links — the author shows how with npm's view command and PyPI's JSON metadata endpoint. Treat new or low-traffic packages as untrusted and read them manually. Commit lockfiles and review dependency diffs in pull requests the way code is reviewed. And add a dependency scanner to CI so a bad name gets flagged before it ships.

The author recalls one fake name from the test that looked completely convincing: nothing about it felt wrong, instincts raised no alarm, and only the registry lookup caught it.

Why it matters

AI assistants are now a routine channel through which dependencies enter a codebase, and this test suggests they occasionally hand developers package names that exist nowhere. The absolute numbers are small, and most suggestions were real, but the attack only needs one hit: one plausible name, registered first by someone else, installed without a second look. The overlap between tools is the more worrying signal, because it implies the most attractive targets are also the most predictable. Until models stop inventing packages, a plain registry lookup remains the cheapest defense available — and, as the author found, often the only one that works.