When AI invents a package, attackers claim it.

Slopsquatting is a supply chain attack in which someone registers a package name that AI coding tools tend to invent, then waits for people or agents to install it. The model suggests a package that never existed, the attacker publishes one under that name, and the install runs the attacker’s code. The defense is simple: confirm that every new dependency is real, established and the one you meant, before it installs.

The name joins “AI slop” and “typosquatting”. The difference from a typo is that the mistake comes from the model, and it repeats.

01What is slopsquatting?

A hallucination here means a confident, plausible answer that is simply wrong. A model asked to parse a file might import a package that sounds right and does not exist. If you, or an agent, then run the install command, the package manager fetches whatever sits under that name today.

Seth Larson, the Python Software Foundation’s security developer-in-residence, coined the term. Andrew Nesbitt, who created the package data service Ecosyste.ms, popularized it in April 2025.

02What the research found

The numbers come from a study presented at USENIX Security 2025. Researchers generated 576,000 code samples in Python and JavaScript from 16 models and checked every package they recommended against the real registries.

Commercial models did much better: they invented at least 5.2% of packages on average, against 21.7% for open-source models. GPT-4 Turbo was lowest, at 3.59%. The repetition is what turns an error into an attack. If a model invents the same name every time, an attacker can find it by asking the same questions, then register it.

Two details matter for defense. Only 13.4% of invented names were one or two characters away from a real package, so most do not look like typos at all. And 8.7% of the invented Python names were real JavaScript packages, which makes the wrong-language mix-up its own trap.

Newer models narrowed the gap without closing it. A 2026 preprint by an independent researcher tested five recent models, including Claude Sonnet 4.6, GPT-5.4-mini and Gemini 2.5 Pro, and found rates between 4.62% and 6.10%. That is close to the 2024 commercial models and far below the open-source ones. It also found 127 names that all five models invented identically. The spread shrank. The problem did not.

03Real cases so far

Most documented cases are researchers claiming a name before an attacker could. That is reassuring, and it is also proof the trap works.

1. March 2024Bar Lanyado registers an empty huggingface-cli package, a name chatbots kept inventing. It gets over 15,000 real downloads in three months, and an Alibaba research repository tells readers to install it.
2. April 2025Seth Larson coins “slopsquatting”, and Andrew Nesbitt’s post spreads it.
3. October 2025A commit adds 47 AI-generated agent skills to a public repository. Some tell agents to run npx react-codeshift, a package that did not exist.
4. January 2026Aikido’s Charlie Eriksen finds react-codeshift in 237 repositories and registers it defensively. Afterwards it sees one to four downloads a day.
5. February 2026Aikido points to unused-imports, a malicious npm package one guess away from the real eslint-plugin-unused-imports, as a possible deliberate slopsquat. npm has put it under a security hold.
6. July 2026Researchers from Tel Aviv University, the Technion and Intuit show “HalluSquatting” against six coding assistants, using harmless test payloads.

The honest summary: as of September 2026, the public record is mostly defensive registrations and research demos, plus at least one malicious package that fits the pattern. The attack costs almost nothing to try, so do not wait for a famous incident.

04Why coding agents raise the stakes

A person who sees an unfamiliar package name might pause. An agent working through a task runs the install and moves on, often while nobody reads the command. With npx, downloading and running a package is a single step. Our codebase migration guide has a real example: running npx ast-grep without installing @ast-grep/cli first pulls an unrelated old package that owns the bare name.

Installing is enough to get hurt. npm packages can run scripts during installation, and installing a Python package from source can run its build code. The attacker’s code can run before you ever import anything.

Agent instructions also spread mistakes. The react-codeshift name traveled through copied skill files, the reusable instruction files that agents load, not through anyone’s typing. And the HalluSquatting research combined a predictable name with prompt injection, hidden instructions that steer the agent, to take over the agent doing the install.

05How to defend against slopsquatting

None of these steps is exotic. Together they make an invented name very hard to get onto your machine.

1. 01

   Check every new package before it installs

   Look at the registry page before you install anything new. Real packages have a history: several releases, a linked source repository, maintainers you can find and downloads that fit their fame. A package first published last week, with no repository link, or with a name that mashes two real packages together, is a red flag.

   # When was it first published, and who maintains it?
   npm view <package> time.created maintainers repository.url

2. 02

   Let the lockfile decide what gets installed

   Commit your lockfile, and in CI install with npm ci, which installs exactly what the lockfile lists and fails if it disagrees with package.json. A new name can then only arrive through a visible change to both files, which a reviewer sees. Python projects get the same protection from a lock file with hashes.

3. 03

   Delay brand-new releases

   npm and pnpm can now refuse versions that were published too recently. It will not stop a name squatted months ago, but it blocks fresh squats and many hijacked releases. pnpm counts in minutes and, since version 11, waits one day by default. npm counts in days. Both examples below wait a week.

   minimumReleaseAge: 10080

   min-release-age=7

4. 04

   Put installs behind an approval

   In your agent’s permission settings, require approval for npm install, pip install and npx, and avoid skip-permission modes in projects where the agent adds dependencies. Treat this as a speed bump, not a wall: Claude Code’s docs, for example, say its command rules are not a security boundary around the program.

5. 05

   Use an allowlist for team projects

   For a team, route installs through a registry proxy that serves only approved packages, or a dependency firewall that blocks new and suspicious ones. Then a hallucinated name fails to install instead of failing later in production. If an agent runs unattended in CI, keep its permissions this tight there too, as our guide to coding agents in CI shows.

Give your agent the same rules in its project instructions:

Before adding any new package:
1. Tell me the exact name, its registry page and what it is for.
2. Confirm it exists, and report its first release date, latest version and source repository.
3. Explain why the standard library or an existing dependency cannot do the job.
4. Wait for my approval before running any install or npx command.
Never install a package name you have not checked on the registry.

06A checklist before you install

New dependencies are one of the AI failure patterns in our guide to reviewing AI-written code. Give them a slow read every time.

07FAQ

Read next: our checklist for securing AI-generated code, and how agent skills work.