Run cloudflared tunnel --url http://localhost:8080 and Cloudflare hands you a working HTTPS endpoint on a random *.trycloudflare.com subdomain in about two seconds. No account, no signup form, no API key, no DNS record to point anywhere. Most engineers see a trycloudflare.com URL in a security alert and wave it through, because the tail of the domain reads as cloudflare.com and Cloudflare is infrastructure everyone already trusts.
That trust isn't misplaced about who owns the domain. It's misplaced about what the domain means. trycloudflare.com was registered in July 2018, its registrar is Cloudflare's own registrar service, and I checked the WHOIS record myself while writing this. Ownership isn't in question. What's in question is a separate axis entirely: whether any specific URL under that domain is trustworthy, which has nothing to do with who owns the parent zone. Anyone, anywhere, can spin up a quick tunnel pointed at whatever's running on their machine, get a TLS certificate Cloudflare vouches for, and tear the whole thing down seconds later — no DNS record, no WHOIS trail, nothing to subpoena.
What two years of threat intel show
This isn't theoretical. Proofpoint tracked a campaign starting February 2024 that used TryCloudflare's free tunnel feature to stage phishing lures leading to five separate RAT families: AsyncRAT, GuLoader, Remcos, VenomRAT, and Xworm. Message volumes ran from hundreds to tens of thousands per wave, hitting manufacturing, technology, finance, and law firms with lures in English, French, Spanish, and German. By mid-2024 nearly every campaign Proofpoint observed had converged on Xworm as the final payload.
The chain is worth naming because none of its individual steps look alarming in isolation: a phishing email links to a WebDAV share on a trycloudflare.com subdomain, which serves an LNK or VBS file, which runs a PowerShell stage, which pulls down a Python installer that finally drops the RAT — with a decoy PDF opened at the end so the target sees something plausible instead of a blank window.
The same mechanic shows up on the credential-theft side. Cofense's research into Cloudflare-service abuse found credential phishing via Cloudflare Tunnel and Workers climbing to its highest volume since they started tracking the pattern in 2021: fake Microsoft, banking, and crypto-wallet login pages, some run as full adversary-in-the-middle relays that sit between the victim and the real login server and forward the session token, not just the password. The subdomain is disposable by design, so a blocklist entry written this morning is chasing a domain that's already gone by lunch.
The allowlist mistake
The practical failure is allowlisting *.cloudflare.com and assuming it covers trycloudflare.com. It doesn't. They're different registrable domains, and a rule written against one silently does nothing against the other. “Hosted on Cloudflare's own infrastructure” and “safe to open” are unrelated facts for this specific domain, and treating them as the same fact is the entire reason the abuse pattern works. It isn't exploiting a flaw in Cloudflare's systems. It's exploiting the reader.
I watched the correct instinct play out on my own machine today. An agent working a client task wanted to spin up a quick tunnel for something completely benign — sharing invoice PDFs over HTTPS instead of email attachments. A safety classifier blocked the cloudflared tunnel call and required explicit human confirmation before it would run. The task was harmless. The block was still correct: a classifier that reasons from “this creates an anonymous, Cloudflare-signed public HTTPS endpoint” rather than “is this particular use fine” doesn't need to know the invoice PDFs were innocent to make the right call. That's what defense-in-depth looks like in practice — not catching an attack, just refusing to special-case a pattern that's identical to one, every time, regardless of who's asking.
None of this is unique to Cloudflare. ngrok, localtunnel, and every other zero-registration tunnel service have the same shape: free, instant, and unregistered by nature, so the pattern reappears under a different second-level domain the moment one gets blocklisted hard enough. Blocking trycloudflare.com by name is a patch, not a fix. The control that actually holds is gating on “anonymous tunnel to a random subdomain” as a category, not on whichever hostname it happens to be wearing this month.