How to Fix Subdomain Takeover Vulnerabilities
Dangling DNS records pointing to decommissioned services allow attackers to take over your subdomains. Learn how to find and fix them.
Modern web development creates a significant number of subdomains throughout a project's lifecycle: staging., dev., api., blog., docs., status., and dozens of service-specific entries. Each subdomain is typically a CNAME record pointing to an external service — a Heroku app, GitHub Pages site, Netlify deployment, or AWS CloudFront distribution. When the service is decommissioned but the DNS record remains, a dangling CNAME is created that anyone can exploit.
The exploitation mechanism is service-dependent but broadly similar: an attacker claims the abandoned external service endpoint. For Heroku, they create a new app with the same name. For GitHub Pages, they create a repository with a matching CNAME file. For AWS S3, they create a bucket matching the subdomain. Once claimed, any content they deploy is served under your subdomain — which browsers and users trust as part of your organization. Your security headers, SSL certificate, and domain reputation all apply to the attacker-controlled content.
Subdomain takeover enables cookie theft (subdomains can set cookies for the parent domain, potentially hijacking sessions), phishing (users see your legitimate domain name in the URL), OAuth callback hijacking (if the subdomain is a registered redirect URI), and significant reputation damage. Automated tools like subjack, nuclei, and subzy specifically test takeover-vulnerable patterns against all discovered subdomains continuously. Security researchers have demonstrated successful takeovers on subdomains of Microsoft, Shopify, and Uber. A quarterly DNS audit is the primary defense.
The Problem
Subdomain takeover occurs when a DNS record (typically a CNAME) points to an external service that has been decommissioned, but the DNS record remains. An attacker can claim the abandoned service endpoint and serve their own content on your subdomain, which browsers and users trust as part of your domain. This enables phishing, cookie theft, and reputation damage.
How to Fix
-
1
Audit all DNS records for dangling references
List all subdomains and check if their targets still exist:
dig +short CNAME staging.yourdomain.com dig +short CNAME blog.yourdomain.com dig +short CNAME docs.yourdomain.comFor each CNAME, verify the target is still active. Common vulnerable services:
- Heroku: NXDOMAIN response means vulnerable - GitHub Pages: 404 on the CNAME target - AWS S3: NoSuchBucket error - Azure: NXDOMAIN for *.azurewebsites.net - Shopify: "Sorry, this shop is currently unavailable"
Check with: curl -I https://staging.yourdomain.com
-
2
Remove dangling DNS records
For any CNAME pointing to a decommissioned service, remove the DNS record immediately from your DNS provider. In your DNS management panel:
1. Go to DNS records for yourdomain.com 2. Find the CNAME record for the decommissioned subdomain 3. Delete it 4. Verify removal: dig +short CNAME staging.yourdomain.com (should return empty)
DNS changes propagate within minutes to hours depending on TTL settings.
-
3
Reclaim abandoned service endpoints
If you cannot remove the DNS record immediately (e.g., it is managed by another team), reclaim the service:
- Heroku: Create a new app and add the custom domain - GitHub Pages: Create a repository with a CNAME file containing the subdomain - AWS S3: Create a bucket matching the subdomain name
This is a temporary measure. The DNS record should still be removed if the service is no longer needed.
-
4
Implement a DNS record inventory process
Maintain a documented inventory of all DNS records and their purpose:
| Subdomain | Type | Target | Purpose | Owner | |-----------|------|--------|---------|-------| | app | A | 1.2.3.4 | Production | DevOps | | staging | CNAME | staging-abc.herokuapp.com | Staging | Dev | | blog | CNAME | yoursite.ghost.io | Blog | Marketing |
Review this inventory quarterly. When decommissioning any service, the DNS cleanup must be part of the decommission checklist.
How to Verify
For each subdomain, verify it returns content you control:
curl -I https://staging.yourdomain.com
curl -I https://blog.yourdomain.comCheck for signs of takeover: generic hosting provider pages, 404s from services you do not use, or content you did not create. Use dig to confirm DNS records only point to active services.Prevention
Include DNS record cleanup in your service decommission process. Perform quarterly DNS audits. Use StackShield to continuously monitor all your subdomains for takeover vulnerabilities and get alerted when a DNS record becomes dangling.
Frequently Asked Questions
How serious is a subdomain takeover?
Very serious. An attacker controlling your subdomain can serve phishing pages that appear to be part of your site, set cookies for your parent domain (potentially hijacking sessions), host malware under your domain reputation, and intercept email if MX records are involved. Users and browsers trust the subdomain as part of your organization.
Can A records be vulnerable to takeover?
Yes, but it is less common. If an A record points to a cloud IP address you have released (e.g., an Elastic IP in AWS), someone else can claim that IP. CNAME records are more commonly exploited because cloud services use predictable hostname patterns.
How do attackers find vulnerable subdomains?
Attackers use subdomain enumeration tools (subfinder, amass, dnsrecon) to discover all subdomains, then check each one for dangling DNS records. Certificate Transparency logs also reveal subdomains. This scanning is fully automated and happens continuously across the internet.
How long does it take for a removed DNS record to stop being exploitable?
Once the DNS record is deleted, propagation depends on the record's TTL (Time To Live). Records with low TTLs (300 seconds) become safe within minutes. Records with high TTLs (86400 seconds / 24 hours) can remain cached in resolvers for up to a day. Check your DNS TTL with: dig +short CNAME subdomain.yourdomain.com and look for the TTL value in the response.
Does Cloudflare proxying prevent subdomain takeover?
Cloudflare proxying (orange cloud) does protect proxied records because Cloudflare intercepts requests before they reach the underlying CNAME target. However, DNS-only (grey cloud) records are still vulnerable. Additionally, if an attacker claims the underlying service endpoint, they may still be able to get a valid SSL certificate for the subdomain through other means. Remove dangling records rather than relying on proxy protection.
Related Security Terms
Related Guides
How to Fix DNS Security Issues and Misconfigurations
DNS misconfigurations like open zone transfers and missing DNSSEC expose your domain to hijacking and spoofing attacks. Fix them now.
How to Fix Missing Email Security Records (SPF/DKIM/DMARC)
Missing SPF, DKIM, and DMARC records allow attackers to send spoofed emails from your domain. Configure email authentication now.
How to Fix Weak SSL/TLS Configuration in Laravel
Your SSL/TLS certificate is expired, misconfigured, or using weak protocols. Learn how to fix SSL issues for your Laravel app.
Is your Laravel app exposed right now?
34% of Laravel apps we scan have at least one critical issue. Most teams don't find out until something breaks. Our free scan checks your live application in under 60 seconds.