RC RANDOM CHAOS

The host dials out, the internet walks in

Cloudflare Quick Tunnels expose a localhost service to the public internet over an outbound connection, with no account and no inbound port opened.

· 3 min read
The host dials out, the internet walks in

One command, cloudflared tunnel --url http://localhost:8000, hands anything running on your machine a public HTTPS URL. No Cloudflare account, no DNS record, no open port. Run it, copy the https://quiet-marble-otter.trycloudflare.com address it prints, and whatever was bound to localhost is reachable from anywhere on the internet in seconds.

The mechanism is what matters. cloudflared does not listen for inbound connections. It makes an outbound, encrypted connection from your machine to the nearest Cloudflare location and holds it open. Public requests hit Cloudflare’s edge, which routes them down that existing connection to your origin and returns the response the same way. Your router never accepts an inbound packet, and your IP stays behind Cloudflare. Automatic HTTPS and the edge’s DDoS protection come along because your traffic now sits behind it.

For the job it is built for, that is clean. Share a preview, receive a webhook, run a browser test against a real URL, or, in Cloudflare’s own framing, give a coding agent a real endpoint to call. Add --output json and a script or an agent reads the generated URL straight out of the command. Nothing to register, nothing to tear down, and the tunnel is ephemeral.

The same properties that make it convenient are the ones a security team has to account for. Most perimeter controls police inbound traffic. They block unsolicited connections, close ports, and inspect what tries to reach in. A Quick Tunnel opens nothing inbound. It rides an outbound, encrypted TLS connection from the host to Cloudflare’s edge. The outcome is a publicly reachable door into a service on an internal machine, stood up by a user with no account, no change request, and no inbound rule.

That is an egress-exposure problem. Running the command publishes a local service to the open internet with no account and no inbound port opened. There is no inbound listener to detect, because the connection runs outbound. The randomly generated trycloudflare.com subdomain is not a secret; it is obscurity, and the endpoint is live the instant the command returns.

Because the exposure is created from the inside out, the control sits at egress rather than at the firewall’s inbound rules:

  • Watching for newly opened ports will never catch this. Monitor outbound connections instead. The cloudflared process and its connection to Cloudflare’s tunnel edge are the signal.
  • The tunnel only exists while the host can reach Cloudflare; a host that cannot reach Cloudflare never forms one.
  • Inventory the cloudflared binary on endpoints. This mode needs no Cloudflare account, so wherever the binary runs, a Quick Tunnel can be stood up.
  • None of this happens unless the cloudflared binary runs on the host in the first place.

The command behaves identically whether a person or an automated process runs it. An agent or build step that pulls in cloudflared and runs it with --output json exposes a host exactly as well as a human typing the command, and does so without anyone watching a terminal.

Share

Keep Reading

Latest on the Wire

Full wire →

New signal daily · RSS

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.