The short version. AI coding assistants confidently recommend packages that do not exist. They hallucinate a plausible name, pip install it, done. The problem is that a hallucinated name is predictable, and an attacker can register it first. The next developer who trusts the same suggestion installs the attacker's code. This is a supply-chain attack with a new and very cheap entry point, and it is best stopped at the moment of install, before the malicious package ever runs.
A new door into the oldest attack
Supply-chain attacks are not new. Typosquatting, where an attacker registers reqeusts and waits for a fat-fingered requests, is a decade old. What is new is that AI coding assistants have created a far more reliable version, and named it for us: slopsquatting.
Here is the mechanism. You ask an assistant to write code that does X. It generates code that imports a library to do X. Sometimes that library does not exist; the model invented a plausible name, the way it invents a plausible citation. The developer, trusting the assistant, runs the install command. If the package is not there, they move on. But if an attacker has already registered that exact hallucinated name, the developer just installed attacker-controlled code, with whatever install scripts and dependencies the attacker chose, straight into the build.
The security research is already in. A USENIX Security 2025 study by Spracklen and colleagues measured package hallucination across Python and JavaScript and found it common, and, crucially, repeatable. The same model, given similar prompts, hallucinates the same names. Repeatable means predictable. Predictable means an attacker does not have to guess; they can generate the model's hallucinations in advance and register the ones worth registering.
Why this is more dangerous than classic typosquatting
Typosquatting relies on human error, one developer mistyping one name. It is a numbers game with a low hit rate.
Slopsquatting relies on machine consistency, and that changes the economics in the attacker's favor:
- The target names are predictable. An attacker can run the popular assistants at scale, collect the packages they hallucinate, and pre-register the plausible, unclaimed ones. No guessing.
- The victim trusts the source. The name did not come from a typo. It came from an AI assistant the developer is relying on to be right. Trust in the tool transfers to trust in the name.
- It scales with adoption. Every new developer leaning on AI-generated code is a new potential victim of the same pre-registered names. The attack gets more valuable as assistants get more popular.
- It lands early and deep. A malicious package installed during development runs with the developer's privileges, on the build machine, inside CI. That is about the best position an attacker could ask for.
The result is a supply-chain attack where the reconnaissance is done by the defender's own tools, and the attacker just has to be there first.
Detection after the fact is too late
The instinct is to scan installed dependencies and flag the bad ones. That is worth doing, but it is the wrong place to stop this. By the time a slopsquatted package is installed, its install-time scripts have already run. On the build machine. With whatever access the build has. Post-install scanning finds the fire after the house is warm.
The right place to intervene is before install, at the moment a package is about to be pulled in. That is the only point where you can refuse a package that has the fingerprints of a hallucination without having already executed it.
What does a slopsquat look like at that moment? It tends to be a package that is plausibly named for what the code needs, recently registered, with little history, few downloads, and no established maintainer, appearing in a dependency list that an AI assistant just wrote. None of those signals is damning alone. Together, at install time, they are enough to say "hold on, confirm this one."
The defensible version: a squattability model, applied pre-install
The useful frame from the research is squattability: a name is a real risk only if it is reproducibly hallucinated (models actually suggest it), plausible (it looks like something that should exist), and registrable (nobody legitimate has claimed it). A name that fails any of those is not a practical attack. A name that passes all three is a loaded gun sitting in a public registry.
A defense worth deploying does two things. It extends the hallucination measurement beyond the original Python and JavaScript study to the ecosystems your teams actually use. And it turns the model into a pre-install gate: before a dependency is added, check it against the squattability signals and the known-hallucination set, and stop the risky ones before their install scripts run.
How Nemesis fits
Nemesis Red already flags hallucinated and slopsquatting-risk dependencies as part of assessing AI- assisted code, and the approach it takes is the one that matters: catch the risky package by its squattability signature, reproducibly hallucinated, plausible, freshly registrable, rather than waiting to detect malice after the code has run. The same signal belongs at the developer's install step and in CI, as a pre-install check, so a hallucinated dependency is refused before it ever executes on a build machine.
We are honest about scope. This does not replace software composition analysis or a full SBOM program; it closes a specific, fast-growing gap those tools were not built for. And no single signal is proof. The point is to raise friction at the exact moment, pre-install, where friction is cheap for a legitimate package and fatal for a slopsquat.
What to do about it now
- Treat AI-suggested dependencies as untrusted input. The assistant is a productivity tool, not a package authority. A recommended import is a claim to verify, not a fact.
- Gate installs, do not just scan them. Add a pre-install check in developer environments and CI. Stopping the package before its scripts run is the whole game.
- Confirm new, low-history packages by hand. Especially ones that appeared in AI-generated code. A thirty-second check beats an incident.
- Watch the ecosystems you actually ship in. The original study covered Python and JavaScript. Your exposure is wherever your developers let an assistant choose dependencies.
The uncomfortable summary: your developers' most trusted new tool is generating package names, and some of those names are traps that attackers can set in advance. The fix is not to distrust the assistant. It is to refuse the package at the door, before it runs, when refusing is still free.
Nemesis Red flags hallucinated and slopsquatting-risk dependencies by their squattability signature, before they run. Part of the autonomous, proof-gated offensive engine from Nemesis Labs. nemesislabs.xyz