Slopsquatting: When Your AI Assistant Suggests a Package That Turns Out to Be a Trap

Your AI coding assistant recommends a package. You run npm install. It works. You move on.

Here is the uncomfortable part. That install command just ran code on your machine, with your permissions, with access to your files, your network, and every credential your environment can reach. If the package was malicious, none of that required a warning or a click. It happened at install time, before you ran a single line of your own code.

And in 2025 and 2026, "if the package was malicious" stopped being hypothetical.

There is a quiet flaw in how language models suggest dependencies. They do not look packages up in a registry. They predict text that looks statistically right for the context. So sometimes they invent a package name that sounds perfectly plausible and does not actually exist.

Researchers measured this at USENIX Security 2025. They generated 2.23 million code samples across 16 models in Python and JavaScript, and found that about 19.7 percent of them referenced at least one package that does not exist. Roughly one in five AI code suggestions pointed at a phantom dependency.

Attackers noticed. The move is simple: run popular coding prompts, collect the fake package names the models keep inventing, register those names on npm or PyPI, and fill them with malware. The security community named this slopsquatting.

It works because the hallucinations are predictable. In the same study, when researchers repeated identical prompts ten times, 43 percent of the invented names came back on every single run. That is not random noise. It is a reliable, farmable list of names an attacker can pre-register.

In September 2025, a supply chain attack compromised around 20 widely used npm packages that together pulled roughly 2 billion downloads a week. A maintainer got phished, and malicious versions of trusted packages went out to anyone who updated.

Attackers are also aiming squarely at AI development tooling. In June 2026, a North Korea-linked group hijacked a stale contributor account and republished more than 140 packages in the Mastra AI framework's npm scope in one short burst, each rigged to pull in a credential-stealing payload. That scope was chosen on purpose: AI-agent packages sit right next to model API keys and cloud tokens, and coding assistants pull them in automatically.

Separately, a malicious package named to mimic a real, popular one kept getting installed week after week, riding on models that suggested the wrong name. The pattern across all of these is the same: the malicious code runs when a dependency is installed, before you run a single line of your own code.

Step back and the core issue is not any single bad package. It is where the code runs.

When you or your AI agent runs an install command on your laptop or your build server, that code executes with full local privileges. It can read your SSH keys, your cloud credentials, and your environment variables. It can reach your internal network. It can quietly exfiltrate anything it finds. On a developer machine that is often connected to production systems, that is a very short path from "I installed a package" to "an attacker is inside our infrastructure."

A lot of these packages do not keep the payload in the package files either. Some run code through a post-install script that fires automatically during installation, and others declare a dependency that fetches the real payload from an external server at install time. So "I glanced at the package and it looked clean" buys you almost nothing.

Instead of running AI-generated code and its dependencies directly on developer machines and your production network, you run them in a sandbox: an ephemeral, isolated environment that gets created for the task and destroyed when it is done.

If something malicious executes in there, it hits a wall. No access to your real credentials, no path to production, no persistence. The blast radius is a throwaway container that disappears minutes later.

A practical sandbox setup usually includes ephemeral environments that auto-create on commit and auto-destroy on close, complete isolation from your production network, pre-installed security tooling in every environment, project-level access policies and resource limits, and a workflow developers actually accept — built on Gitpod, GitHub Codespaces, or a custom setup that works with VS Code and JetBrains IDEs.

The goal is not to slow developers down. It is to let them use AI tooling at full speed while making sure that when a bad dependency slips through — and eventually one will — it lands somewhere harmless.