Slopsquatting: attackers register package names that AI assistants hallucinate

Attackers have found a cheap route into developer machines: registering package names that AI coding assistants invent. A recent explainer on dev.to breaks down the technique, known as slopsquatting, how a hallucinated import turns into executed code, and the habits that blunt it.

How the attack works

According to the dev.to post, the sequence starts when a language model suggests a plausible-sounding package that does not exist on npm or PyPI. Because models predict plausible text, an invented package name reads exactly like a real recommendation, and a model can repeat the same invented name across many conversations. Someone notices the name in a chat log, tutorial, public repository or forum answer, registers it on a registry with malicious code inside, and waits. The next developer, or the next AI agent, who follows the suggestion runs the install and receives the attacker's code instead of an error.

The post positions slopsquatting as a relative of typosquatting, where an attacker registers a misspelling of a popular package. The difference is the origin of the wrong name: a human typo reaches one victim, while a model's invention is confidently repeated to many people, which makes registration worthwhile. Before registration, a made-up name fails loudly with a 404; afterwards, the install succeeds and everything looks normal.

Why an install executes code

Installing a package is not just downloading files. On npm, a package can declare preinstall, install or postinstall lifecycle scripts that run automatically during installation, with the user's permissions. On the Python side, a prebuilt wheel does not run package code, but a source distribution must be built first, and the build step (such as a setup.py file) runs the author's code. Even with install scripts disabled, a package's top-level code runs the first time it is imported, in both ecosystems.

That reach matters: on a laptop it means the shell environment, SSH keys and cloud credentials; in CI it means deploy tokens, registry credentials and cloud keys visible to the job. The post stresses this is documented, legitimate npm behavior used for native builds — the danger lies in running an install without knowing whose code it is.

Why AI tools raise the stakes

Assistants do not consult a registry while writing; they produce a package name the same way they produce a function name, and it inherits the trust given to the rest of the answer. Agentic tools compound the problem, the post argues: a chat assistant hands you a command to run, but a coding agent with shell access may run the install itself, mid-task, unobserved. The recommendation is least privilege for agents — package installs should require explicit approval. The author frames this as part of a broader pattern of vibe-coded security flaws: the tool optimizes for output that works, and verifying where a dependency comes from was never part of the objective.

Defenses the post recommends

Verification comes first: check that a suggested package exists using npm view or its PyPI page, take install commands from the project's official documentation rather than the chat, and read the signals — registry age, version history, maintainers, a repository link that resolves, download counts. These are filters, not proofs, but they catch a squat registered days ago with one version and no source link.

Second, commit lockfiles and install from them: use npm ci in CI and Docker builds, and pin pip versions with hashes so a swapped file is rejected. Lockfiles do not make a bad package safe, but they stop it changing after review.

Third, treat dependency changes like code. A new line in a manifest is a trust decision; make it visible in pull requests, require a human to review every dependency an agent adds, and question tiny packages that do something the assistant could have written inline.

Fourth, vet with scripts off: npm install --ignore-scripts blocks lifecycle scripts, and pip install --only-binary :all: refuses source builds. The post caveats that these are vetting aids, not safe modes — legitimate native builds break without their install step, and import-time code still runs.

Finally, limit the blast radius: assume something malicious will eventually run during an install, and give CI jobs only the secrets they need, so a build-and-test job never sees production deploy credentials.

Why it matters

Slopsquatting requires no vulnerability in any tool. It exploits a natural property of language models — invented names that sound real — combined with the trust developers extend to assistant output and the fact that installs execute code. As agents gain shell access, the distance between "suggested a name" and "ran attacker code" collapses unless installs are gated. The defenses are old discipline made newly load-bearing: verify, pin, review, isolate. The post also notes that every package name it uses is invented for illustration — if one appears on a real registry, that is the attack in action.