What Is Subdomain Takeover? Explained

A subdomain takeover happens when a DNS record for one of your subdomains — a CNAME pointing to a third-party hosting service, most often — still exists after you’ve stopped using that service, letting anyone else claim the now-unclaimed resource and have your subdomain resolve to content they control.

How it happens

Most subdomain takeovers follow the same sequence. A team points blog.example.com at a hosted platform via a CNAME record — a static site host, a help-desk widget, a marketing landing-page builder, a CDN endpoint. Later, the team stops using that service: the project ends, the account is deleted, the trial expires. Someone forgets to remove the CNAME record from DNS. The subdomain still resolves to the hosting provider’s infrastructure, but the specific resource it used to point to — the site, the bucket, the app — no longer exists there.

Because many hosting platforms let anyone register a new resource with an arbitrary name, an attacker can go to that same platform, claim the exact identifier your dangling CNAME still references, and suddenly blog.example.com serves whatever content they put there — under your domain, with your domain’s reputation and, if you’re using HTTPS with automatic certificate issuance, often a valid TLS certificate for it too.

Why the impact is worse than it looks

A takeover of an obscure, low-traffic subdomain still causes real damage because the content resolves under your organization’s actual domain name:

• Phishing with a trusted domain. A page at careers.example.com or promo.example.com looks legitimate to users and to automated scanners alike, because the domain genuinely belongs to you — DNS says so.
• Cookie and session theft. If your site sets cookies scoped to the parent domain (no Domain restriction narrower than necessary), a taken-over subdomain can potentially read cookies meant for your main application, undermining assumptions baked into the same-origin policy.
• Content Security Policy bypass. If your CSP allowlists your own domain or a wildcard subdomain as a trusted script source, an attacker who takes over any matching subdomain can serve JavaScript that your own Content Security Policy explicitly trusts.
• Certificate Transparency false trust. Because the takeover is on real DNS infrastructure, a certificate issued for it appears legitimately in Certificate Transparency logs, giving no obvious red flag to anyone monitoring for spoofed lookalike domains.

What makes a record vulnerable

Not every dangling record is exploitable — it depends on whether the target service lets a third party claim an unclaimed name. Services vulnerable in this pattern typically share three traits: they identify resources by a name the customer chooses, they let anyone create an account and register that name, and they don’t verify domain ownership before serving traffic for it. Static site hosts, some CDN edge configurations, help-desk and support-widget platforms, and app-hosting PaaS providers have all had this failure mode at various points. The common root cause across all of them is the same: a CNAME or similar record survives the deletion of what it pointed to.

Finding and fixing dangling records

The fix is mostly hygiene, not new tooling:

1. Inventory every DNS record. Pull the full zone file and check every CNAME, and any A/AAAA record pointing at a third-party IP range, against what’s actually still provisioned on the target service.
2. Remove records when you decommission a service, not “eventually” — make it a standard step in the offboarding checklist for any external platform, the same way you’d remove an unused API key or revoke unused credentials.
3. Re-claim what you can. If a record is dangling and the platform still allows registering that exact resource name, claim it yourself even if you don’t plan to use it, to close the window before someone else does.
4. Monitor periodically. Because this is a hygiene failure rather than a code vulnerability, periodic re-scans of the zone file catch drift that a one-time audit won’t — teams change tools and forget cleanup steps continuously, not just once.

The takeaway

Subdomain takeover isn’t a flaw in DNS or in the hosting platforms it points to — it’s what happens when a pointer outlives the thing it points to, on infrastructure that lets strangers claim orphaned names. The fix costs nothing but discipline: audit DNS records regularly, delete them the moment a service is decommissioned, and treat a dangling CNAME with the same urgency as an exposed credential, because in practical terms that’s exactly what it is.