Blog

Slopsquatting, Typosquatting, and the New Software Supply Chain Attacks: How AI and Vibe Coding Are Making Package Registries Even More Dangerous

AI coding tools hallucinate fake package names. Attackers register them. You install malware. Here's how slopsquatting works and what you can do about it.

Sebastien Dubois

04 Apr 2026 — 11 min read

In this article, I want to explore a family of supply chain attacks that are growing fast, and that most developers still haven't heard of. We'll look at how AI-generated code is creating entirely new attack surfaces in package registries, why traditional defenses aren't enough, and what you can do to protect yourself.

Introduction

If you've been using AI tools to write code or create content (and honestly, who isn't at this point?), you've probably noticed something: these tools are really confident. They suggest tools, software packages & dependencies, write import statements, and generate install commands without hesitation. And most of the time, the things they recommend actually exist.

But sometimes, they don't. Oops. And that's where things get dangerous.

LLMs don't "know" which packages exist and which don't (in the common sense). They predict the most statistically likely next token. So when you ask for help with a task, they might confidently suggest a package name that sounds right, looks right, but doesn't actually exist on npm, PyPI, or any other package or software registry. That's called an AI Hallucination, and it's a well-known problem.

What's less well-known is that attackers are now weaponizing those hallucinations. They study which fake package names AI models tend to generate, register those names on public registries, and wait. When the next developer (or the next AI agent) runs the install command, they get malware instead of the tool they expected.

This attack has a name: Slopsquatting. And it's just one member of a growing family of supply chain attacks that are getting worse in the age of AI-assisted development.

TL;DR

Slopsquatting is a supply chain attack where attackers register package names that AI models hallucinate
It's different from Typosquatting (which relies on human typos) and Dependency Confusion (which exploits public/private namespace collisions)
A USENIX Security 2025 study found that ~20% of AI-generated code samples recommended nonexistent packages
Real-world example: a fake huggingface-cli package got 30,000+ downloads in three months
AI hallucinations are not random. They're predictable and repeatable, which makes them reliable attack targets
Vibe coding and autonomous AI agents install packages without human review, massively increasing exposure
Traditional registry defenses (name similarity checks) don't catch slopsquatting because the hallucinated names look nothing like real packages
Package registries are just one attack surface. AI plugins, prompt injection via email/calendar, and compromised skills are all live threats right now
The Lethal Trifecta for AI Agents (hallucination + tool access + autonomy) makes all of this exponentially more dangerous
You need a layered defense: verify before installing, lock your dependencies, restrict autonomous installations, build your own skills, and use SCA tools
We're still very early. Things will get worse before they get better

What is typosquatting?

Let me explain the classic version first, because slopsquatting builds on top of it.

Typosquatting is one of the oldest tricks in the book. An attacker registers a package name that's a common misspelling of a popular package. Think crossenv instead of cross-env, or expresss with an extra "s". When a developer fat-fingers the install command, they get the malicious version instead.

The crossenv incident on npm back in 2017 was one of the first to make headlines. The package looked legitimate, wrapped the same functionality as the real cross-env, but also silently captured environment variables (including npm authentication tokens) and sent them to an attacker-controlled server.

Since then, typosquatting has scaled up. A single campaign on PyPI deployed over 500 malicious packages in two waves. And attackers have gotten more creative with their techniques:

Character substitution: swapping visually similar characters (rn looks like m, 0 looks like O)
Character omission or addition: colrs instead of colors, expresss instead of express
Hyphen/underscore confusion: cross-env vs cross_env (npm and PyPI normalize these differently)
Scope dropping: express instead of @scope/express

The good news is that registries have started fighting back. npm now blocks new names that are too similar to popular existing packages. PyPI has added name normalization. These defenses catch the obvious cases.

But they don't catch what's coming next.

What is Slopsquatting

Slopsquatting is typosquatting's AI-powered cousin. Instead of betting on human typos, attackers bet on machine hallucinations.

Here's how it works:

A developer (or an AI agent) asks an LLM for help with a coding task
The model confidently suggests a package that doesn't exist. Not a typo of a real package, just a completely fabricated name that sounds plausible
The attacker has already registered that name on a public registry, filled with malicious code
The developer runs pip install or npm install, and the malware executes

LLM hallucinations are not random. They're "statistically predictable". The same model, given similar prompts, will repeatedly hallucinate the same nonexistent package names. That makes them realistic & somewhat reliable attack targets.

A USENIX Security 2025 study tested 16 code-generation models across 576,000 code samples. The findings are alarming:

~20% of samples recommended packages that don't exist
43% of hallucinated package names were repeated consistently across 10 separate queries
51% of fabricated names were pure inventions (not typos or variations of real packages)
38% were plausible conflations of real package names (like express-mongoose)
8.7% of Python hallucinations matched valid JavaScript package names, creating cross-ecosystem confusion

That last point is particularly nasty. An AI suggests a Python package that happens to share a name with a real JavaScript package. The developer doesn't find it on PyPI, assumes it's a naming variation, and either gets confused or installs the wrong thing entirely.

Real-world examples

This isn't theoretical. It's already happening.

huggingface-cli (2024): Security researcher Bar Lanyado at Lasso Security documented that AI models repeatedly hallucinated a Python package called huggingface-cli. When he registered it as an empty package on PyPI, it received over 30,000 authentic downloads in three months. No promotion, no SEO, no social media. Just people following AI recommendations.

react-codeshift (2026): A hallucinated conflation of jscodeshift and react-codemod. This one spread across 237 GitHub repositories through AI-generated agent skills, getting daily downloads from automated agents that never had a human reviewing the install command.

unused-imports: An AI suggested this instead of the real eslint-plugin-unused-imports. The malicious package was pulling 233 downloads per week.

Why vibe coding makes everything worse

Vibe Coding amplifies every single one of these risks.

If you're not familiar with the term, vibe coding is the practice of letting LLMs generate all your code while you provide goals and feedback in natural language, without necessarily reviewing every line (or not looking at the code at all). More and more people are doing this.

The problem is that vibe coding means nobody is really paying attention to the import statements, the requirements.txt entries, or the package.json additions. You're trusting the AI to pick the right dependencies. And as we've seen, AI tools get this wrong about 20% of the time.

Worse: autonomous AI agents can now install packages on their own. They read the AI's recommendation, run the install command, and execute post-install scripts. All without a human in the loop. That's even worse.

The full family of supply chain attacks

Slopsquatting and typosquatting are part of a larger family of attacks:

Typosquatting: exploits human typing errors. The classic.
Slopsquatting: exploits AI hallucinations. The newest member.
Dependency confusion: exploits namespace collisions between public and private registries. An attacker publishes a package on npm or PyPI with the same name as your company's internal package, sets the version to 99.0.0, and your build system grabs the public (malicious) version instead. Alex Birsan demonstrated this against Apple, Microsoft, and PayPal in 2021.
Starjacking: exploits trust signals. An attacker links their malicious package to a popular GitHub repository, inheriting its star count and contributor list. The package looks legitimate because it appears to have thousands of stars and dozens of contributors. Registries don't verify that the linked repository actually contains the package's source code.

All of these fall under the umbrella of namesquatting: registering names in shared namespaces to exploit trust or confusion.

The four members of the namesquatting family.

The bigger picture: it's NOT just packages

I want to zoom out for a moment, because package registries are just one piece of a much larger problem.

The more I read about AI security risks, the more I recommend people to seriously explore the concept of the Lethal Trifecta for AI Agents: the combination of hallucination, tool access, and autonomy. When an AI agent can hallucinate a package name AND has permission to install it AND runs without human review, you've got all three legs of the trifecta working against you.

But namesquatting is just the beginning. Consider what's happening right now:

You install AI-powered tools on your personal computers, on devices in your home network, on corporate infrastructure. Then you wonder why/how you're getting hacked
You install an AI plugin that looks "ok", only to discover later that it's been instructing your AI agents to leak secrets and API keys in the background
You update a plugin and don't realize it's been taken over by a malicious party. The update looks normal. The behavior isn't
You download something that seems harmless, but days or weeks later, an AI agent picks it up, processes it, and takes exactly the wrong action. Think about the delay between a download and the moment AI actually touches it
You let AI check your mailbox, and a junk mail contains a Prompt injection attack hidden in its text. The AI reads it, follows the injected instructions, and now you're compromised. Same with your calendar. Same with any data source AI has access to

I strongly believe that the people who oversell AI don't care nearly enough about the harm it can do; especially to people who are uninformed about how current-generation AI actually works. Even people who are educated and supposed to know better fail time and time again to take appropriate security measures.

The attack surface around AI is massive and growing. Every new AI integration, every new plugin, every new AI skill, every new MCP server, every new tool connection is another potential entry point.

Supply chain attacks through package registries are just one category among many.

Why traditional defenses fall short

Most of the defenses that registries have built were designed for typosquatting. They check whether a new package name is suspiciously similar to an existing popular package.

But slopsquatting names aren't similar to anything. They're pure fabrications. They look like perfectly reasonable packages that just happen not to exist yet. Similarity checks won't catch those.

CVE databases won't help either. Software Composition Analysis (SCA) tools like Snyk or Dependabot scan your dependencies against known vulnerability databases. But a slopsquatted package is brand new. It's not in any CVE database. It hasn't been flagged by any security researcher yet. And those can be created at scale.

So what can you do?

How to protect yourself

As usual, the defense needs to be layered. No single measure is enough. There are tons of things to pay attention to. But first, you have to explore the risks, pay attention, and CARE enough about them to take action.

1. Don't copy/paste AI skills or plugins. Build your own

This is the single most important rule. Don't download random AI skills, plugins, or prompts from the internet and run them. You wouldn't run a random shell script from a stranger. Treat AI skills the same way. If you need a capability, build it yourself. You'll understand exactly what it does, and you won't be at the mercy of someone else's intentions or security hygiene. It's not like skills are hard to create.

If you absolutely must use third-party skills or plugins, audit them line by line before running them. And audit every update too.

2. Verify before you install

Don't blindly trust AI-generated install commands. Before running pip install or npm install for a package you haven't used before, check:

Does this package actually exist on the registry?
When was it created? (Brand new packages are suspicious)
Who published it? (Check the publisher's history)
Does it have a linked source repository? (And does that repo actually contain the package's code?)
What's the download count? (Low numbers on an older package could mean starjacking)

This takes 30 seconds. It could save you from a serious breach.

3. Ban autonomous install commands

And better yet: don't give your AI agents permissions to install software or dependencies autonomously. Do this manually.

Configure your AI agents to suggest dependencies but never install them directly. Review every addition to package.json, requirements.txt, or Cargo.toml yourself. This is one of those cases where a tiny bit of friction prevents a lot of damage.

4. Lock your dependencies

Always commit lockfiles (package-lock.json, poetry.lock, Cargo.lock). Review dependency changes in pull requests. Pin exact versions. Don't use latest or * in your version specs.

Lockfiles are your safety net. If a malicious package sneaks into your dependency tree once and you catch it, the lockfile prevents it from coming back.

Consider that anything you depend on may be taken over by malicious parties; directly, or indirectly (just read about the recent Axios catastrophe in the npm ecosystem!).

These have been recommended practices for a long time, but they're even more important now.

5. Don't give AI the keys to your kingdom

Don't hand over API keys, database credentials, or admin tokens to AI agents. Don't run AI in YOLO mode with unrestricted permissions. Use proper sandboxes. Apply the Least Privilege Principle rigorously: AI should have the absolute minimum access it needs, and nothing more.

Every new tool connection, every new MCP server, every new AI skill or agent, every new permission grant is another entry point. Treat them accordingly.

6. Put guardrails in place

AI Guardrails aren't optional. They're essential. Set up:

Allowlists for approved packages and tools
Human approval for any new dependency or integration
Blocking of post-install scripts by default (that's where most malware executes)
Sandboxed environments for anything untrusted
Input filtering on any data source AI can access (email, calendar, documents)

7. Review code before you ship

This should go without saying, but the rise of vibe coding means it needs saying: review the code before you hit publish. Review the dependencies. Review the imports. Review what changed. AI generates code fast; the bottleneck is now review and testing, and that's exactly where you should be spending your time.

Moreover, do all this before you run/execute anything on your own machine. You can get hacked also during development, not only when the code runs in production!

8. Use Software Composition Analysis (SCA) tools (but know their limits)

Software Composition Analysis (SCA) tools can catch known-malicious packages and flag suspicious behavior patterns (network calls, filesystem access, eval usage).

But remember: SCA tools can't catch what they don't know about yet. Use them as one layer, not as your only defense.

9. Reserve your internal names and use scoped packages

If your organization uses internal packages, reserve the namespaces in public repositories, and publish empty placeholder packages with those names on public registries. This prevents dependency confusion attacks. On npm, use @org/package namespaces to eliminate name collision attacks entirely.

Do this with all the technologies you're using, be it npm, Pypi, Docker, ...

Going further

If you want to stay up to date with AI, Knowledge Management, and the tools and systems that matter, consider joining the Knowii Community or subscribing to my newsletter.

Conclusion

The software supply chain has always been a target. Typosquatting has been around for years. Dependency confusion made headlines in 2021. But slopsquatting is new, and it's different in an important way: it scales with AI adoption.

Every developer who uses an AI coding assistant. Every CI/CD pipeline that auto-installs dependencies. Every autonomous agent that runs without human review. Every AI plugin you installed without reading the source. Every MCP server you connected without thinking twice. They're all potential attack vectors.

We're still very early. The AI tooling ecosystem is growing faster than our security practices can keep up. Things will get worse before they get better. New attack patterns will emerge. New vectors will be found. The attackers are paying attention, and they're moving fast.

The defenses I've listed are straightforward: build your own skills, verify before installing, ban autonomous installs, lock your dependencies, sandbox everything, and review before you ship. None of this is hard. But you have to actually do it. You have to explore the risks and CARE enough about them to take action.

The age of "just run npm install and trust it" is over. The age of "just install this AI plugin and let it run" should never have started.

Stop giving AI the keys to your kingdom. Start treating every AI integration as a potential attack surface. Because that's exactly what it is.

That's it for today! ✨

About Sébastien

I'm Sébastien Dubois, and I'm on a mission to help knowledge workers escape information overload. After 20+ years in IT and seeing too many brilliant minds drowning in digital chaos, I've decided to help people build systems that actually work. Through the Knowii Community, my courses, products & services and my Website/Newsletter, I share practical and battle-tested systems.

I write about Knowledge Work, Personal Knowledge Management, Note-taking, Lifelong Learning, Personal Organization, Productivity, and more. I also craft lovely digital products and tools.

If you want to follow my work, then become a member and join our community.

Ready to get to the next level?

Want to use AI as a real thinking partner?

🤖 AI Ghostwriter Guide — Make AI write like you
🧠 AI Master Prompt Workshop — Craft prompts that actually work
🎙️ Knowii Voice AI — Privacy-first voice-to-text powered by AI
🎯 Join Knowii — AI workshops + community + all courses