Slopsquatting

What is slopsquatting?

Slopsquatting is a supply chain attack in three steps. A language model writes code that installs a package that does not exist. The name it invented is not random, so the same kind of prompt produces the same fake name again on the next run. An attacker registers that name on npm or PyPI, puts something malicious inside it, and waits for the next developer or coding agent to run the install command.

Nothing about the name looks wrong. It reads like the package you would expect to exist, which is why the model produced it: react-codeshift sounds like the codemod tool for React, and nobody has ever maintained one under that name.

The word comes from an April 2025 conversation between Andrew Nesbitt of the Ecosyste.ms package data project and Seth Larson, security developer in residence at the Python Software Foundation, about what a registry's 404 logs reveal: which non-existent packages developers are really trying to install. Larson suggested the name and it stuck.

What the research actually measured

The number everyone repeats comes from a study presented at the USENIX Security symposium in 2025 by a team from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech. They ran 16 models, generated 576,000 code samples in Python and JavaScript, and checked every package reference against the PyPI and npm registries.

What they measured is the share of package references that pointed at nothing: at least 5.2 percent on average for the commercial models and 21.7 percent for the open source ones, over 205,474 distinct invented names. That is a rate per package reference in generated code, not a rate per project, and it says nothing about how often an attack succeeds.

Their second experiment matters more. They took 500 prompts that had already produced a hallucinated name and ran each one ten more times. 43 percent of the invented packages came back in all ten runs, and 39 percent never came back at all.

A one-off hallucination is worthless to an attacker. A name that comes back every time is a target an attacker registers once and then leaves sitting there.

Newer models invent fewer names but have not stopped. A 2026 replication on five frontier models released between October 2025 and March 2026 measured rates between 4.62 and 6.10 percent: the gap between the best and the worst model closed, and the floor did not reach zero.

Slopsquatting versus typosquatting

Both attacks register a name and wait. The difference is whose mistake they are waiting for.

Typosquatting waits for a human hand. Someone means to type requests and types reqeusts. There is a correct spelling to compare against: the real name exists, you simply missed it.

Slopsquatting waits for a machine to invent a name that was never real, so there is no correct spelling to fall back on. In the USENIX data only 13.4 percent of the invented names sat within one or two character edits of a real package, and nearly half were six edits or more away. A check that looks for names suspiciously close to popular ones walks straight past them.

Two invented names that got registered

In December 2023 a researcher at Lasso Security registered huggingface-cli on PyPI as an empty, harmless package, after noticing that models kept recommending it. The real tool installs under a different name. It picked up over 15,000 downloads in three months, and the README of Alibaba's GraphTranslator repository was telling readers to install it.

The second case shows what changes when an agent does the typing. In October 2025 a public collection of agent skills picked up two entries telling an agent to run npx react-codeshift, a blend of jscodeshift and react-codemod. Both of those are real. The blend never was. By the time Charlie Eriksen at Aikido Security claimed the name in December 2025 to keep it out of other hands, it had spread to more than 237 repositories through people cloning and editing the skill files, and it still pulled one to four downloads a day from agents following the instruction literally.

Where does a name like that die in a normal workflow? Not in code review, because nobody was reading a diff. npx does ask before it downloads something new, and people answered yes. It dies one step earlier: the moment a package that is not already in your lockfile turns up in an install command, the install stops and a person reads the name.

Keeping an invented name out of the build

These controls are in the order they help.

1. A lockfile and installs that refuse to improvise. npm ci needs an existing package-lock.json, never writes to it, and errors out when the lockfile and package.json disagree. With pip's --require-hashes, every requirement including every transitive one has to be pinned to a version with a hash. A package nobody added on purpose cannot arrive quietly.

2. An allowlist or an internal mirror. Point the build at your own proxy rather than the public registry, so a new package comes in through a request instead of a download.

3. An identity check before it enters the build. How old is the account behind the name, how many releases has it had, does the repository it names point back. Three weeks old, one release and no history is the shape of a slopsquat.

4. Human review of new dependencies specifically. Reviewing a diff and reviewing a dependency are different jobs. A 900 line diff gets skimmed. A pull request saying this adds one package you have never used is a thirty second decision, and it is the only check that catches a name no scanner has seen yet.

What to watch out for with slopsquatting

An agent removes the pause. A developer who hits an install error goes looking and searches the odd name. An agent that installs and runs in one step never stops there. The approval prompt meant to save you stops working once it fires fifty times a day, and the fifty-first answer is yes.

Invented names spread by copying. A wrong install line in a README or a skill file gets cloned, and from then on people repeat it rather than the model. That is how one name reached 237 repositories.

The control is not to stop writing code with AI. It is that no new dependency enters the project without somebody looking at it. That rule was worth having before models wrote code, and it needs no security budget: a lockfile committed to the repository, and one named person who reads the dependency changes in a pull request.