Subdomain takeover is one of those vulnerabilities that sounds exotic until you see it on a production marketing domain. The root cause is usually mundane: a CNAME still points at GitHub Pages, Heroku, Azure, or another SaaS endpoint, but the tenant behind that endpoint was deleted. An attacker claims the orphaned target and serves content on campaign.yourbrand.com. Your users trust the subdomain because it is yours.
This playbook explains how takeover works, where dangling records come from, and how to find them with low-noise tooling before launch, after vendor offboarding, and during periodic attack-surface reviews.
How Takeover Actually Happens
Most takeovers follow the same pattern. Your DNS publishes CNAME promo.example.com → old-service.example.net. The SaaS account that owned old-service is gone, but DNS never changed. The provider shows a "not found" or "claim this name" page. The attacker creates a new account, verifies the name, and publishes phishing or malware under your subdomain.
Impact includes cookie scope confusion (if parent cookies are too broad), phishing that bypasses email filters, and abuse of brand trust. It is not theoretical: bug bounty programs and incident reports regularly pay for dangling CNAMEs on major domains.
Where Dangling Records Come From
Common sources include retired marketing microsites, A/B test hosts, acquired-company DNS imports, CDN or WAF cutovers left half-finished, and contractor-managed DNS that nobody audited after a project ended. SaaS offboarding is a repeat offender: the team deletes the S3 bucket or Heroku app but not the CNAME.
Inventory Before You Scan
You cannot fix what you have not listed. Start with passive subdomain discovery to collect hostnames from public sources without aggressive brute force. Compare results to your internal CMDB or registrar DNS export. Unknown hosts are either legacy debt or shadow IT.
Finding Vulnerable CNAME Chains
The subdomain takeover scanner focuses on CNAME targets associated with claimable services and verifies live HTTP responses that indicate an unclaimed resource. It is designed for defenders: evidence-first output you can attach to tickets, not blind exploitation.
Run it on your apex domain after:
- Retiring a campaign subdomain
- Switching CDN or hosting vendors
- Merging DNS zones from an acquisition
- Any incident where an unknown subdomain appeared in logs
Remediation Playbook
When you confirm risk, pick one path and document it:
- Remove the CNAME if the subdomain is unused. Delete the record and confirm nothing legitimate still resolves.
- Reclaim the target if the subdomain is still required. Recreate the SaaS tenant or point DNS at infrastructure you control.
- Replace with A/AAAA only when you operate the destination directly; do not point at shared SaaS names you might abandon again.
- Monitor with scheduled rediscovery after major marketing or infrastructure changes.
Our fix guide for orphaned subdomains walks through DNS cleanup and verification steps in more detail.
Prevention Habits
Pair DNS changes with offboarding checklists: "delete app" and "delete CNAME" must be the same ticket. Use short TTLs during migrations so mistakes are reversible. Restrict who can create public subdomains in SaaS consoles tied to your domain.
Takeover risk also intersects with broader common website security mistakes like exposed admin paths on forgotten hosts. Clean DNS and scan those hosts if they still resolve.
Providers Commonly Linked to Takeover
Not every CNAME is equal risk. Takeover scanners focus on providers where unclaimed names can be registered by a third party: GitHub Pages, Heroku, Azure App Service, AWS S3 static website endpoints, Fastly vacant hosts, Shopify partner domains, and similar SaaS patterns. The HTTP response often includes distinctive error text—"There isn't a GitHub Pages site here," "No such app," or provider-specific claim flows.
Internal teams underestimate how many marketing tools create these records. Landing page builders, status pages, documentation hosts, and short-lived campaign microsites each add a CNAME. When the subscription lapses, the DNS record frequently outlives the account.
Cookie Scope and Session Impact
If your apex domain sets cookies with a broad Domain=.example.com scope, content served on a compromised subdomain may inherit session context in some browser configurations. Even when cookies are scoped correctly, users still trust the hostname in the address bar. Phishing on login.example.com that you do not operate is indistinguishable from your real login page to most visitors.
Security reviews should ask two questions for every public subdomain: who operates the destination today, and would we notice if it changed tomorrow?
Bug Bounty and External Discovery
Researchers and automated scanners continuously probe popular domains for dangling CNAMEs because payouts are predictable and remediation is usually straightforward for the asset owner. Passive discovery plus takeover verification is the same workflow defenders should run proactively. Treat external reports as confirmation that your inventory process needs tightening, not as one-off noise.
When You Suspect Active Abuse
If unknown content appears on your subdomain, assume incident status until proven otherwise. Capture DNS snapshots, HTTP headers, and page hashes. Remove or reclaim the CNAME immediately. Review certificate transparency logs for unexpected issuances on the affected name. Notify legal and communications teams if customer data or brand impersonation is involved. After cleanup, rescan with passive discovery and the takeover scanner to confirm no sibling hosts share the same failure mode.
Evidence Teams Should Capture
Store DNS zone exports before and after remediation, HTTP response hashes for suspicious hosts, and scanner output for audit trails. When legal or insurance asks whether you exercised reasonable care, timestamps matter as much as the fix itself.
Quarterly Rediscovery Habit
Takeover risk is not launch-only. Schedule passive discovery and takeover scans quarterly and after any acquisition, rebrand, or major SaaS offboarding. Marketing calendars change faster than DNS tickets close—automate reminders tied to campaign end dates when possible.
Next Steps
Run passive discovery, follow with the takeover scanner, fix dangling CNAMEs, and rescan to confirm closure. For ongoing exposure tracking, combine this playbook with vulnerability scanning best practices and scheduled checks from the Vulnify dashboard.
Frequently Asked Questions
What is subdomain takeover?
Subdomain takeover happens when a DNS record (usually a CNAME) points to a third-party service you no longer control, and an attacker registers that name on the provider to host content on your subdomain.
How do I find dangling CNAME records?
Start with passive subdomain discovery to list hosts, then run a subdomain takeover scanner on your apex domain to match CNAME targets against unclaimed SaaS fingerprints.
Is subdomain takeover still common in 2026?
Yes. Marketing subdomains, legacy campaign hosts, and half-finished cloud migrations still leave dangling records. Automated scanners and bug bounty reports find them regularly.
Does a WAF stop subdomain takeover?
No. Takeover is a DNS and hosting ownership problem. A WAF on your main site does not protect orphaned subdomains that still resolve elsewhere.
Which subdomains are highest risk?
Short-lived marketing hosts, acquired-company zones, and names pointing at SaaS platforms you no longer pay for. Any CNAME to a shared cloud endpoint you do not actively manage should be treated as suspect until verified.
How fast can an attacker claim a dangling subdomain?
Minutes to hours once detected. Automated tools monitor certificate transparency and DNS changes continuously, so delay between discovery and abuse can be very short during active campaigns.