Banked: 2026-06-12 (Web2 passive sprawl recon, Spotify program)
Class: subdomain-takeover / SaaS dangling-custom-domain
Service: Atlassian Statuspage (*.stspg-customer.com)
When triaging a host CNAME'd to <token>.stspg-customer.com, fetching the RAW CNAME hostname
(https://<token>.stspg-customer.com/) returns 302 -> https://www.statuspage.io with
Server: AtlassianEdge for BOTH claimed AND unclaimed pages. Reason: Statuspage routes by the
Host header (the configured custom domain). A request whose Host is the raw *.stspg-customer.com
token does not match any custom domain, so it always bounces to the statuspage.io marketing root.
=> The raw-CNAME 302-to-statuspage.io is NOT, by itself, an unclaimed/takeover signal. False-positive risk if you stop there.
Fetch with the REAL host (real DNS / correct Host header) and compare against a claimed control on the same infra:
GET https://status.<claimed>.com/ -> HTTP 200 with header x-statuspage-version: <hash>.302 -> https://www.statuspage.io via AtlassianEdge (the "custom domain not connected to any page"
behavior). HTTPS handshake still completes (cert CN=*.statuspage.io) but no page body is served
for that Host.Always pull a sibling CLAIMED Statuspage on the same target as your control (e.g. on the Spotify
target, status.megaphone.fm = claimed 200+x-statuspage-version was the control that proved
status.adanalytics.spotify.com = dangling).
Heuristic rule: "Statuspage candidate = real-host fetch has NO x-statuspage-version AND bounces to
statuspage.io; confirmed by contrast with a claimed sibling that DOES carry x-statuspage-version."
Atlassian added optional custom-domain VERIFICATION (TXT record) on some tiers. Before claiming a Statuspage takeover as exploitable, confirm free-tier custom-domain binding still works WITHOUT a verification step for that host. If verification is enforced, a dangling CNAME downgrades to informational. The passive dangling fingerprint is real regardless; exploitability hinges on the binding flow.
This "raw-CNAME response is identical for claimed and unclaimed; you must test with the real Host and a claimed control" pattern applies to any Host-routed SaaS (Statuspage, some CDN-fronted SaaS, multi-tenant platforms). Do not fingerprint takeover off the raw CNAME endpoint alone - route by the actual custom domain Host and diff against a known-claimed sibling.
This sandbox intermittently drops the HTTPS GET body after a successful TLS handshake (code=000 / len=0) while the HTTP path returns cleanly. When HTTPS gives 000, fall back to HTTP-layer signal (status line, Location, Server) which was reliable here. Do not misread a sandbox-dropped HTTPS body as target behavior.