A coding assistant invents the same fake package run after run

The package it told you to install was never published

Ask several AI assistants how to use a popular machine-learning service from the command line and they would tell you to install a tool called huggingface-cli. No such package exists. The real tool ships inside another one and installs under a different name, pip install -U "huggingface_hub[cli]". The invented name was plausible, confidently given, and wrong. A security researcher, Bar Lanyado, found four different models recommending it.¹

Two words here need their plain meanings. A package is a bundle of reusable code a developer installs rather than writes. A registry is the public index it installs from, PyPI for Python and npm for JavaScript, and an install command or an import line names a package by a string. When the assistant writes a name that is not in the registry, it has hallucinated a package.

This is not a lookup that fetched the wrong entry. A plain assistant has no index inside it to consult. When it answers, it predicts the next piece of text from patterns fixed in its weights, with no step that checks a registry. The lesson on why a model invents a fact it never stored covers that, and the lessons on calling a tool and looking something up at answer time cover the steps that would let it check. The point here is narrower. If the assistant only predicts plausible text, you would expect a fresh piece of nonsense each time, a different wrong name on every run. That is not what happens. Ask again and the same invented name comes back. This lesson answers why a package that was never real keeps returning, and what that repetition makes possible.

Re-run the prompt and the same invented name returns

A study presented at USENIX Security in 2025 measured this directly. Its detection test is blunt: take every package name a model writes in generated code and compare it against a master list of real names from PyPI and npm. A name not on the list counts as a hallucination.² Across 16 models and 576,000 code samples, 19.7% of the roughly 2.23 million package names the models recommended did not exist, 205,474 distinct names in all.²

The figure the thesis needs is about repetition, not the overall rate. The authors took 500 prompts that had each produced at least one hallucination and re-ran every one ten times. In 58% of cases the same invented package came back in more than one of the ten runs, and 43% came back in all ten. A separate 39% never recurred. Those three figures are separate readings of the same rerun set, not shares that sum to a whole.² They point the same way: for most invented names, recurrence is the rule. Each model tends to reproduce its own set of fake names rather than spray fresh ones.

The repetition does not stop at one model. Lanyado's earlier study found 215 hallucinated names shared by more than one of the four models he tested.¹ A 2026 re-evaluation of current frontier models found 127 names that all five models invented identically.³ The invention is stable within a model, across models, and across two generations of them.

Why would a name pointing at nothing be a stable guess? Because the draw that picks each next word is not a uniform roll over every string the model could write. The model ranks the possible continuations by probability and mostly takes from near the top. For a given run of code, one plausible-looking name can sit far above the rest, the most probable way to continue whether or not it names a real package. Run the prompt again and the same top-ranked name tends to win. The study found a matching effect: the hallucination rate rose with sampling temperature, the setting that makes the draw more random by flattening the ranking.² Turn the randomness up and the model is likelier to wander off its favorite.

That the same names recur is measured and firm. Why one particular invented string becomes a model's stable favorite, token by token, is not something the study settles. It rests on how the model's probabilities happen to be shaped, reasoning built on the base mechanism rather than a demonstrated fact of its own. Treat the recurrence as established and the deeper why-this-exact-name as open.

A predictable name is one an attacker can register before you do

Security researchers gave the resulting risk a name: slopsquatting, registering a package name that an assistant is known to hallucinate so that a developer following the assistant installs the attacker's package believing it is real.⁴ The term is credited to Seth Larson of the Python Software Foundation and was popularized by Andrew Nesbitt, according to the security reporting.⁴⁵

The attack runs in four steps. The assistant writes a plausible fake name inside otherwise working code. The developer trusts it and runs the install. An attacker who has catalogued the names assistants commonly hallucinate has already claimed one on the registry. The install now pulls the attacker's code instead of a missing-package error.⁴ The recurrence is the hinge. A name that appeared once and never again would be worthless to register; a name that comes back reliably is a fixed address. As Lanyado put it, persistence, the repetition of the fake name, is what turns the behavior into a functional attack.⁶

The researchers treat the name list as dangerous themselves. The study's authors released their code and data but withheld the master list of the 205,474 names and the per-prompt results, citing supply-chain risk, and gate access behind researcher verification.⁷ The people who measured the names will not hand them out.

How much of this has actually happened? As of these sources, no malicious slopsquatting attack has been documented in the wild.⁵ The one hallucinated name known to have been registered was Lanyado's own proof of concept. He uploaded an empty, harmless package as huggingface-cli, and it drew more than 30,000 downloads in three months, even appearing in the published install instructions of a real project.¹ His summary is the honest one: "I have yet to identify an exploit of this attack technique by malicious actors."⁶ Every ingredient is present and the install step is proven on a harmless package. A malicious campaign is plausible, not observed.

The scary rate is an average from older open models

One figure from the study gets quoted on its own: about one in five recommended packages was hallucinated. That 19.7% is an average, and the spread under it matters more. Commercial models, the GPT series, hallucinated 5.2% of the time; open-source models averaged 21.7%, about four times as often.² The average sits near the open-source figure because 13 of the 16 models tested were open source. The round number most likely to be repeated is pulled up by models most readers are not using.

It is also falling. A 2026 re-evaluation of current frontier models put their rates between 4.62% and 6.10%.³ Treat any single rate as a reading for a particular model at a particular time.

The threat does not shrink at the rate's pace. That same 2026 group still produced 127 names all five models invented, and 53 were still registrable after the registries' existing defenses.³ A lower rate with stable, registrable names is still a fixed address an attacker can sit on.

The fix is to let the assistant check the registry

The cause is a missing check, so the fix is to supply one. Ground the assistant in the real registry and let it confirm each name against what exists, through the tool call and live-lookup steps the earlier lessons cover. The study's tested mitigations did roughly this. Retrieval-augmented generation cut one open model's rate from 16.14% to 12.24%, and fine-tuning it against its own past hallucinations cut it to 2.66%, about an 85% reduction.² Asked directly, models can also flag their own inventions: GPT-4 Turbo caught its hallucinated names with 89% precision and recall, GPT-3.5 around 82%, lower for the open-source models.²

A plain registry check is not the end of it. Some invented names are registrable, and once an attacker has registered one, the name passes a yes-or-no lookup. Recent work scores how likely a name is to be fake, rather than returning a yes-or-no answer, from registry signals such as a package's age and release history.⁸ A strict lookup waves through a name that is suspicious but registered, and the probability score is meant to flag it. How far the base rate can fall is still moving: the study found Python hallucinated less than JavaScript, 15.8% against 21.3%, and the frontier figures are a point in time, not a floor.²³ What is settled is why the assistant invents a name and that the same name recurs. What is open is how low the rate can go and why a particular fake name becomes the favorite. The reader's defense does not wait on any of that: confirm that a recommended package exists and is what it claims before you install it.⁹