Slopsquatting and HalluSquatting Are the Same Problem

Three names have been circulating for what turns out to be the same attack. Slopsquatting, phantom squatting, and HalluSquatting — named independently by different researchers and vendors — all describe a single structural problem: an AI coding agent generates a package name, repository reference, or domain name that doesn’t exist, and an attacker registers it before the developer notices.

ActiveState published analysis Thursday consolidating the three terms under a shared pattern they call late-binding. The agent produces a name, the developer accepts it, and the resolution happens later — against whatever actually owns that namespace by the time the code runs. If an attacker has already registered the hallucinated name, malicious code enters the pipeline without any obvious human error. The developer trusted the AI; the AI trusted a name it invented.

The mechanism is not new

Typosquatting has operated on this same principle for over a decade — register reqeusts or django-seccurity, wait for the inevitable human typo, and serve a payload. Supply chain attacks through package registries follow the same playbook: the target is whoever installs the package, not the registry itself. DPRK-linked operators have run exactly this strategy through npm and PyPI for years. Last week’s GitHub Actions and Packagist incident showed the same dependency-trust pattern applied to CI pipelines.

What’s changed is the error source. Before, it was human inattention. Now it’s LLM confidence. AI coding tools are trained to produce fluent, authoritative-sounding output and are not designed to flag when a package name they’ve suggested might not exist yet. The developer’s trust is reasonable — the model just explained a complex API call accurately — and then misplaced at the one moment that counts.

That combination of plausibility and invisibility is the effective attack surface. The hallucinated package name looks exactly like a real one. The AI offered it without hesitation. The developer didn’t check. The build system doesn’t check either unless you’ve specifically told it to.

What the controls actually are

ActiveState’s recommended mitigations are practical: pre-fetch name verification (confirm the package actually exists in the registry before it goes into the dependency file) and governed dependency management (an approved list of permitted packages that CI enforces at the pipeline level). Neither requires exotic tooling. Both require policy — making the check mandatory rather than leaving it to individual developer judgment, which is where this class of attack consistently wins.

The verification step in particular can happen automatically. Most modern package managers can be configured to fail fast on packages that aren’t yet present in the registry; the missing piece is usually organizational — nobody required it, so nobody set it up.

Three coinings, one pattern

The variety of names for this attack is informative in itself. Three independent terms before anyone consolidated the underlying pattern suggests that different people found the same intrusion from different angles — which tends to mean the attack is already operating, not theoretical. The organizations that encountered it presumably didn’t assign it a name at all.

This sits inside a broader convergence: AI agents are already being used for post-exploitation, rogue agents are being seeded inside enterprise workspaces via phishing, and now the AI coding assistant itself is a potential conduit for supply chain compromise. The threat model for AI tooling in the development pipeline is filling in quickly, and most organizations are still treating these tools as productivity features rather than security surfaces.

Supply chains have always been easier to compromise than the targets themselves. The tools in the pipeline just got a new way to make mistakes.