On a subdomain Multisite install, WordPress by default scopes its auth cookies to the network domain: ms_cookie_constants() sets COOKIE_DOMAIN to '.' plus the network's cookie_domain if one is set, otherwise the network domain. (ms_cookie_constants reference)

Why it matters: say old-staging.example.com was CNAMEd to a host or page builder, the account was closed, and the DNS record stayed. If that provider lets anyone claim an unclaimed hostname, someone else can serve content on your subdomain (OWASP calls this subdomain takeover).

The record itself leaks nothing. The risk is that when a logged-in admin's browser makes a request to that subdomain, it sends any cookie whose Domain, Path and Secure attributes match, including wordpresslogged_in*, to the server the other person now controls. (MDN on Set-Cookie)

To find candidates, start from your DNS zone. One useful cross-check is certificate transparency logs (crt.sh, query %.example.com), which often surface old hostnames that got their own certs. They won't list names covered only by a wildcard cert, so treat them as a supplement. Then for each name:

dig +short CNAME old-staging.example.com dig old-staging.example.com # NXDOMAIN vs NOERROR curl -sI https://old-staging.example.com

A CNAME whose target returns NXDOMAIN is the classic red flag. A provider's generic "no such site" page only matters if that provider actually lets a stranger claim the name, so check their docs.

When you decommission, remove the DNS record first, then delete the environment or cancel the service. The other order leaves a window where the name points at something nobody owns.

For those running subdomain networks or sharing COOKIE_DOMAIN: do you audit the zone when a site leaves the network, or does DNS just accumulate forever?