Quick answer: Slopsquatting is a supply chain attack that exploits an AI code assistant suggesting a software package that does not exist. Language models sometimes produce package names that are not real but look realistic, which is called hallucination. The attacker registers these imaginary names the model often produces into the package repository in advance with malicious content. When the developer trusts the assistant's suggestion and installs that package, the malicious code enters their project. This is the AI era relative of typosquatting, which tricks through name similarity. DSET evaluates this risk with its local AI engine KAOS and verifies every finding with a working proof.

AI code assistants increased development speed, but they brought a new trust problem. When an assistant suggests a library, most developers assume that the library really exists and is safe. Yet models from time to time make up package names that do not exist, and these made up names turn into a ready opportunity for attackers. This article explains what slopsquatting is, why it is dangerous and the DSET and KAOS approach.

What slopsquatting is

Typosquatting is registering a similar version of a common package name with a typo and waiting for the developer to mistype. Slopsquatting is a step different: the attacker does not wait for a typo, instead they target the imaginary package names AI models often produce. Research has shown that language models refer to non existent packages at a certain rate when suggesting code, and moreover produce the same imaginary name again and again. The attacker observes these predictable errors, registers the most frequently made up names into the package repository with malicious content and waits for the developer to install that package by trusting the assistant. The name comes from here: the model's untrusted output, that is slop, turns into an attack surface.

Why it is a dangerous supply chain attack

Slopsquatting is a classic supply chain attack, because the malicious code enters the project not directly but through a trusted dependency channel. Once installed, the malicious package runs everywhere the project runs.

Stage What happens Risk
Hallucination The model suggests a non existent package The developer trusts the imaginary name
Pre registration The attacker publishes that name with malicious content The imaginary name is now real and malicious
Installation The developer adds the package to the project Malicious code enters as a dependency
Spread The package runs at build and runtime Secret leakage, backdoor
Persistence The dependency stays in the project The attack lasts until it is noticed

The essence of the table is this: in slopsquatting the weak link is not the model itself but trusting the model's output blindly. For this reason the defense is to verify before installation whether each dependency really exists and whether it is trusted and maintained. This verification is part of the broader discipline of supply chain attacks and software dependency security.

Its relation to the security of AI generated code

Slopsquatting is only one of the risks AI code assistants bring. Assistants sometimes also produce insecure code, for example suggest an old encryption method or an open configuration; for this separate but related risk the topic of AI code generation security and Copilot review is the reference point. Both risks rest on the same root principle: no output AI produces, code or suggestion, should be considered trusted without verification. This principle also requires verifying the source and integrity of dependencies, which intersects with the topic of AI supply chain security and model provenance.

How to defend

The basis of the defense is to pass dependency installation through a human and automated verification gate. Every new package must be tested for whether it really exists in a known and trusted repository, whether its age and maintenance history are reasonable, and whether downloads and community trust are sufficient. Every package the AI assistant suggests must pass through this gate before installation. In addition the project's dependency tree must be scanned regularly, which should be run within the scope of source code security review and SCA.

The KAOS and DSET approach

DSET addresses slopsquatting and the hallucinated package risk as part of a software supply chain assessment, with its local AI engine KAOS. KAOS examines a project's dependency tree, flags non existent or newly registered suspicious packages and evaluates the real impact of a dependency under the principle of proof based verification. The difference is this: it does not settle for saying a package is theoretically suspicious, it examines whether that package actually contains malicious behavior. As an AI powered tool, KAOS itself is subject to this principle too, that is no output of the assistant is accepted without verification.

Frequently asked questions

Is slopsquatting the same thing as typosquatting? The two are related but their triggers differ. Typosquatting waits for a human typo, for example registers the one letter short version of a popular package name. Slopsquatting instead waits for an AI model's hallucination, that is it targets the non existent names the model makes up. The result of both is the same, a malicious package entering the project, but slopsquatting is a new path that emerged with the spread of AI assistants.

How do I know a package the assistant suggested is safe? Independently verify every suggested package before installing it. Check that the package exists in a known repository, has a reasonable history and maintenance record, and that its download count and community trust are consistent. An assistant suggesting a package does not prove it is safe, it only shows that the model produced that name.

Does this risk affect only a certain programming language? No, the hallucinated package risk can appear in every ecosystem that has a package repository. Whether it is a JavaScript, a Python or another language ecosystem, the AI assistant can suggest a non existent dependency. For this reason the defense is language independent: a dependency verification gate must be applied in every ecosystem.

Sources

To examine the dependency security of your AI generated code with a proof based assessment, contact DSET. We provide software supply chain security and source code review from our Ankara Hacettepe Teknokent laboratory.