What Is Subdomain Takeover and How Do You Prevent It?
Subdomain takeover happens when a DNS record, almost always a CNAME, still points at a third-party service you no longer control, and someone else is able to register that same resource on the platform, effectively taking control of what your subdomain serves.
Last updated: August 29, 2026
How it happens
Say blog.example.com is a CNAME pointed at a hosting platform like GitHub Pages, S3, Heroku, or Netlify. If that hosted resource is deleted or the subscription lapses, but nobody removes the CNAME record, the DNS entry keeps pointing at a resource name that no longer belongs to you. On many platforms, anyone can then register that same resource name for their own account, and once they do, blog.example.com resolves straight to content they control.
Why it's dangerous
An attacker-controlled subdomain of a domain people already trust is a strong platform for phishing, and depending on cookie scoping it can sometimes be used to read or set cookies that a browser considers to belong to your parent domain. It can also damage trust and brand reputation directly. Visitors have no way to tell the subdomain isn't yours anymore, and in some cases the attacker can even obtain a valid TLS certificate for it, making it look entirely legitimate.
How to prevent it
The core discipline is ordering: remove the DNS record before, or as part of the same step as, decommissioning the underlying service, never after. Beyond that, keep an inventory of every subdomain and what it points to, and periodically re-check that inventory for entries pointing at resources that no longer exist or were never claimed.
How to fix an active takeover
If a dangling CNAME is found, the fastest fix is simply removing the DNS record if the subdomain isn't in active use. If it needs to keep working, re-claim the underlying resource on the platform (register the same name under your own account again) before anyone else does.
Sweep common subdomain names for dangling CNAMEs pointing at third-party platforms that could be hijacked by an attacker.
Frequently asked questions
Which platforms are commonly affected?
GitHub Pages, Amazon S3, Heroku, Netlify, Vercel, and Microsoft Azure are among the most frequently seen, since they all allow a user to claim a resource by name and serve content under it.
Is every dangling CNAME immediately exploitable?
Not always. Some platforms show a generic error for an unclaimed resource without confirming it's re-registerable at that exact moment. It's still worth treating as a real risk and fixing promptly, rather than assuming a quiet failure means it's safe.
Does deleting the underlying app or bucket automatically remove the risk?
No. The risk lives in the leftover DNS record, not the deleted resource itself. Deleting the app without removing the CNAME is exactly the sequence that creates a dangling, takeover-prone record in the first place.
How do I find dangling subdomains on my own domain?
Sweep your known subdomains and check whether each CNAME target still resolves to something you actually control, and whether any point at a known third-party platform's "not claimed" state.