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.

High severity Infrastructure Security Updated 2026-03-01

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. 1

    Audit all DNS records for dangling references

    List all subdomains and check if their targets still exist:

    {{ trim($paragraph)); ?>

    For 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. 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. 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. 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.com

Check 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.

Related Security Terms

Detect This Automatically with StackShield

StackShield continuously monitors your Laravel application from the outside and alerts you when security issues are found. No installation required.

Start Free Trial