Your domain no longer lists what else an edge node has cached

An edge node answers a few addresses of its own: /workloads, /stats and /discover among them. They exist for operator tooling and for the browser code that fetches content from peers. They answered on every hostname the node served, customers’ domains included, so anyone loading /workloads on your domain got the content ID of every workload cached on that node, and /discover listed what each peer held. On a shared node, those were other customers’ sites.

The lists held content IDs, not content, and nothing in them could decrypt a Level 1 or Level 2 site. They did let anyone see which sites a node carried.

What changed, in two steps:

• v0.0.103 (2026-09-23): on a customer’s domain, /stats, /workloads and /gateway/* stopped answering and fall through to that site’s own pages, so your page or your 404 is served instead. /discover still answers, because browsers use it, but it now lists only your site’s own content ID, for the node and for every peer.
• v0.0.104 (2026-09-25): the node decided “is this my own address?” from the Host header, which the caller controls, so a request with a forged header could still reach the full lists. Those diagnostics now also require a connection from the node’s own machine.

For node operators

/stats, /workloads and /gateway/* now answer only to connections from the machine the node runs on. If you run the node in Docker with its port published and read these from the host, the requests arrive from Docker’s bridge network, so add that network to DIAGNOSTICS_TRUSTED_CIDRS. It’s empty by default, and nothing is trusted unless you list it.

Node-to-node content fetches are unaffected, so peer delivery works as before.

See also Pages at reserved-looking paths reach your site, the first part of this work.