Subdomain takeover is a vulnerability class where an attacker gains the ability to serve content on a subdomain of a target organization. The attack does not require exploiting a code vulnerability. It exploits a DNS misconfiguration where a DNS record exists but the resource it points to has been decommissioned and is now claimable by anyone.
The issue is particularly common in organizations that actively use cloud services and SaaS platforms, because DNS records are often added when a service is provisioned and not cleaned up when the service is deprovisioned.
The Mechanics of a Takeover
Consider a common scenario: an organization creates a subdomain blog.example.com and configures it as a CNAME pointing to example.github.io (their GitHub Pages site). Later, the organization discontinues the GitHub Pages site and deletes the repository, but forgets to remove the CNAME record from their DNS zone.
The DNS record still resolves. A request to blog.example.com sends the browser to GitHub Pages infrastructure, but there is no repository claimed for that hostname. GitHub Pages will return a 404. At this point, an attacker can create a GitHub account, create a repository, and configure it to serve at the example.github.io hostname. Because the CNAME still points there, requests to blog.example.com will now serve the attacker's content.
The subdomain is under the organization's domain name, carries valid TLS certificates (many platforms issue certificates automatically), and appears legitimate to users.
Commonly Affected Services
Subdomain takeover risk is present wherever a service allows users to configure custom hostnames and the hostname is released when the user removes it from their account. Services commonly seen in takeover disclosures and research include:
- GitHub Pages (CNAME to
username.github.io) - Heroku (CNAME to
*.herokudns.com) - Netlify (CNAME to
*.netlify.app) - Vercel (CNAME to
*.vercel.appor A records to Vercel IPs) - AWS Elastic Beanstalk (CNAME to
*.elasticbeanstalk.com) - Azure App Services (CNAME to
*.azurewebsites.net) - Fastly (CNAME to
*.fastly.net) - Tumblr (A record to Tumblr IPs)
- Ghost/Squarespace/Shopify hosted subdomains
This list is not exhaustive. Any SaaS platform that supports custom domain mapping has the potential to be an attack vector when DNS records are not cleaned up on deprovisioning.
Impact
The impact of a subdomain takeover depends on what the attacker does with the claimed subdomain. Confirmed impact scenarios include:
- Phishing: The attacker serves a page impersonating the organization, using the legitimate subdomain to bypass domain reputation checks in spam filters and browser security UIs.
- Cookie theft: If the vulnerable subdomain shares a parent domain with the main application and cookies are scoped to the parent domain (e.g.,
Domain=.example.com), an attacker with control over any subdomain can read those cookies. This gives access to any session tokens stored in parent-scoped cookies. - Cross-site scripting: An attacker can serve JavaScript from a legitimate subdomain. If the main application allows the subdomain as a CSP script source, this becomes an immediate XSS vector.
- Reputation and trust abuse: Serving malicious or spam content from a legitimate organizational subdomain damages domain reputation, which can affect email deliverability and search indexing for the entire domain.
Detection
Identifying Dangling DNS Records
A dangling DNS record is one that resolves to an address or hostname, but the target is no longer claiming that hostname. The detection process involves:
- Enumerating the DNS records for a domain (CNAME, A, AAAA, NS).
- For each CNAME, resolving the final target and checking whether the target service shows a "not found" or "unclaimed" response.
- For A records pointing to cloud provider IP ranges, checking whether the IP is responding and whether the response is a claim-not-found page.
The detection logic must account for service-specific fingerprints. GitHub Pages returns a specific 404 page format for unclaimed custom domains. Heroku, Netlify, and Fastly each return distinct error responses for unclaimed hostnames. Matching against these fingerprints reduces false positives compared to treating any non-200 response as a takeover indicator.
How WebDefect Detects Takeover Risk
WebDefect includes a subdomain takeover check in its DNS and discovery phases. The scan:
- Enumerates CNAME chains for the scanned domain and any discovered subdomains.
- Matches CNAME targets against a list of platforms known to have claimable namespace patterns.
- Fetches the target URL and checks the response body against service-specific unclaimed resource fingerprints.
- Classifies confirmed dangling CNAMEs pointing to claimable services as high severity findings.
- Classifies CNAME targets that could not be verified (e.g., the target service returned a connection error rather than an unclaimed-resource page) as medium severity findings requiring manual investigation.
WebDefect does not attempt to claim any resource. The scan is read-only and observational.
Remediation
The fix for a dangling DNS record is to remove the record. If the subdomain is no longer used, the DNS record should be deleted entirely. If the service needs to be re-provisioned, configure the service first and create the DNS record only after the service is configured to claim that hostname.
If cookie sharing between the vulnerable subdomain and the main application is a concern, review all cookies that use parent-domain scoping (e.g., Domain=.example.com) and consider restricting them to the specific host that sets them.
For platforms where the hostname must remain configured while a migration occurs, some platforms allow you to claim the hostname without serving content from it, which prevents a third party from claiming it. Consult the platform's documentation for domain management options.
Prevention
The root cause is that DNS records outlive the services they were created for. Organizational practices that reduce this risk:
- Maintain an inventory of all DNS records and the services they map to. This does not need to be a complex system: a spreadsheet with domain, record type, target, and associated service or team is sufficient to make cleanup practical.
- Include DNS record cleanup in deprovisioning checklists. When a Heroku app, GitHub Pages site, or other hosted service is decommissioned, removing the associated DNS record should be an explicit step in the process.
- Run periodic DNS audits. A quarterly audit of all CNAME and A records can surface dangling records before an attacker finds them.
- Use a dedicated monitoring tool or run WebDefect scans regularly to detect new dangling records between audits.