What Is a Subdomain Takeover, and How Do You Check for One?

A subdomain takeover is one of the few web vulnerabilities where the fix is nearly free and the exploit is nearly automatic, and yet it keeps showing up in bug bounty reports at companies with otherwise strong security teams. Here's exactly how it happens, how to check whether any of your own subdomains are exposed, and how to close it.

What subdomain takeover actually is

Every subdomain, like blog.example.com or app.example.com, points somewhere via a DNS record. Often that record is a CNAME pointing at a third-party service: a page builder, a help desk platform, a CDN, a cloud storage bucket. As long as that third-party resource is claimed and active, everything works. The problem starts the moment the resource is deleted or expires, but the DNS record pointing at it is not.

That orphaned DNS record is called a dangling CNAME. Your subdomain is still technically live from DNS's point of view, it's just pointing at an address nobody owns anymore. Most of the services this happens with (GitHub Pages, Heroku, Shopify, Vercel, Netlify, Fastly, and dozens of others) let anyone sign up and claim an unclaimed resource name. If an attacker notices the dangling record before you do, they register that exact resource on the third-party service, and your subdomain now serves whatever content they want, under your own domain name.

How a subdomain becomes takeover-able

The pattern is almost always the same sequence of ordinary, individually reasonable actions:

1. Someone on the team spins up promo.example.com pointing at a landing-page builder for a one-off campaign.
2. The campaign ends. The landing page gets deleted from the builder's dashboard, that part of the cleanup checklist gets done.
3. Nobody removes the DNS CNAME record, because DNS cleanup isn't on the checklist, or the person who set it up has since left.
4. Months or years later, an attacker running routine subdomain enumeration against your domain finds promo.example.com still resolving to the builder's platform, requests that exact custom domain slug on the builder, and it's theirs.

Nobody did anything wrong at any individual step. That's exactly why this is so common, it's a process gap, not a coding mistake.

Why it's worse than it sounds

A takeover isn't just an embarrassing 404 page. Once an attacker controls the endpoint, they control a page served under your real, trusted domain, and most cloud providers will issue that attacker a completely valid TLS certificate for it, since from the provider's side they legitimately proved control of the resource. That page can be used to:

• Host phishing pages that inherit your domain's reputation and any existing trust users have in it
• Steal session cookies scoped to the parent domain, depending on cookie configuration
• Serve malware from what looks, to every automated scanner and every user, like your own infrastructure
• Damage SEO and brand trust once the abuse is discovered and reported

How to check your own domains

Checking manually means, for every subdomain: resolving its DNS record, checking whether it's a CNAME pointing at a third-party service, and if so, fetching the page to see whether it shows a "not found" / "unclaimed" message specific to that provider (GitHub Pages, Heroku, and Shopify each have a distinct one). Doing that by hand across dozens or hundreds of subdomains isn't realistic, which is the entire reason automated tools exist for this.

How to fix it

• Remove the dangling DNS record if the subdomain is no longer in active use, this is the fix in the vast majority of cases.
• If the subdomain is still needed, re-claim the resource on the third-party service before anyone else does.
• Build DNS cleanup into your offboarding checklist for every campaign, staging environment, or third-party integration, not just an afterthought.
• Re-scan periodically. New subdomains and new dangling records get created continuously as teams grow, a one-time check only catches what exists today.

Frequently asked questions