Slopsquatting: When Your AI Assistant Invents a Package and an Attacker Registers It

Here is a short program that ends in a compromised laptop. You ask a coding assistant to solve a problem. It writes code that imports a library — something plausible, say pip install requests-oauth-helper. You run it. The install succeeds. The code works. What you don’t know is that no such library existed until last week, when someone who studies what these models invent registered that exact name on the package index and filled it with malware. The model hallucinated a dependency; an attacker was waiting on the other side of the hallucination.

This is slopsquatting, and it is one of the more elegant nasty ideas in software security right now — a supply-chain attack that exists only because AI coding tools are confidently, repeatably wrong about which packages are real. The name was coined by Seth Larson, security developer-in-residence at the Python Software Foundation; “slop” is the now-standard pejorative for low-quality AI output, and “squatting” borrows from its older cousin, typosquatting. The mechanism is new, the blast radius is large, and the fix is refreshingly boring. Let’s take it apart.

How a hallucinated import becomes an attack

The chain has four links, and none of them requires the attacker to breach anything you own:

1. The model invents a package. Asked to write code, an LLM suggests importing a library that sounds real but doesn’t exist. This is ordinary hallucination, the same failure that still hasn’t been solved in prose, applied to dependency names.
2. An attacker harvests the invented names. Because the hallucinations are predictable — more on that below — a bad actor can run popular prompts, collect the phantom names the models keep producing, and pick the ones most likely to be typed into a terminal.
3. They register the name for real. They upload a malicious package under that exact name to PyPI, npm, or another registry. Registration is free and instant, and nobody vets it on the way in.
4. You install it. The next developer who gets the same suggestion runs the install command. What should have failed with “no such package” now succeeds — with the attacker’s code executing during install or first import.

The quiet horror of it is that step four feels like success. A typo-squat announces itself the moment you notice you fat-fingered reqeusts. A slop-squat is the code doing exactly what the trusted assistant told you to do. There is no mistake to catch, because from your side nothing went wrong.

Why a model invents a library that isn’t there

It helps to understand why this happens, because the mechanism is what makes it predictable enough to weaponise. A language model doesn’t look packages up; it predicts plausible text. Package names are highly compositional — python-jwt, fast-redis, aws-s3-utils — so a model that has ingested thousands of real ones learns the shape of a package name and will cheerfully generate a new one that fits the shape perfectly while corresponding to nothing on any registry. From the inside there is no difference between recalling requests and confabulating requests-oauth-helper; both are just high-probability strings given the surrounding code.

Two things sharpen the danger. The model has no built-in step that checks whether a name actually resolves to a real package before recommending it, so nothing catches the invention on the way out. And because the same training patterns and the same popular prompts recur, the same “plausible” name tends to surface again and again rather than scatter randomly. A failure that was merely embarrassing in prose becomes an exploitable, stable target the moment it names a thing you’re about to install — which is exactly the property the numbers below confirm.

How often models actually invent packages

You might hope this is a fringe failure. It isn’t. The most thorough study to date — presented at USENIX Security in 2025 — ran 16 large language models across 576,000 generated code samples and checked every package they suggested. The models recommended packages that don’t exist roughly 5.2% of the time for commercial models and 21.7% of the time for open-weight ones, adding up to 205,474 unique hallucinated package names. Better-funded, closed models hallucinate less, but “less” here still means one invented dependency in every twenty suggestions. Point an open model at a big codebase and the odds you’ll be handed at least one phantom import approach a certainty.

Volume alone wouldn’t make a good attack, though. Randomly-different hallucinations each time would be almost impossible to squat, because you couldn’t predict which name to register. The lethal finding is that the hallucinations are stable. When researchers re-ran the same prompt ten times, 43% of the hallucinated package names came back every single time, and only 39% never reappeared. A phantom name that shows up on all ten runs isn’t noise; it’s a reliably-manufactured target. The model will keep recommending it to the next thousand developers, and the attacker only has to register it once.

It’s worth placing this in a family. Security teams have long known about dependency confusion — tricking a build into pulling a public package in place of an internal one — and about typosquatting, which preys on misspellings. Slopsquatting is the newest sibling: same payoff, different lure. The study found the problem across both Python and JavaScript, the two ecosystems most exposed to open public registries, and the gap between commercial and open-weight models isn’t mysterious. Larger, more heavily tuned models have simply been reinforced harder against confidently stating things that aren’t so. But “harder” is not “perfectly”, and one invented package in twenty is a lot of loaded chambers when the thing pulling the trigger is an automated install.

Why it’s worse than a typo

Typosquatting has been around for years, and the ecosystem has partial defences against it — registries watch for near-misses on popular names. Slopsquatting is nastier for three reasons, and they stack.

First, the name is plausible, not a slip. The model doesn’t misspell numpy; it invents numpy-utils or fast-json-parser, names that sound like things that ought to exist. There’s nothing to squint at. Second, the AI vouches for it. A suggestion carrying the implicit authority of a tool you’re paying for disarms the scepticism you’d apply to a random blog. Socket’s researchers noted an especially bleak loop: search one of these fake names and Google’s own AI Overview may confidently summarise it as a useful, well-maintained library — one AI rubber-stamping another AI’s invention, with no human in the chain who ever confirmed the thing is real.

Third, and most important, the workflow has removed the checkpoint. “Vibe coding” — prompt, copy, run, move on — is now the default for a lot of people, and autonomous agents go further, installing the dependencies they pick without asking. The moment a human stops reading the package names before they hit the registry, the last line of defence is gone. This is the same structural weakness we flagged with prompt injection and data poisoning: the attack surface isn’t the model’s cleverness, it’s the trust we extend to its output and the steps we skip because it feels fast.

It’s not hypothetical

The building blocks are all documented. Socket recorded an incident in which Google’s AI Overview recommended a malicious npm package that was squatting on a legitimate one — an AI actively steering users toward attacker-controlled code. Separately, a threat actor was found automating the creation of thousands of typo- and hallucination-style fake packages, using ChatGPT to generate realistic-sounding variants of real library names at scale and publishing tutorials on how to weaponise them. The economics are brutal in the attacker’s favour: registering a package costs nothing, the models mass-produce plausible targets for free, and a single successful install can mean credential theft, a crypto-wallet drain, or a foothold in a CI pipeline.

The npm case is worth dwelling on, because it shows the full loop closing. The malicious package there squatted on a real, popular one by a single character, and it was Google’s own AI — not a careless human — that surfaced it to searchers. Separately, a threat actor documented a playbook for building a botnet out of malicious npm packages, having used ChatGPT to generate thousands of realistic-sounding variants of genuine library names at scale, complete with video tutorials. That is the asymmetry in one sentence: the defender must be right every time a name is typed, while the attacker gets an AI to generate the bait, another AI to vouch for it, and a human in a hurry to run it.

To be fair to the ecosystem, this is being fought. The Python Software Foundation has funded dedicated security engineering on PyPI — malware-reporting APIs, better typosquat detection, partnerships with security teams — and firms like Socket scan for these packages by analysing what the code actually does. But registry defence is a race, and the supply of hallucinated names refills every time a model is updated. Larson’s own assessment is sober: we can’t even measure how many bad installs are happening because of hallucinations without more transparency from the model providers than we currently get.

What actually reduces the risk

The good news is that this attack is uniquely defeatable, because it depends entirely on you not looking. A handful of unglamorous habits close it off:

• Verify before you install. Before running any AI-suggested pip install or npm install, confirm the package exists and look at its age, download counts, repository, and maintainers. A brand-new package with no history and a suspiciously on-the-nose name is the whole attack, sitting in plain sight.
• Pin and lock everything. Commit a lockfile with exact versions and hashes. If a dependency wasn’t deliberately added and pinned by a human, it shouldn’t enter the build. Lockfiles turn “the model added something overnight” into a reviewable diff.
• Never pipe AI output straight to a shell. The gap between “the model suggested this” and “this executed on my machine” is where you get to be a human. Don’t automate it away.
• Constrain the agents. If you run coding agents that can install packages, put them behind an allowlist or a private mirror of vetted dependencies, so a hallucinated name simply can’t resolve to the public internet.
• Scan the supply chain. Use tooling that inspects package behaviour, not just names, so a malicious install is caught even when the name looks clean.

At a team level, the same logic scales up. Route installs through a curated internal proxy so that a package has to be vetted once before anyone — or any agent — can pull it; treat a new external dependency as a change that needs a human review, not a thing that appears in a diff overnight; and don’t let CI install from the open internet on the strength of an AI’s say-so. There is also an honesty problem worth naming: Larson’s own point is that nobody can currently measure how many bad installs are happening because of hallucinations, because the model providers don’t publish the data that would let anyone check. Until they do, defenders are fighting a threat whose size is deliberately fuzzy — which is its own small argument for treating every AI-suggested dependency as unproven until you’ve looked.

None of these are exotic. They are the same disciplines that separated careful teams from careless ones before AI arrived; the assistant has only raised the cost of skipping them. That is the honest lesson of slopsquatting, and it applies well beyond security. These tools are genuinely useful, and they are also confidently wrong at a measurable, repeatable rate — a rate that other people can and do build businesses on. The productivity is real, and so is the tax; the 10x-developer pitch quietly assumes you’ll pay the second one by checking the work. Slopsquatting is what the bill looks like when you don’t.