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

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