What is slopsquatting? When a model invents a package

By

Slopsquatting is registering a package name a language model invented, so a later install of that name runs someone else's code. What a 2025 study measured.

Slopsquatting is registering a package name that a language model made up. The name was not on npm or PyPI when the model wrote it. Someone publishes that exact name. The next install of the model’s suggestion downloads their package.

Seth Michael Larson, security developer-in-residence at the Python Software Foundation, gave it that name. The Register reported it on April 12, 2025. “Slop” is the usual jab at model output. The attack sits next to typosquatting, which copies a real name with a small misspelling. Slopsquatting does not need the real name. It needs the model to repeat a name that was never real.

A hallucination is the model being wrong. Slopsquatting is what a person does with that wrong name.

How slopsquatting works

The model writes an import or an install for a package that is not in the registry. If you install it then, the install fails, because nobody owns the name. That failure is the warning.

The attack is the next step. The attacker asks models the same kind of question, collects names that come back often, and publishes those names with their own code. Your agent’s next npm install or pip install of that name succeeds. Success is the bad outcome.

A 2025 paper measured how often code models invent names. It did not use the word slopsquatting. The measurements below are from that paper, on models chosen from the EvalPlus leaderboard as of January 20, 2024, plus GPT-3.5, GPT-4, and GPT-4 Turbo. They are not a rate for the models in Claude Code or Codex today.

Spracklen, Wijewickrama, Sakib, Maiti, Viswanath, and Jadliwala ran 30 tests, 16 models for Python and 14 for JavaScript, and generated 576,000 code samples. Those samples recommended 2.23 million packages. 440,445 of them, 19.7%, were not in PyPI or npm. 205,474 of those names were unique. GPT-series models landed at 5.2%. Open-source models landed at 21.7%. GPT-4 Turbo was the lowest overall, at 3.59%. Python averaged 15.8%, JavaScript 21.3%.

They also re-ran 500 prompts that had already hallucinated a package, 10 times each. 43% of those names came back on all 10 tries. 39% never came back. 58% came back more than once. Some invented names are predictable. That is what makes them worth registering.

Most of those names are not one-character typos. Of 76,489 names they compared with a real package, 13.4% were one or two edits away. 48.6% were six edits or more.

The paper’s threat model is a user who trusts the model and installs without checking. The attacker can run the same models, cannot change their weights, and can publish the missing name. The authors did not release the list of invented names.

How an invented package name becomes an installA model writes a package name that is not in the registry. Someone registers that name. A later install downloads their package.Model writes apackage nameName missing fromthe registrySomeone registersthat nameA later installdownloads their code

Slopsquatting in each tool

None of the four coding-agent docs describe a scanner that blocks invented package names. An install is a shell command. It goes through the permission mode you already set, and through the sandbox if the tool has one. Those pages do not mention package names.

Claude CodeCodexCursorGrok Build
A documented check for invented package namesNot documentedNot documentedNot documentedNot documented
What still appliesInstalls are shell commands, so your permission mode appliesSameSameSame

Claude Code

The Claude Code docs do not describe slopsquatting, a package allowlist, or a registry lookup before install.

See the Claude Code docs index.

OpenAI Codex

The Codex docs do not describe a package-name check. An install is still a shell command, so your permission rules for shell commands still apply.

See the Codex docs index.

Cursor

The Cursor docs do not describe a package-name check.

See the Cursor docs index.

Grok Build

The Grok docs do not describe a package-name check.

See the xAI docs index.

Details checked against each vendor’s documentation in November 2026. The rates above are from the March 2, 2025 revision of the package-hallucination paper, and the name is from The Register, April 12, 2025.

A real example

Before you install a name the model wrote, ask the registry who already owns it. This is express, which has been on npm since 2010:

npm view express name version time.created --json

On November 4, 2026 the registry answered:

{
  "name": "express",
  "version": "5.3.0",
  "time.created": "2010-12-29T19:38:25.450Z"
}

The version moves. The created time is the check. A name that has existed since 2010 is not something a model invented this morning. If npm view errors because the name is missing, stop. Do not install it to “see what happens.” This page does not print an invented name. The paper withheld that list so people would not register it.

For Python, open the project page on pypi.org. A page that exists only tells you the name is taken. It does not tell you the model meant this package.

When to use the check

Run it when an agent adds a dependency you do not already use. A new import, a new line in package.json, and a new line in requirements.txt are the moments. Look at the name, the publish date, and whether you have heard of the project.

You can skip it for a dependency the repo already pinned and that you meant to bump. That bump has a different failure mode. Securing your projects with AI covers a real package whose release was replaced. Slopsquatting is the case where the name was never real until someone published it.

Larson’s advice in that Register piece is the practical version. Check that the package is a known one, that the name has no typo, and that you have looked at what is inside it. An organization can also mirror the subset of PyPI it is willing to install.

Pitfalls

A successful install is not evidence the model was right. It is evidence that the name exists now. The paper says a filter that only checks “is this name in the registry?” fails as soon as the attacker publishes. The 200 from npm is too late.

The 19.7% figure is the share of package recommendations in that 2024-era study, across 576,000 samples. It is not the miss rate of the model you used today. GPT-series models in that study were at 5.2%, and open-source models at 21.7%. Quoting 19.7% as a current product stat is wrong.

Repeating the prompt does not save you. 43% of the retested names came back every time. A second opinion from the same model can hand you the same invented name.

Typosquatting and a compromised release of a real package are neighboring attacks. A one-character misspelling of a popular name is the first. LiteLLM’s October 2026 release, covered in the security post, is the second. Slopsquatting is the invented name. The fix for all three starts the same way: do not let an agent install a dependency you have not looked at. Permission modes are where that install stops for approval.

  • Permission modes: Permission modes decide what a coding agent can do without asking. The modes in Claude Code, Codex, Cursor and Grok Build, and what YOLO mode really skips.
  • Sandbox: An agent sandbox limits which files and hosts a coding agent's commands can reach. How the boundary works in Claude Code, Codex, Cursor and Grok Build.

All AI glossary entries →

Want me to talk about your product? You can sponsor this site.