Ask an AI assistant for code and it will sometimes import a library that sounds exactly right and has never existed. The install fails, you move on. The interesting part is what happens when it does not fail.
Package hallucination: why the invented names repeat
It is the newest of the five routes into a software supply chain, and the one that did not exist five years ago.
Language models produce plausible text, and a package name is text. When a model needs a library for image resizing, a name shaped like a real image-resizing library is a very likely completion — whether or not anyone ever published it.
Two properties turn that from a nuisance into an attack. First, the invented names are not random: ask many models the same kind of question and the same plausible names recur, because they are all drawing on similar training data and similar naming conventions. Second, package registries let anyone claim an unused name instantly.
The recurrence has been measured. Published research on package hallucination in LLM-generated code has found that a substantial share of recommended package references point at something that does not exist, and — the part that matters — that many of the invented names reappear on repeated runs of the same prompt. Repeatable is the property an attacker needs: a name that appears once is a nuisance, and a name that appears reliably is a target that can be registered in advance.
So an attacker collects the names models hallucinate, registers them, and publishes something that works — plus an install script. The next developer whose assistant suggests that name gets working code and a payload. The technique is called slopsquatting, after the AI slop the names come from.
Why the checks you already have do not catch it
This is the part that matters when evaluating tooling, because two existing defences look like they should apply and do not.
Typosquatting detection is blind to it. Typosquatting works by measuring edit distance: reqeusts is one transposition from requests, so it is flagged. A hallucinated name is not a misspelling of anything. It is a well-formed, sensible name for a library that simply does not exist. There is nothing close by to compare it to.
Malware feeds are reactive. An advisory naming a package as malicious exists only after somebody analysed it and reported it. On the day the attacker publishes, no feed names it. That window — between publication and detection — is precisely when the assistant is recommending it.
Both defences are worth having. Neither sees this.
The one thing an attacker cannot fake
A history.
A package registered last week to catch hallucinated imports has, necessarily, been on the registry for a week. It cannot have years of releases, a long issue history or a slow accumulation of dependents, because those take time and time is the one input that cannot be forged.
So the signal is age, and it should be the only trigger: a direct dependency first published within roughly the last ninety days deserves a look. Not because new packages are bad — the overwhelming majority are entirely innocent — but because this particular attack cannot avoid the property.
Everything else that looks suspicious about such a package should be treated as an aggravating factor on a young package, never as a finding on its own:
- Install scripts. Code that runs at install time, before you have run anything yourself. On a package published last week, this is the strongest single signal available.
- No source repository. Nothing to read, nothing to check.
- A single maintainer account created around the same time as the package.
Applied to established packages, each of those would produce constant noise — plenty of respectable libraries have install scripts and one maintainer. Applied to a package that is nine days old, they are the difference between "probably fine" and "look at this now".
The corollary is that this finding should expire. Once the package ages past the window, the alert resolves itself and the ordinary advisory and malware checks take over the watch. A permanent warning about a package that has now been around for a year is noise.
If your assistant installs packages on its own, this is one of the reasons that permission is worth deciding deliberately.
What to do about it in practice
The habit worth building is small: when an assistant suggests a dependency you have not heard of, look it up before installing rather than after. Check the registry page for the publication date, the number of releases and whether a source repository exists. That is thirty seconds, and it catches the great majority of this class.
Beyond habit, a lockfile helps more than it looks. It pins exactly what was installed, so the question "when did this arrive and who added it?" has an answer in version control rather than in someone's memory.
What is slopsquatting?
Slopsquatting is an attack that exploits AI coding assistants inventing package names that do not exist. Because models hallucinate the same plausible names repeatedly, an attacker can register those names on a public registry and publish working code with a malicious payload. The next developer whose assistant suggests that name installs the attacker's package. The name comes from the AI slop the invented names originate in.
Why does typosquatting detection not catch hallucinated packages?
Typosquatting detection works by edit distance — it flags a name that is one or two characters away from a popular package, such as a transposition or a doubled letter. A hallucinated package name is not a misspelling of anything: it is a well-formed, sensible name for a library that simply never existed, so there is no nearby real package to measure it against. The check has nothing to compare it to.
How can I tell if a package suggested by AI is real?
Look the package up on its registry before installing rather than after, and check three things: when it was first published, how many releases it has, and whether it links to a real source repository. A package created within the last few months, with one release and no repository, deserves scepticism — particularly if it runs an install script. That check takes about thirty seconds and catches this entire class of attack.
Are new packages always dangerous?
No. Newly published packages are not inherently dangerous, and treating them that way would make the signal useless. The overwhelming majority of newly published packages are entirely innocent, which is why age alone should raise a look rather than an alarm, and why aggravating factors such as install scripts, a missing source repository or a brand-new maintainer account matter only in combination with youth. The alert should also expire once the package has been around long enough to have a real history.
Where CodeControl fits
CodeControl checks the registry creation date of every direct dependency and raises a package-reputation finding for anything first published within ninety days. Age is the only trigger; install scripts, a missing source repository and a lone maintainer are reported as aggravating factors on a young package rather than as findings against an established one. The finding resolves itself once the package ages out, from where the malware and advisory checks carry the watch. It sits alongside typosquatting and dependency confusion detection.