Slopsquatting: when your AI coding agent installs the attacker's package

Your AI coding agent recommended a package that doesn't exist. Someone registered it.

In January 2026, Aikido Security researcher Charlie Eriksen found an npm package called react-codeshift. It had no real author. It had never been intentionally published. It was a name an AI invented by mashing together two real tools, jscodeshift and react-codemod, into something that sounded plausible but did not exist.

By the time Eriksen found it, the hallucinated package name had propagated to 237 repositories through forks, been translated into Japanese, and was still pulling down daily install attempts from autonomous agents that had no idea the package was fictional. Nobody had deliberately spread it. The AI wrote it, other agents copied it, and the dependency lived on in codebases around the world waiting for someone to register the name.

Nobody had registered it yet when Eriksen published his research. But the lesson was clear: if attackers had registered react-codeshift first, every agent that ran npm install on that code would have pulled down whatever the attacker put inside it.

That attack has a name now. It is called slopsquatting.

What slopsquatting actually is

Slopsquatting is what you get when you combine two things: AI models that confidently invent package names, and attackers who know which names get invented.

Typosquatting has been around for years. An attacker registers coloures instead of colours, or reqeusts instead of requests, and waits for a human to mistype during npm install. Slopsquatting is the same idea but the source of the error is different. Instead of betting on a human's fat fingers, the attacker bets on an AI being confidently wrong.

A 2025 USENIX Security paper tested sixteen code-generating models across 576,000 samples and found that nearly 20% of AI-generated code referenced packages that do not exist. The more alarming finding was about consistency: when researchers ran the same prompts ten times each, 43% of hallucinated package names appeared on every single run. These are not random errors. The models hallucinate the same fake names over and over, which means attackers can systematically identify which fictional packages to register by querying the models themselves.

The attack workflow is not complicated. An attacker queries an AI model with common development prompts, records every package name that appears in the output but does not exist in any registry, registers those names, and adds a post-install script. When a developer runs npm install or pip install with AI-generated code, the script fires before any human has seen what it does. It pulls API keys, cloud credentials, npm auth tokens, whatever is sitting in the environment at install time, and sends them to the attacker. The developer sees a successful install. The attacker has their credentials.

Why AI agents make this worse

Human developers have friction. They hesitate at an unfamiliar package name. They check the npm page to see if there is a README, a source link, a download count above zero. They sometimes ask a colleague. That friction is annoying but it catches a surprising number of problems before they become incidents.

AI coding agents do not have that friction. Their job is to reduce it. They resolve dependencies and keep the build moving. When an agent generates code with a package name and then runs the install step, there is no pause between generation and execution. The package gets installed because that is the workflow.

This changes the risk profile significantly. A human developer installing a suspicious package is one developer making one mistake. An autonomous agent that generates code with a hallucinated package name and installs it might do that across hundreds of repos, in CI/CD pipelines running on schedule, in workflows that have no human in the loop. The react-codeshift incident spread to 237 repositories without anyone trying to spread it. It was just agents copying agent output.

The agents that are most capable are also most at risk here. The models that score well on benchmarks by writing complete, runnable code are the ones generating complete dependency lists, complete install commands, complete setup scripts. Capability and confidence are correlated, and confident wrong answers about package names are exactly what slopsquatting depends on.

The Alibaba incident and how amplification works

The react-codeshift case shows how slopsquatting spreads through the agentic layer. A different incident in 2026 showed how it spreads through documentation.

Security researcher Bar Lanyado documented a case where Alibaba copied an AI-recommended installation command referencing the huggingface-cli package into a public repository's documentation. The command was AI-generated, the package name was not carefully verified, and within three months the package had accumulated over 30,000 downloads, not from developers deliberately seeking it out, but from people following the documentation. Official-looking documentation recommending a package dramatically amplifies the download count and creates an appearance of legitimacy that makes the package look safer than it is.

This is the second-order risk that makes slopsquatting harder than it looks. The problem scales beyond any individual developer's review habits. When organizations with large repositories and trusted documentation publish AI-generated install commands without verification, a single unverified dependency can reach thousands of environments. The attacker does not need to compromise the package registry or the supply chain. They just need to register the right name before the AI-generated recommendation gets canonized somewhere with enough reach.

What happens when the package runs

Most slopsquatting packages follow the same pattern. The package looks plausible enough from the outside. It may have a brief description, a version number that suggests it has been around a while, and no obviously malicious content in the files that are visible before install.

The payload lives in the postinstall script, which npm and pip both run automatically after installation completes. Post-install scripts are a legitimate mechanism, widely used for building native modules or running one-time setup. They are also the standard attack surface for supply chain attacks because they run with whatever permissions the parent process has, which in a developer environment often means access to environment variables, credential files, SSH keys, and config directories.

A post-install exfiltration script typically grabs environment variables starting with AWS_, GITHUB_, ANTHROPIC_, OPENAI_, DATABASE_, and similar prefixes, scans the home directory for credential files and key stores, and sends everything to an external endpoint before the install process reports back to the terminal. The developer sees install completed successfully. The attack is already done.

The attacker does not need to maintain the malicious package indefinitely. They need it to survive for one good run in a high-value environment. A single CI/CD pipeline with production credentials is enough to make the registration worth doing.

What to do about it

The good news is that slopsquatting is detectable before anything malicious runs, which makes it a solvable problem if you add the check at the right point.

The most practical defense is running package verification before the install command. An open-source tool called slopcheck does exactly this. It parses dependency files across ecosystems, including requirements.txt, package.json, Cargo.toml, go.mod, Gemfile, and pom.xml, checks every name against its live registry in parallel, and flags anything that does not resolve to a real package. A GitHub Action is available so the check can run in CI before any install command fires. A full project scan usually finishes in under a second.

Beyond slopcheck, a few practices reduce the surface area. Lockfiles are the simplest one. A lockfile records exact package versions and their cryptographic hashes after a human has verified the install. An AI agent that generates code against a pinned lockfile cannot introduce a new, unverified dependency at install time. It can only use what is already there. This does not eliminate slopsquatting but it contains it to the initial setup phase where a human is usually present.

Code review for AI-generated dependency changes specifically is worth separating from general code review. Looking at new dependencies is a different task than looking at logic, and teams that review both in the same pass tend to skim the dependency list. When an AI adds a package, that package should get a brief check: does it exist, does it have real usage outside AI-generated code, does the npm page have a source link that points somewhere real?

The hardest case is autonomous agents running in CI without a human in the install path. For those workflows, the check has to be automated. Slopcheck in a pre-install hook or a package legitimacy gate in the CI pipeline is the practical answer. The alternative is trusting that the agent never hallucinates a package name in a file that matters, and the data shows that is not a bet worth taking.

The pattern to watch for

Slopsquatting packages tend to cluster around specific naming patterns. The models are trained on documentation and code that references real packages heavily, so their hallucinated names sound like variants of real things. Common patterns include combining two real package names, adding modifiers like -ai, -gpt, -helper, or -utils to real package names, and inventing plausible-sounding names in domains the model knows well.

Slopcheck flags these patterns specifically, checking for Levenshtein distance against popular packages and common hallucination suffixes. Running it on AI-generated code before any install is the fastest way to catch the problem before it becomes an incident.

The supply chain threat in AI-assisted development is not limited to slopsquatting, but slopsquatting is the one that requires the least attacker sophistication. There is no need to compromise an existing package, infiltrate a registry, or find a zero-day. The AI generates the attack surface by making consistent naming mistakes, and the attacker registers a domain before anyone else does. For the low effort required, the potential access is significant. Most developer environments have more sensitive credentials than the organizations that own them realize.

Add a package verification step before AI-generated dependencies go anywhere near install. The AI will keep hallucinating package names. That is not going to stop. The question is whether someone is checking before the install command runs.