Slopsquatting: attackers are registering the URLs your AI agent hallucinates

“Slopsquatting” started as a package-registry problem: an LLM asked to write code would occasionally invent a plausible-sounding npm or PyPI package name that doesn’t exist, and an attacker who noticed the pattern would register that exact name and fill it with malware, waiting for someone’s AI coding assistant to suggest the install command. Recent research from Unit 42 shows the same failure mode working against web domains, not just packages — and at a scale that makes it a supply-chain problem for anyone who trusts a URL an AI agent hands them.

The mechanism, and why it’s cheap to run

Unit 42 probed 913 global brands with 685,339 adversarial prompts across two model families, generating 2.1 million candidate URLs. Of those, roughly 809,000 pointed to domains that don’t exist — plausible-looking, brand-adjacent, and confidently presented as real. About 13,000 of the domains that were registered had already been flagged as malicious by threat-intelligence feeds, meaning attackers are already ahead of this. The researchers estimate roughly 250,000 hallucinated domains remain unregistered and sitting available, ready for anyone who notices the same pattern the researchers did.

The case study is the part worth sitting with. On March 8, 2026, Unit 42’s system predicted that models would invent a specific domain resembling a national postal service’s online marketplace — both model families generated it at every sampling temperature tested, a strong signal the hallucination was consistent rather than a one-off fluke. Twenty-three days later, on March 31, an attacker registered that exact domain and stood up a phishing kit — nicknamed Montana Empire — that harvested card numbers, bank-transfer details, and national ID data from anyone who landed on it believing it was official.

Why this isn’t a solved problem in newer models

It’s reasonable to assume model providers have mostly trained this behavior out by now. An arXiv preprint published in June 2026 tested five current frontier code-generating models against nearly 200,000 real coding prompts, checking every suggested package name against the actual PyPI and npm indexes. Hallucination rates ranged from about 4.6% to 6.1% depending on the model — lower than older benchmarks, but far from zero, and consistent enough across repeated runs that an attacker doesn’t need to guess once; they can run the same prompt repeatedly and watch which invented names keep reappearing before deciding which one is worth registering. The underlying failure — a model confidently inventing something that sounds real instead of admitting it doesn’t know — is the same one whether the output is a package name or a URL.

What to check before you click or curl something an AI gave you

Before trusting a model-suggested URL

Don't run this blind just because an agent, chat answer, or MCP tool response suggested it:$ curl -sI https://suggested-domain.exampleCheck instead: does the domain match the vendor's own published docs/site?$ whois suggested-domain.exampleA domain registered in the last few weeks, for a brand that's been around for years, is a strong red flag.

The habit worth building is treating a model-suggested URL the same way you’d treat an unsolicited link in an email — plausible-looking is not the same as verified. A few concrete checks that catch most of this:

• Cross-check against a source you already trust — the vendor’s own published documentation, a bookmark you set previously, or a search result, rather than clicking straight through from a chat answer or a code comment.
• Look at domain age. A brand-adjacent domain that’s a few weeks old is exactly the pattern Unit 42’s case study describes — legitimate services rarely spin up new top-level domains for existing products.
• Be more suspicious of package and dependency suggestions than of prose. An agent suggesting npm install <package> or a pip install command is effectively asking you to execute code from wherever that name resolves to — worth the extra ten seconds to check the name actually exists on the real registry before running it.
• Treat MCP tool responses the same as any other untrusted input. If a tool call returns a URL, that URL came from wherever the tool’s data source pulled it from, not from a vetted allowlist — the same least-privilege scoping habit that applies to API credentials applies to trusting what a tool hands back, too.

Why “the model will get better at this” isn’t a fix on its own

It’s reasonable to expect hallucination rates to keep falling as models improve — the arXiv study’s 4.6%–6.1% range is already lower than hallucination rates reported against older model generations. But a shrinking rate doesn’t shrink the attack surface as much as it sounds like it should, for two reasons. First, a lower percentage against a larger number of daily model queries can still mean a growing absolute count of hallucinated names and domains, since usage volume is growing faster than the rate is falling. Second, and more importantly for an attacker, consistency matters more than frequency — Unit 42’s postal-service example worked precisely because two separate model families invented the same domain across every temperature setting, not because either model hallucinated often. A rare but highly reproducible hallucination is more valuable to register than a common but random one, because reproducibility is what tells an attacker which invented name is actually worth the cost of squatting on.

None of this requires distrusting AI-assisted coding or agent tooling wholesale — it requires the same verification discipline that already applies to any input you didn’t type yourself. The difference in 2026 is that the thing generating the untrusted input is now something your own tooling asks for advice dozens of times a day, which is exactly why attackers have started optimizing for what it’s likely to say.

The MCP-specific version of this check

If you’re connecting an agent to a real MCP server rather than just asking a model to write code, the same discipline applies to the connection string itself, not only to what the tool later returns. Norbelys publishes exactly one MCP endpoint — mcp.norbelys.com/mcp, listed on the developer docs — which is worth stating plainly precisely because a hallucinated or squatted look-alike domain for a real product’s MCP server is the same attack this post describes, aimed at whichever tool you connect an agent to next. Copy the URL from Norbelys’s own published docs, the way you’d verify any other domain in this post’s checklist, rather than trusting whatever a model or a search result hands you — and once connected, scope the credential you hand that connection the same way you’d scope any other API key, since a squatted server and a leaked key both cash out the same way: an agent doing something with more reach than you meant to grant it.