Slopsquatting is a software supply chain attack where criminals register malicious packages under the fake names that AI coding assistants invent, then wait for developers to install them. Because AI tools routinely recommend libraries that do not exist, attackers can turn a confident chatbot suggestion into a direct path into your build. The risk grows with every team that ships code written alongside an AI assistant, which is why defending the build itself matters.
What Is Slopsquatting?
The name “slopsquatting” is a play on “typosquatting” where “slop” refers to the low-quality output that AI models produce. When a developer asks a tool like ChatGPT or GitHub Copilot for help, the model sometimes recommends importing a library that sounds plausible but was never published on registries such as npm and PyPI. The hallucination arrives with the same confidence as a correct answer, which is what makes it dangerous.
What turns that glitch into a reliable attack is repetition. A USENIX Security 2024 study that generated 576,000 code samples across 16 large language models found hallucinated packages in 5.2% of output from commercial models and 21.7% from open-source ones, surfacing more than 205,000 unique fake package names. The fabricated names were far from random. The researchers found that 58% of hallucinated packages reappeared more than once across ten runs, and 43% recurred every time a prompt was repeated. That predictability lets an adversary run popular models, catalog the names they invent again and again, and register malicious libraries under those exact identifiers, confident that developers will eventually be told to install them.
How Does a Slopsquatting Attack Work?
The attack follows a clear chain, from a hallucination in an editor to malicious code running inside a production pipeline.
Step 1: An AI Assistant Hallucinates a Package Name
A developer prompts an AI assistant for code to solve a task. The model returns a working-looking snippet that imports a library such as aws-helper-sdk or fastapi-middleware, names that sound authentic but point to nothing real. The hallucination is delivered with the same confidence as a correct answer, which is precisely the problem.
Step 2: An Attacker Registers the Hallucinated Name
Attackers no longer need to guess which package names developers might mistype. They watch AI code-generation patterns, catalog the names that models invent repeatedly, and register those names in public repositories. The malicious package is then armed with a payload designed to steal credentials, exfiltrate data, or open a backdoor.
Step 3: A Developer Trusts the AI Output and Installs It
Faced with a plausible import statement, the developer accepts the recommendation without verifying that the package is real or checking who published it. With autonomous coding agents, even that brief human checkpoint disappears, because the agent can install dependencies on its own. In one documented case, a security researcher claimed an npm package that an LLM had invented, only to find 237 GitHub repositories already instructing AI agents to install it.
Step 4: The Build Pulls the Malicious Package
Once the dependency is declared, the CI/CD pipeline fetches and executes it during the build. A malicious dependency injected at this stage maps to MITRE ATT&CK technique T1195.001, compromising the software supply chain. The payload runs with the broad permissions that build environments typically hold, giving the attacker access to secrets, signing keys, and source code.
Slopsquatting vs. Typosquatting vs. Dependency Confusion
These three attacks share a goal but differ in the mistake they exploit. Typosquatting depends on human error. An attacker registers a misspelled version of a popular package, such as requsts instead of requests, betting that a developer fat-fingers the name. Dependency confusion abuses how package managers resolve names, tricking a build into pulling a malicious public package that shares a name with a private internal one, usually by publishing a higher version number. Slopsquatting introduces a third trigger: machine error. Instead of waiting for a typo or a naming collision, the attacker relies on an AI model to invent and recommend a name that no human ever intended to type. The defenses for one do not automatically cover the others, which is why software supply chain security tools need to account for all three.
Why Traditional Security Tools Miss Slopsquatted Packages
Most security stacks were built for a world where threats were already documented. Slopsquatting sidesteps that assumption.
Scanners Rely on Known-Bad Signatures
Vulnerability scanners and software composition analysis tools compare dependencies against databases of known-bad packages and disclosed CVEs. A freshly registered slopsquatted package has no history and no signature, so it passes inspection as a clean, unknown library.
Code Review Can’t Catch What Looks Legitimate
A human reviewer scanning an import statement sees a name that reads as a real, well-formed library. There is no typo to flag and no obvious red flag in the code. The malicious behavior lives in what the package does at install or runtime, not in how its name appears on the page.
Pre-Build Checks Don’t See Runtime Behavior
Checks that run before the build inspect code at rest. They cannot observe what a dependency actually does once the build starts executing it, such as reaching out to an attacker-controlled server or reading credentials from the environment. The damage happens during execution, where pre-build tooling has no visibility.
Stop Slopsquatting at Build Time With InvisiRisk
The moment a slopsquatted package runs is the moment that matters, and that is exactly where we operate. InvisiRisk’s Build Application Firewall (BAF) sits inline with your CI/CD pipeline as a proxy, performing deep packet inspection of every network transaction during the build. We watch what a build does in real time and enforce policy while it runs, rather than scanning code before or after the fact. So when a hallucinated package tries to reach an unauthorized destination, exfiltrate secrets, or pull in something the build was never authorized to touch, we detect it and block that behavior as it happens. Because we judge behavior instead of signatures, we catch malicious activity even from a package no scanner has ever flagged, including zero-day threats. You wouldn’t run a web server without a WAF, so why run a build system without a BAF?
Book a demo to see how InvisiRisk can secure your software supply chain.
