Subdomain takeovers are still embarrassingly common...

Mika — Sun, 19 Apr 2026 13:04:44 +0000

You've probably heard of domain hijacking — but subdomain takeovers are sneakier, more common, and surprisingly easy to miss.

What is a subdomain takeover?

When a company sets up a service like a blog, a shop, or a staging environment, they often point a subdomain at an external platform using a DNS record called a CNAME.

For example:

shop.example.com → CNAME → example.myshopify.com

This tells the internet: "when someone visits shop.example.com, send them to our Shopify store."

Now imagine the company shuts down that Shopify store — but forgets to delete the DNS record. The CNAME is still there, pointing at a Shopify address that no longer exists.

An attacker can register that Shopify store and suddenly controls shop.example.com. They can serve phishing pages, steal cookies, or damage the brand — all from what looks like a legitimate company subdomain.

Why does this keep happening?

Because DNS cleanup is boring and easy to forget. Teams spin up new services all the time — staging environments, marketing landing pages, support portals — and when those services get decommissioned, the DNS records are often left behind.

It's not a sophisticated attack. It just requires patience and a good eye for dangling CNAMEs.

How do you detect it?

Detection comes down to two steps:

Step 1 — Follow the CNAME chain
Resolve the subdomain and follow every CNAME until you reach the final destination. If the final target returns NXDOMAIN (the domain doesn't exist in DNS), that's a strong signal of a dangling CNAME.

Step 2 — Check for service fingerprints
If the target resolves but the service isn't configured, most platforms return a recognizable error page. For example, an unclaimed GitHub Pages site returns "There isn't a GitHub Pages site here". Checking for these fingerprints confirms whether a takeover is possible.

One important caveat: wildcard DNS can cause false positives. If a parent domain resolves any random subdomain (like random123.example.com), you need to account for that before flagging something as vulnerable.

Checking your own subdomains

If you're a developer or sysadmin, it's worth periodically auditing your DNS records — especially for subdomains pointing at third-party services you may have stopped using.

I built a free API that automates this entire process. It follows CNAME chains, checks fingerprints against 80+ services (AWS S3, Azure, Heroku, Vercel, Netlify, GitHub Pages, Shopify, Zendesk and more), handles wildcard detection, and returns a confidence level with each result.

There's also a bulk endpoint that checks up to 25 subdomains at once — useful if you have a large number of subdomains to audit.

You can try it here: Subdomain Takeover Checker API — free tier available, no credit card needed.

Or check out the website: subdomainchecker.com

TL;DR