Slopsquatting turns AI-hallucinated packages into supply chain attacks

Slopsquatting is what happens when an attacker registers a package name that an AI coding tool made up, then ships malware under it. The developer asks an assistant for code, the assistant recommends a library that doesn’t exist, and the developer runs the install command. If the attacker got to that name first, the attacker’s code is now on the developer’s machine.

The name blends “slop,” the slang for low-quality AI output, with “squatting,” the old habit of claiming names you don’t own. Security teams will recognize the pattern from typosquatting, where attackers register misspellings of popular packages. Slopsquatting uses names that never existed until a model made them up. Both are software supply chain attacks, and both put malicious code into a build.

AI models invent package names, and the names repeat

Researchers at the University of Texas at San Antonio, the University of Oklahoma, and Virginia Tech generated 576,000 Python and JavaScript code samples across 16 language models, and 19.7% of the packages those samples recommended did not exist. Commercial models averaged at least 5.2% hallucinated packages and open-source models averaged 21.7%. Across all models, the study logged 205,474 unique made-up names. The study was presented at USENIX Security 2025. It tested models available in early 2024, and the authors note that newer models may behave differently.

The same fake names come back. When the researchers re-ran 500 prompts that had produced a hallucination, 43% of the invented packages appeared in all 10 repeat runs, and 58% appeared more than once. That gives an attacker a short, predictable list of names worth registering.

Few of the invented names resemble real ones. Among the Python hallucinations, only 13.4% sat one or two characters away from a real package, and 48.6% were very different from any real name.

Checking a suggested name against a list of known packages doesn’t solve it. An attacker may already have published malware under that name, so the package will look like it exists.

Attackers register the names and wait

An attacker prompts popular models with common coding questions and writes down every package name that doesn’t exist. They register those names on public registries such as npm or PyPI, then publish a package that does roughly what a developer would expect, with a hidden payload added.

Eventually a developer gets the same recommendation and pastes the install command. Installing an open source Python or JavaScript package can let its author run arbitrary code on the machine, so the payload can fire during the install, before anyone reads a line of the package’s code.

A developer laptop holds cloud keys, API tokens, SSH keys, source code, and VPN access. Compromise one and the attacker has a foothold in the build pipeline, with a route into production behind it.

Vibe coding removes the last checkpoint

Vibe coding means accepting AI-generated code with little review, and review is the one step that could catch a bad package name. The attack depends on a user who installs recommended packages without sufficient verification, trusting the model to name only real ones. Nobody reads the dependency list, so a library no one has heard of goes in without a second look. People building internal tools with an assistant may not know what a legitimate library looks like, so they’re even less likely to notice. Reviews that read only the generated code never see the dependency, a blind spot in AI code security.

Developer endpoints need limits of their own

Pipeline controls cut down on bad packages getting in. They can’t promise zero, and a package that gets through runs on a developer’s endpoint.

Netwrix PolicyPak applies endpoint controls through Group Policy, MDM, or its cloud service. PolicyPak removes local admin rights and uses secure elevation rules, so developers get the access approved tasks need and nothing more. Its allowlisting, based on file ownership, blocks untrusted applications and scripts from running, which limits what a malicious package can do once it lands on a machine.