Subdomain Takeover: How a Deleted Cloud Resource Can Hijack Your Domain

Subdomain takeover is one of those vulnerabilities that sounds unlikely until you understand exactly how it happens — at which point it becomes clear why it's still found in production environments at large, well-resourced companies.

The Setup: A Dangling CNAME

It starts innocently: a team points a subdomain — say, blog.example.com — at a third-party platform like GitHub Pages or Heroku, using a CNAME record. Later, the project ends and someone deletes the GitHub Pages site or Heroku app, but nobody removes the CNAME record pointing to it.

The Takeover

Many platforms let anyone claim an unused project name. An attacker who finds that dangling CNAME can register the exact same resource name on the third-party platform — and suddenly their content is being served under blog.example.com, with your domain's trust and, often, your valid SSL certificate.

What It's Used For

A taken-over subdomain can host phishing pages that look completely legitimate (since the URL really is yours), serve malware, or bypass domain-based security checks and allowlists that assume anything under your domain is trustworthy.

Prevention Is Simple, Once You Know

The fix is straightforward: whenever a third-party-hosted project is decommissioned, delete the DNS record pointing to it in the same step, not as an afterthought. Periodically auditing your DNS zone for CNAME records pointing at deleted or unclaimed resources closes the gap for good.

Check for Dangling Records

Nexora Shield's Subdomain Takeover Checker tests a subdomain's CNAME target against known vulnerable service fingerprints to flag this exact risk.