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

Forem: Mika

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

What does this mean?

How the tool found it

This happens more than you think

What I did with the finding

TL;DR

Subdomain takeovers are still embarrassingly common...

What is a subdomain takeover?

Why does this keep happening?

How do you detect it?

Checking your own subdomains

TL;DR