The Vulnerability in One Sentence

If your DNS has a CNAME or A record pointing to a third-party service that no longer hosts your content, an attacker can register that service under your name and serve their content from your domain.

That is subdomain takeover. It is real, it is widespread, and it has been used in serious security incidents β€” phishing campaigns under trusted brands, cookie theft, OAuth bypass, and more.

The Concrete Example

Imagine you do this last year:

  1. You set up a marketing site on Heroku at marketing-yourcompany.herokuapp.com.
  2. You add a CNAME: marketing.yourcompany.com β†’ marketing-yourcompany.herokuapp.com.
  3. The marketing campaign ends. You delete the Heroku app.
  4. You forget to remove the CNAME from your DNS.

Now anyone can sign up for Heroku, claim the app name marketing-yourcompany, and Heroku will serve their content for that hostname. Your CNAME still points there. Suddenly marketing.yourcompany.com displays a phishing page β€” under the green padlock, on your trusted domain.

Why This Happens So Often

Two reasons:

  • Cloud platforms allow first-come-first-served claiming. Heroku, GitHub Pages, AWS S3, Azure, Bitbucket, Tumblr, and dozens of others let you register a hostname (or a project name) that maps to a stable subdomain. There is no verification that you actually own the parent domain pointing at it.
  • DNS records outlive the resources they point to. Engineers spin up cloud resources, point DNS at them, then deprovision the resources without cleaning up DNS. The CNAME stays as a relic.

Studies of large enterprise DNS zones routinely find dozens to hundreds of dangling CNAMEs per organization. Many of those are takeover-vulnerable.

Affected Service Patterns

Any service where:

  • You can register a custom subdomain under their domain (yourname.service.com).
  • The platform serves traffic for that subdomain to the registrant.
  • The subdomain becomes available again after the registrant releases or deletes it.

Common targets historically include:

  • Heroku (*.herokuapp.com)
  • GitHub Pages (*.github.io)
  • AWS S3 (*.s3.amazonaws.com)
  • AWS CloudFront (*.cloudfront.net)
  • Azure (*.azurewebsites.net, *.cloudapp.net)
  • Tumblr (*.tumblr.com)
  • Bitbucket (*.bitbucket.io)
  • Fastly, Squarespace, Helpjuice, Pantheon, etc.

The list is not static. Any platform with this architecture is a potential vector. Bug bounty platforms maintain ongoing lists of currently-vulnerable services.

What an Attacker Actually Gains

This is not "embarrassing." The blast radius is real:

  • Phishing under your brand. A login page on your domain, with valid HTTPS, that POSTs credentials to the attacker.
  • Cookie theft. If your main domain sets cookies for *.yourcompany.com, the attacker on the takeover subdomain can read them.
  • OAuth and authentication bypass. Many OAuth flows trust subdomains of an allowed origin. An attacker on a takeover subdomain may be able to complete OAuth flows in your users' browsers.
  • SEO and brand damage. Search engines index the attacker's content under your domain.
  • SPF/DKIM bypass. If your email infrastructure trusts subdomain identity, the attacker may send "from" your domain in ways that pass authentication.

How to Find Vulnerabilities in Your Own DNS

  1. Export your DNS zone. Most providers offer a zone-file export.
  2. List all CNAME and ALIAS records. These are the takeover candidates.
  3. For each CNAME target, check whether the resource exists. Visit it. If the platform shows a "no such app" / "page not found" / "bucket does not exist" page instead of your content, you have a candidate.
  4. Verify the platform allows re-registration of the target. Some platforms now reserve previously-used names; many do not.

Tools like subjack, SubOver, and can-i-take-over-xyz automate this scan against the most common services. They are open-source and run from a list of your subdomains. For small DNS zones, a 5-minute manual review catches most issues.

How to Fix It

For each vulnerable record:

  • Delete the CNAME or A record if you no longer use the resource. This is the canonical fix.
  • Re-claim the resource if the platform allows re-registration. Some teams "park" the resource on a known-safe placeholder rather than delete the DNS record.
  • Repoint the record to a current, controlled resource if you actually want that subdomain live.

The general principle: never let DNS records outlive the resources they point to. When you decommission a cloud resource, decommission the DNS record at the same time.

How to Prevent It Long-Term

  • DNS hygiene as part of decommissioning. When you delete a Heroku app, S3 bucket, or any third-party hosted resource, also delete the corresponding DNS record. Make this a checklist item.
  • Tag DNS records with their owner / purpose. Most DNS providers support metadata or comments on records. Knowing who created a record makes cleanup easier.
  • Periodic DNS audits. Quarterly review of all DNS records, focusing on CNAMEs pointing to third-party platforms. For larger orgs, automated scanning.
  • Apex-only public services. For maximum reduction of attack surface, avoid pointing subdomains at third parties unless actively needed. Use paths under your apex (yourcompany.com/blog) instead of subdomains where possible.
  • Strict cookie scoping. Set cookies on the specific subdomain that needs them, not on .yourcompany.com (which exposes them to all subdomains).
  • OAuth allow-lists with explicit subdomains. Avoid wildcard patterns in OAuth redirect URIs β€” list each authorized subdomain.

The Bug Bounty Reality

Subdomain takeover is one of the most-rewarded categories on bug bounty platforms. Major companies pay $500–$5,000 per confirmed takeover vector. If your organization runs a bug bounty, expect researchers to scan your DNS regularly and submit findings.

This is good news: you have professionals identifying issues before attackers. The right response is to fix promptly, not to argue scope. The bounty cost is dramatically less than a real incident.

The Quick Action List

  1. List every CNAME and ALIAS in your DNS zones.
  2. For each, verify the target resource still exists and is yours.
  3. Delete or repoint any that are not.
  4. Add DNS cleanup to your standard decommissioning checklist.
  5. Schedule a quarterly review.

The vulnerability is often described as "low-hanging fruit" because it is genuinely easy to find and fix. The cost of not doing this audit is the chance that someone else does β€” and reports it less responsibly than a bounty researcher would.