Your company has hundreds of subdomains. Marketing spun up a landing page on Heroku last year. The design team tested a prototype on Netlify. Engineering had a staging environment on AWS. Those services are gone — but the DNS records pointing to them are still there.
That's a subdomain takeover waiting to happen.
How Subdomain Takeover Works
Service is deprovisioned
Team shuts down a Heroku app, deletes an S3 bucket, or removes a GitHub Pages site — but forgets to remove the DNS CNAME record
DNS record still points to the service
blog.example.com still has a CNAME to example-blog.herokuapp.com — but that Heroku app no longer exists
Attacker claims the service name
Attacker creates a new Heroku app named example-blog.herokuapp.com (or the equivalent on any provider) — and the service accepts it because the name is available
Attacker controls the subdomain
blog.example.com now resolves to the attacker's content. They can serve phishing pages, steal cookies, or exploit the trust of your domain.
15%
of Audits Find Dangling DNS
70+
Vulnerable Services
$3K-25K
Bug Bounty Payout
Minutes
Time to Exploit
Why It Matters
A taken-over subdomain isn't just a defacement risk. The attacker controls content on your domain:
Subdomain Takeover Impact
Cookie theft
If your application sets cookies on .example.com (parent domain), the attacker's page on blog.example.com can read them — including session cookies. This enables session hijacking for your main application.
Credible phishing
A login page on staging.example.com looks completely legitimate. Users, employees, and even security tools trust content on your own domain. Phishing success rates on taken-over subdomains are dramatically higher.
OAuth/SSO token theft
If any OAuth redirect_uri includes the vulnerable subdomain (or a wildcard pattern), the attacker can steal authorization codes — as we detailed in our OAuth vulnerabilities analysis.
Email spoofing
Controlling a subdomain may allow SPF-authenticated email sending from your domain, bypassing email security controls.
🛑Same-Origin Trust
Browsers trust all subdomains under the same parent. Cookies scoped to .example.com are accessible to evil.example.com. CSP policies that allowlist *.example.com include attacker-controlled subdomains. This makes subdomain takeover far more impactful than it initially appears.
Vulnerable Services
Over 70 cloud services are vulnerable to subdomain takeover when their DNS records are left dangling:
| Service | Record Type | Fingerprint | |---|---|---| | Heroku | CNAME | "No such app" | | GitHub Pages | CNAME | "There isn't a GitHub Pages site here" | | AWS S3 | CNAME | "NoSuchBucket" | | Shopify | CNAME | "Sorry, this shop is currently unavailable" | | Netlify | CNAME | "Not Found - Request ID:" | | Azure | CNAME | Various error pages | | Fastly | CNAME | "Fastly error: unknown domain" |
How We Find Them
Subdomain takeover detection is one of the first things our reconnaissance phase covers. As we described in How RedVolt Combines AI with Human Expertise, our AI agents enumerate every subdomain and check each one for takeover vulnerability:
Enumerate
Discover all subdomains via DNS brute-forcing, certificate transparency logs, and public sources
Resolve
Check DNS resolution for each subdomain — identify CNAMEs, A records, and their targets
Fingerprint
Match DNS targets against known vulnerable service fingerprints
Verify
Confirm the service name is available for registration (without actually claiming it)
Prevention
What Leads to Takeovers
- •No DNS record inventory or ownership tracking
- •Deprovisioning services without removing DNS
- •Wildcard DNS records (*.example.com)
- •No regular monitoring for dangling records
How to Prevent Them
- •Maintain a DNS record inventory with service ownership
- •Decommissioning checklist that includes DNS cleanup
- •Avoid wildcard DNS — use explicit records only
- •Regular automated scanning for dangling CNAMEs
💡Cookie Scoping
Even if you can't prevent every dangling record, you can limit the impact: scope your cookies to the specific subdomain that needs them (app.example.com) instead of the parent domain (.example.com). Set the __Host- prefix on cookies to prevent subdomain access entirely.
As we covered in Security Headers: The Complete Implementation Guide, proper cookie attributes and Content Security Policy help mitigate the impact of subdomain compromises.
The Bigger Picture: Attack Surface Management
Subdomain takeover is a symptom of a larger problem — unmanaged attack surface. As we explained in Securing Your CI/CD Pipeline, modern infrastructure is constantly being provisioned and deprovisioned. Without inventory management, forgotten assets become liabilities.
Our Web Security Auditor includes comprehensive subdomain enumeration and takeover detection as part of every assessment. We find the dangling DNS records before attackers do. Start a scan or request a full security review.