What is slopsquatting?
By Identra · Updated
Slopsquatting is a software supply chain attack in which attackers publish malicious packages under names invented by AI coding tools. Developers or agents that trust those recommendations can install attacker-controlled code as a dependency.
How does slopsquatting work?
A coding assistant suggests a package that doesn't exist. The name sounds right. An attacker spots it, publishes a malicious package under that name on npm or PyPI, and waits for the assistant to suggest it to someone else. Trend Micro's slopsquatting research documents the mechanism.
The invented name starts out as an AI hallucination risk. The attacker's upload turns it into code that runs. On npm that can be a postinstall script. A Python source distribution can run code at install, and any package can run code the first time it's imported.
Nobody touches the model. The attack only needs someone to trust the suggestion.
How is slopsquatting different from typosquatting?
All three attacks in the table end with the wrong package installed. They exploit different mistakes. Spell-checking won't catch slopsquatting, because the attacker's spelling is exactly the one the AI gave you. A registry hit proves the name exists. That's why this belongs under AI supply chain security.
Slopsquatting
- What leads to the wrong package
- An AI tool recommends an invented name that an attacker claimed.
- Control that helps
- Verify the dependency against something other than the AI before admitting it.
Typosquatting
- What leads to the wrong package
- A package name looks like a real one.
- Control that helps
- Check exact names against the project's own docs.
Dependency confusion
- What leads to the wrong package
- The resolver picks an attacker's public package over your private one.
- Control that helps
- Pin package sources and enforce private namespace rules.
What does a slopsquatting attack look like in an enterprise?
Say a developer building an internal invoice parser asks a chat assistant for a PDF library. It suggests a name that sounds plausible. An attacker registered that name a while ago. The developer pastes the pip install line into a terminal.
When the tests import the package, it reads whatever credentials the process can see and posts them to an outside server. How bad that is depends on the machine. A laptop with admin AWS keys in ~/.aws is a very different day from a locked-down container.
An agent with install rights does the same thing with nobody watching. So dependency admission is a coding agent security control. Pull request review comes after the code already ran.
How can teams prevent malicious AI-recommended dependencies?
Treat a new dependency as untrusted until it's checked against a source other than the AI. Confirm the exact name in the real project's docs. Look at the publisher, the repo, the release history and what's actually inside the package. A polished README proves nothing, and asking the same assistant whether it's safe isn't independent evidence.
- Require approval before anyone, person or agent, adds an unapproved dependency or changes a registry source.
- Route installs through a registry proxy with admission rules. A plain caching proxy only caches.
- Review lockfile diffs, including new transitive packages.
- Turn off install scripts by default with npm's ignore-scripts setting and allow exceptions one at a time.
- Scan for malware and check provenance. A freshly published malicious package usually has no CVE.
How should coding agents evaluate unfamiliar packages?
Try them in a throwaway environment using AI agent sandboxing, with no production credentials, no signing keys and tight egress. A package gets whatever access its process has, so least privilege is the real limit.
Log the proposed package, its source, the exact artifact, who approved it and what happened at install. Then test two things. An unapproved package should be stopped before it runs. The agent shouldn't be able to dodge the rule by switching registries.
What should teams do after a suspicious package install?
Stop the agent or the build. Isolate the machine if the code may have run. Keep the package artifact, resolved versions and install logs.
Search other repos, laptops and CI runners for the same package. Remove it, rebuild from clean inputs and rotate anything the process could read. Uninstalling doesn't undo what it already did. The AI incident response record should tie the suggestion and the install to the user or agent, the repo and the permissions involved.
How Identra thinks about it
Identra shows security teams which coding agents, packages and agent tasks are on macOS and Windows endpoints. Recorded AI agent runs tie activity to the user, device, AI client and allowed or blocked outcome, so an investigation can start from who ran which agent.
Go deeper: Identra on the endpoint
Frequently asked questions
Is every hallucinated package a slopsquatting attack?
No. A made-up package name is a model error. It becomes slopsquatting when an attacker registers that name with malicious code behind it.
Does slopsquatting require prompt injection?
No. The attacker just claims names the model already invents. Prompt injection can also steer an assistant toward a bad package, but that's a different mechanism.
Does a package being listed in a public registry mean it is safe?
No. Being listed means it can be downloaded. It says nothing about whether it's the package you meant or whether it's trustworthy.
Do lockfiles prevent slopsquatting?
No. Lockfiles pin versions and, where supported, artifact hashes. They pin a malicious package just as faithfully as a good one, so review has to happen before the lock.
Can slopsquatting affect developers who install packages manually?
Yes. Copying an install command from a chat window is enough. No agent required.