You’re building a new feature, or maybe just patching a bug. Time is tight. You need a specific piece of code, something you’ve done before but can’t quite recall the exact syntax. So, you turn to your AI coding assistant. You type a quick prompt, and like magic, it spits out a few lines of code. Looks good. You copy, paste, and move on.

This scenario plays out millions of times a day. AI coding assistants like GitHub Copilot or OpenAI’s ChatGPT are fantastic productivity boosters. They can write boilerplate code, suggest algorithms, and even help you debug tricky issues. It feels like having a super-smart pair programmer at your beck and call.

But what if that helpful suggestion isn’t quite right? What if the AI, in its eagerness to assist, invents something that doesn’t actually exist?

This is the heart of a new, insidious type of supply chain attack called “slopsquatting.” It’s a clever exploit that preys on the very helpfulness of AI code generation. The flip side — AI used defensively to find these flaws first — is covered in the Claude Mythos preview. Here’s how it works.

Most software today isn’t built from scratch. Developers rely on vast libraries of pre-written code, called packages or modules, that handle common tasks. Think of them like Lego bricks; you grab the right brick for the job instead of molding your own plastic. These packages are managed by public repositories, like npm for JavaScript or PyPI for Python.

When a developer asks an AI assistant for code that uses a package, the AI might sometimes “hallucinate” a package name. It might suggest a package that sounds plausible, or one that’s very similar to a real one, but it simply doesn’t exist in the public repository. This is what’s known as an AI hallucination – the AI confidently generates information that’s factually incorrect.

Here’s the kicker: attackers are actively monitoring these AI suggestions. They’ve built systems that scan for these non-existent package names that AI assistants are generating. Once they spot one, they can quickly register that exact package name on npm or PyPI before anyone else does.

Then, they publish their own package. This package looks innocent enough, perhaps even mimicking the function the developer intended to achieve. But hidden inside is malware.

So, the developer, thinking they’re just adding a helpful library suggested by their AI assistant, unknowingly pulls in this malicious package into their project. Their build process runs, their application incorporates the code, and suddenly, malware is now part of their software supply chain.

This is profoundly concerning because it bypasses many traditional security checks. Security tools are designed to scan for known malicious packages or vulnerabilities in existing code. They aren’t typically built to catch a package that’s supposed to exist but was invented by an AI and then immediately snatched up by an attacker.

Imagine a scenario where your company relies on a specific data processing library. Your lead engineer, under pressure, asks their AI assistant for a more efficient way to handle a particular data transformation. The AI suggests a new, hypothetical library: data-cruncher-optimized. The engineer, trusting the suggestion, adds it to their package.json file.

Hours later, an attacker who’s been watching the AI’s output registers data-cruncher-optimized on npm. They push a package that looks like it does data processing but, in reality, contains a backdoor that allows attackers to exfiltrate sensitive customer data. Your application, now containing this compromised package, becomes a vector for a massive data breach. The impact could be devastating, leading to regulatory fines, loss of customer trust, and significant financial damage.

It’s a chilling thought: the very tools designed to make developers more productive are being weaponized to insert malware.

This attack vector is particularly effective because it exploits a common developer workflow. Developers often trust their AI assistants implicitly, seeing them as extensions of their own knowledge. When the AI suggests a package, it’s usually presented with code that looks perfectly valid, making it easy to overlook the fact that the underlying library might be fictional.

One real-world example, though early in its discovery, involved a hypothetical package named requests-mock-fastapi. An attacker registered this name on PyPI after seeing it suggested by an AI. The malicious package contained code designed to steal AWS credentials. While the exact number of affected projects is still being investigated, it highlights the immediate danger.

So, what can you do to protect your business from slopsquatting? It requires a multi-layered approach, acknowledging that AI-generated code is not inherently trustworthy.

First, dependency scanning is more critical than ever. You need tools that can scan your project’s dependencies not just for known malware, but also for suspicious or newly registered packages. Many modern CI/CD pipelines include these checks, but ensure yours are robust and up-to-date.

Why this matters: Automated scanners are your first line of defense. They can catch many issues before they reach production.

Second, package locking is your friend. Tools like npm shrinkwrap or yarn.lock for JavaScript, or pip freeze and requirements.txt for Python, create a definitive list of exactly which versions of every package your project uses. When you add a new package, it gets locked in. If an attacker later tries to hijack that package name, your lockfile will prevent the new, malicious version from being installed unless you explicitly update it.

The catch: Lockfiles are excellent for preventing unintended updates, but they won’t stop you from manually or accidentally updating to a malicious package if you’re not careful.

Third, consider private registries or curated package sources. For critical applications, you might restrict your developers to using only packages that have been vetted and approved, and are hosted in a trusted internal repository. This adds an extra step but significantly reduces the risk of pulling in rogue code from public sources.

Fourth, and perhaps most importantly, manual verification is non-negotiable for new dependencies. When an AI assistant suggests a new package, developers should treat it with skepticism. They need to take a moment to:

  • Search for the package name on the official repository (npmjs.com, pypi.org).
  • Check its popularity and history: Does it have many downloads? Is it well-maintained?
  • Review the code itself, especially if it’s a critical piece of functionality. This sounds like a lot of work, but it’s far less work than cleaning up after a major security incident.

The real answer: Treat AI suggestions as starting points, not finished products. You still need human oversight.

The broader lesson here is about the nature of AI-generated code. While incredibly useful, these models are essentially sophisticated pattern-matching machines. They learn from vast amounts of existing code, but they don’t understand code in the way a human does. They can, and do, make mistakes. They can “hallucinate” non-existent libraries or even introduce subtle bugs.

Think of it like getting instructions from a brilliant but sometimes forgetful assistant. They might give you the perfect recipe for a cake, but occasionally, they’ll confidently tell you to add an ingredient that doesn’t exist, or misremember a crucial step. You wouldn’t bake that cake without double-checking the recipe, would you? The same caution must apply to AI-generated code.

This slopsquatting phenomenon is a stark reminder that as we integrate AI more deeply into our workflows, we must remain vigilant. The attack surface for software has just expanded, and the methods of exploitation are becoming more sophisticated, directly targeting the human-AI interaction.

Frequently Asked Questions

What is slopsquatting? Slopsquatting is a supply chain attack where attackers register package names suggested by AI coding assistants that don’t actually exist, and then publish malware under those names.

How do attackers find these non-existent packages? Attackers monitor the output of AI code generation tools for package names that are suggested but do not appear in public repositories like npm or PyPI.

Can dependency scanning tools detect slopsquatting? Yes, advanced dependency scanning tools can help identify newly registered packages or those with suspicious characteristics, which can be an indicator of slopsquatting.

Is using an AI coding assistant inherently dangerous? Not necessarily. AI assistants are powerful tools, but their output, especially for new dependencies, requires careful verification by developers to ensure security.