Subdomain Takeover via a Dangling Enterprise-SaaS CNAME
Type: CWE-672 dangling DNS / Subdomain Takeover · Severity: High · Reported to a private bug-bounty program via HackerOne.
Target and vendor names are redacted per coordinated-disclosure rules. This write-up covers the technique only.
The finding
A support subdomain had a live CNAME pointing at a decommissioned enterprise-SaaS tenant (a privileged-access / support platform). The tenant target returned NXDOMAIN, meaning it was deleted/unclaimed and could be re-registered:
$ dig +short CNAME support.redacted.tld
tenant.saas-vendor.tld.
$ dig tenant.saas-vendor.tld A +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAINIf anyone provisions a tenant with that identifier on the SaaS platform, they instantly control the content served at the organization's support subdomain.
Why it matters
The pointed-to product was an enterprise privileged-access / support platform, and the subdomain was literally named support. For a security-sensitive organization this is a near-ideal phishing and credential-harvesting vector:
- Employees trust the
support.*subdomain as a legitimate internal portal. - Phishing links using the real corporate domain bypass spam/phishing filters.
- Advanced actors hunt abandoned SaaS endpoints on target perimeters for a foothold.
Ethics note
The SaaS platform had no self-service tenant signup — claiming the tenant would have required impersonating the organization through a sales process, which would be unethical and potentially illegal. The takeover was not executed; the DNS evidence (active CNAME + NXDOMAIN target) conclusively proves exploitability.
Remediation
Delete the dangling CNAME (zero-risk), or re-provision the tenant if the service is still needed. Preventatively, audit all external DNS zones for CNAMEs pointing at third-party SaaS providers.
