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