DEV Community: Mika

Top 10 Services Most Vulnerable to Subdomain Takeover (And How to Detect Them)

Mika — Tue, 28 Apr 2026 11:51:54 +0000

Subdomain takeovers are one of the most underrated vulnerabilities in web security. They're easy to miss, surprisingly common, and can have serious consequences — phishing pages served under your own domain, session cookie theft, or brand damage.

The attack always follows the same pattern: a subdomain points to an external service via a CNAME record, the service gets deprovisioned, but nobody removes the DNS record. The subdomain is now dangling — and claimable by anyone.

Here are the 10 services where this happens most often, along with the fingerprint that gives it away.

1. GitHub Pages

Fingerprint: There isn't a GitHub Pages site here

GitHub Pages is one of the most common culprits. Developers frequently set up docs.example.com or blog.example.com pointing to a GitHub Pages site, then delete the repository or disable Pages without removing the CNAME record.

Anyone can create a GitHub Pages site at the dangling address and immediately serve content under your subdomain.

Example CNAME chain:

docs.example.com → username.github.io → ❌ unclaimed

2. Heroku

Fingerprint: No such app

Heroku is a classic. Staging environments, side projects, and old prototypes frequently get deleted while their DNS records live on. The "No such app" page is one of the most recognizable takeover signals in bug bounty hunting.

Example CNAME chain:

staging.example.com → old-app.herokuapp.com → ❌ unclaimed

3. AWS S3

Fingerprint: NoSuchBucket

S3 buckets configured for static website hosting are highly susceptible. When a bucket is deleted, the subdomain pointing to it becomes claimable by anyone who creates a new bucket with the same name in the same region.

This one is particularly dangerous because S3 buckets can serve arbitrary files — including HTML pages and scripts.

Example CNAME chain:

assets.example.com → example-assets.s3-website-us-east-1.amazonaws.com → ❌ bucket deleted

4. Vercel

Fingerprint: The deployment could not be found

Vercel deployments are spun up and torn down constantly. When a project gets deleted or a custom domain gets removed from a Vercel project without cleaning up DNS, the subdomain dangles.

Example CNAME chain:

app.example.com → cname.vercel-dns.com → ❌ project deleted

5. Netlify

Fingerprint: Not Found - Request ID

Same story as Vercel. Netlify sites get deleted all the time — marketing landing pages, campaign microsites, A/B test variants. The DNS record outlives the site.

Example CNAME chain:

landing.example.com → example.netlify.app → ❌ site deleted

6. Azure

Fingerprint: 404 Web Site not found

Azure has multiple vulnerable services — App Service, Front Door, CDN, Traffic Manager. Enterprise companies running on Azure often have dozens of subdomains pointing to Azure resources, and decommissioning processes don't always include DNS cleanup.

Example CNAME chain:

portal.example.com → example.azurewebsites.net → ❌ app deleted

7. Shopify

Fingerprint: Sorry, this shop is currently unavailable

E-commerce businesses frequently set up custom subdomains for their Shopify stores — shop.example.com or store.example.com. When they migrate platforms or shut down the store, the CNAME often stays.

Example CNAME chain:

shop.example.com → example.myshopify.com → ❌ shop closed

8. Zendesk

Fingerprint: Help Center Closed

Support portals are a goldmine for subdomain takeovers. Companies set up help.example.com or support.example.com pointing to Zendesk, then migrate to a different support platform without cleaning up DNS.

A takeover here is particularly dangerous — users trusting a support subdomain might enter credentials or sensitive information.

Example CNAME chain:

help.example.com → example.zendesk.com → ❌ account closed

9. Ghost / Ghost.io

Fingerprint: Domain not configured

Ghost is a popular blogging platform. blog.example.com pointing to a Ghost instance is extremely common, and when companies rebrand or migrate their blog, the DNS record is often forgotten.

Example CNAME chain:

blog.example.com → example.ghost.io → ❌ site not configured

10. Fastly

Fingerprint: Fastly error: unknown domain

CDN takeovers are less common but high impact. Fastly serves content for massive amounts of web traffic, and a dangling CNAME to a Fastly endpoint means an attacker could potentially intercept or serve content to users expecting your site.

Example CNAME chain:

cdn.example.com → example.global.ssl.fastly.net → ❌ service not configured

How to detect these vulnerabilities

Detection comes down to two things:

1. Check for NXDOMAIN
Follow the full CNAME chain. If the final destination returns NXDOMAIN — the domain doesn't exist in DNS — you have a dangling CNAME regardless of the service.

2. Check for service fingerprints
If the target resolves but returns one of the error messages above, the service exists but isn't configured for that domain. That's your takeover signal.

You can check any subdomain automatically using SubdomainChecker — it follows CNAME chains, checks fingerprints against 80+ services, and even enumerates subdomands from certificate transparency logs so you don't have to find them manually.

There's also a free API if you want to integrate takeover detection into your own recon pipeline: RapidAPI

How to protect yourself

Keep a DNS inventory — know what every subdomain points to
Remove DNS records before decommissioning services — DNS cleanup should be step one, not an afterthought
Audit regularly — run a takeover check every few months, especially after infrastructure changes
Automate it — use the API to run checks automatically as part of your CI/CD pipeline or security monitoring

Subdomain takeovers are preventable. The vulnerability only exists because of forgotten DNS records — and a 30-second check is all it takes to find them.

I Ran a Subdomain Takeover Checker on GitHub.com and Found a Vulnerable Subdomain

Mika — Wed, 22 Apr 2026 19:23:42 +0000

I've been building a tool that checks subdomains for takeover vulnerabilities. Yesterday I decided to test it on a well-known target — github.com — just to see what it would find.

I wasn't expecting much. GitHub is a massive, well-maintained platform with a serious security team. But within seconds of running the enumeration, one result came back red:

brandguide.github.com — VULNERABLE
Service: github.io
Reason: Unconfigured fingerprint found for github.io

What does this mean?

brandguide.github.com has a CNAME record pointing to a GitHub Pages address that is no longer configured. The page returns GitHub's classic "There isn't a GitHub Pages site here" message — which is the exact fingerprint that indicates an unclaimed Pages site.

In theory, anyone could create a GitHub Pages site at that address and serve content under brandguide.github.com — a subdomain that looks like it belongs to GitHub.

This is a textbook subdomain takeover.

How the tool found it

The tool uses two steps to detect takeovers:

Step 1 — Enumerate subdomains via certificate transparency logs
Certificate authorities are required to publicly log every SSL certificate they issue. By querying crt.sh, you can discover subdomains that have had certificates issued — no scanning, no probing, just reading public records.

For github.com this returned dozens of subdomains instantly.

Step 2 — Check each subdomain for takeover vulnerabilities
For each subdomain, the tool follows the full CNAME chain. If the final destination returns NXDOMAIN (the domain doesn't exist) or matches a known "unconfigured" fingerprint from services like GitHub Pages, Heroku, Vercel, AWS S3, and 80+ others — it flags the subdomain as vulnerable.

brandguide.github.com passed through the CNAME chain check and matched the GitHub Pages fingerprint. Result: vulnerable.

This happens more than you think

GitHub is not unique here. Subdomains get created for marketing campaigns, staging environments, documentation sites, and internal tools — then the service gets decommissioned, but nobody cleans up the DNS record.

It's not a sign of negligence. It's just the natural entropy of running infrastructure at scale. The DNS record outlives the service by months or years, quietly waiting for someone to notice.

What I did with the finding

Nothing — I don't own github.com and have no intention of claiming the subdomain. This article is purely educational. If you work at GitHub and are reading this, consider this a friendly heads up.

If you want to check your own domains, the tool is free to use:

🔗 subdomainchecker.com — paste in a root domain, it enumerates subdomains via crt.sh and checks each one automatically

There's also a public API if you want to integrate it into your own recon pipeline:

🔗 RapidAPI — Subdomain Takeover Checker — free tier available

TL;DR

Subdomain takeovers are real and happen even at large companies
Certificate transparency logs are a goldmine for passive subdomain enumeration
Automated fingerprint checking makes it trivial to scan dozens of subdomains in seconds
Always clean up your DNS records when you decommission a service

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

Subdomain takeovers happen when a CNAME points to an unclaimed external service
They're common because DNS records are rarely cleaned up when services are decommissioned
Detection involves checking for NXDOMAIN and known service fingerprints
Audit your subdomains regularly — especially after decommissioning any third-party service