Hallucinated Packages: When AI Invents a Library

The measurement

The foundational research on this won a distinguished award at a 2025 security conference, and its sample is large enough to be taken seriously.

576,000 generated code samples, 16 models, two languages, thirty different tests. Those produced 2.23 million package references in total — and of those, 440,445, or 19.7%, pointed at a package that does not exist. The number of unique invented names: 205,474.

The breakdown tells you where the risk sits:

The gap between closed and open-weight models is fourfold. A more recent 2026 replication on five new models squeezed that spread down by an order of magnitude — to between 4.62% and 6.10% — but it did not make the phenomenon go away.

The repetition that turns this into an attack

This is the most important number in the article, and most summaries leave it out.

The researchers picked 500 prompts at random that had caused a hallucination, and ran each of them ten times again. The three figures below come from separate cuts of the study, which is why they do not add up to exactly a hundred.

• 43% of the invented names came back in all ten runs, identically.
• 39% did not repeat even once.
• Overall, in 58% of cases the invented name showed up at least twice.

If hallucination were random noise, slopsquatting would not work: by the time the attacker registered the name, the model would be inventing something else. But it is not random. Close to half the names get invented reliably, over and over, in exactly the same form.

That is what makes it predictable — and that is why it can be registered.

And this is not a typo

Here comes the second surprise, and it rewrites the defence as well.

Only 13.4% of the invented names sit within one or two characters of edit distance from a real package name. The majority are not a misspelled version of an existing name, but plausible-sounding names that never existed.

The distribution of types: roughly half are pure fabrication, more than a third are conflation (the names of two real packages crossed), and only the remainder look like typos. Within those types there is a sneakier subtype too: 8.7% of the names invented for Python really do exist — just in the JavaScript ecosystem. The model carries the name across from one registry to the other.

This has a very concrete consequence: the defence built against typosquatting — filtering by name distance — largely lets this through. What the package registries run for that purpose does not protect you here.

What has actually happened so far

There are three cases worth knowing about, and a fourth finding that matters more than all of them.

The proof of concept that got 30,000 downloads. In 2024 a security researcher uploaded a completely empty package under a frequently hallucinated name. In three months it received more than 30,000 real downloads — and a large technology company copied the install command into the description of its own repo. It took neither malice nor marketing: the model recommending it confidently was enough.

The 2026 twist: agent instruction files. In January 2026 a researcher defensively registered a name born from the crossing of two real packages. The name spread through AI-generated agent instruction files, was copied along by forks into 237 repos, and even got translated. Agents tried to install it daily. There was no malicious content in it.

That is the "why now" part: an invented name today no longer escapes from one developer's chat window, it escapes from instruction files that nobody reads and that forking multiplies.

One suspicious package. In the first half of 2026, the registry placed a security hold on a JavaScript package — a hallucinated, shortened variant of a real plugin. It was running at around two hundred downloads a week. The person who found it is careful with words: "a potentially deliberate slopsquatting attack". The intent could not be proven.

And the fourth finding: up to July 2026 no case had been reported in which slopsquatting was actually used as a cyberattack.

That has to be said out loud. Slopsquatting today is a proven mechanism without documented exploitation.

How big is this risk, really?

It is worth putting two numbers side by side.

On the "traditional" supply chain side, more than 454,600 new malicious packages were identified during 2025, and more than 99% of them appeared in the same ecosystem. Against that, slopsquatting has a single suspicious package.

So slopsquatting is not the biggest risk today. But there is one way in which it differs from everything else: it scales with model usage, not with the attacker's effort. The more people ask for code, the more invented names go into circulation — and the attacker still has nothing to do but ask the model.

How exposed are you

Let us work it out. Suppose a developer asks fifty questions a month that come back with a package installation suggestion.

WITH AN OPEN-WEIGHT MODEL (21.7%):
  hallucinated suggestion:     50 × 0.217 = ~11 / month
  of those, stably repeating:  11 × 0.43  =  ~5 / month

WITH A CLOSED MODEL (5.2%):
  hallucinated suggestion:     50 × 0.052 = ~2.6 / month
  of those, stably repeating: 2.6 × 0.43  = ~1.1 / month

(Own calculation, with the ratios from the measurement above.)

Five invented names a month that the model will reliably invent again and again — which means names an attacker can predict in advance and register. Model choice makes a fourfold difference. Neither choice takes it to zero.

The defence that actually works

The good news is that the most effective protection is not new, and you probably have half of it already.

Lockfile and hash verification. This works because it rests on simple logic: an invented package name is by definition not in the lockfile. If the build installs only from the lockfile, the agent's invented package never gets in — the build breaks. Which is exactly the behaviour you want.

In the two big ecosystems it looks like this:

• On the JavaScript side, CI has to use the lockfile-based variant instead of the ordinary install. That one requires an existing lockfile, stops with an error if it diverges from the package descriptor, and never overwrites either of them — the install is effectively frozen.
• On the Python side, hash-checking mode is the equivalent. There, every requirement needs a hash, partial hashing does not exist; anything not written out and hashed causes an error; and every version has to be pinned.

Four further, cheap measures:

• The registration date. It is suspicious if a package was created thirty to ninety days before your project started and has barely any downloads.
• An internal proxy registry with an allowlist. What is not on the list does not get in.
• The agent must not be able to install a package without human approval. This is a permission setting, not a matter of policy.
• Lower temperature for code generation. Less creativity in the naming.

What the registries do — and what they do not

Through 2025 and 2026 both big package registries tightened up considerably: on the JavaScript side all legacy access tokens were revoked, login now issues a two-hour session token, CI tokens live for at most ninety days, and token-free trusted publishing became the recommended path. On the Python side more than fifty thousand projects were already using that in 2025, a fifth of uploads arrived that way, and two thirds of malicious reports were handled within four hours.

But one thing has to be stated precisely: we found no registry-side measure aimed specifically at slopsquatting. Everything listed above is general supply chain hardening. And the typosquatting detection on the Python side works on name distance — and by now you know why it will not catch this: 86.6% of the invented names are nowhere near one or two characters from a real name.

Common misconceptions

• "This is only a problem with the bad, open models." The difference is fourfold, but even with closed models you get one or two predictable invented names per developer per month.
• "The defence against typosquatting catches this too." It does not. 86.6% of the invented names are not misspellings but names that never existed.
• "It is random, so it cannot be exploited." 43% of the names come back identically in ten runs out of ten.
• "There has already been a big attack from it." Up to July 2026 none had been reported. A proven mechanism, without documented exploitation.
• "The registries will sort it out." They have hardened a great deal, but there is no measure aimed specifically at this, and the existing name-distance filter lets it through.

What to take away

Slopsquatting is dangerous not because the model hallucinates but because it hallucinates the same thing predictably. That is what makes the name registrable. The protection, on the other hand, is cheap and old: a lockfile, hash verification, and checking the name before anything is installed — with the agent not installing on its own. The lockfile and the hash protect the build: there the invented package never gets in, the build breaks on your behalf. The main case in this article is the other one, you running the suggested install command by hand, and that is caught only by the check before installation: once the command goes in, the install script has already run.

The wider security picture is what the security bill of AI code post sets out; and the steps of the manual review are where the going through generated code post takes over.