The subdomain you forgot, that someone else can claim
Point a subdomain at a cloud resource — an S3 bucket, a GitHub Pages site, a Heroku app — then delete the resource but leave the DNS record behind, and you’ve created a dangling pointer to nothing. Anyone can re-register that exact resource and instantly serve their own content on your subdomain: phishing pages with your name on them, cookie theft, OAuth abuse. We detect these passively — DNS lookups plus one read-only request, or two if the host answers HTTPS with an empty body and we retry over HTTP. Confirming a delegation adds DNS only, up to ten queries per candidate. In 2025 researchers re-registered ~150 abandoned S3 buckets that once belonged to governments and Fortune 500s.
What the radar has done so far
A subdomain is counted takeover-able only when its CNAME delegates to a known service AND that service returns its “unclaimed” fingerprint (e.g. S3’s NoSuchBucket) — the same high-precision signal subjack and nuclei use. Confirmed cases are rare and serious; most delegations are live and claimed.
Why this matters
A taken-over subdomain isn’t “just a subdomain” — it inherits your domain’s trust:
- • Phishing that looks 100% legitimate — the page really is on your domain, so links, filters, and users all trust it.
- • Cookie & session theft — cookies scoped to
*.yourdomain.comcan be read from the hijacked subdomain. - • OAuth / SSO bypass & brand damage — redirect-URI allow-lists and email/SPF trust can be abused from a subdomain you no longer control.
The fix is free: delete the dangling DNS record, or re-claim the resource you still need.
By service
- GitHub Pages76 takeover-able of 2,062 delegated
- Fastly14 takeover-able of 189 delegated
- Strikingly3 takeover-able of 62 delegated
- Heroku2 takeover-able of 1,349 delegated
- Shopify0 takeover-able of 8,313 delegated
- Webflow0 takeover-able of 371 delegated
- Big Cartel0 takeover-able of 124 delegated
- Tumblr0 takeover-able of 93 delegated
- Ghost0 takeover-able of 40 delegated
- Help Scout0 takeover-able of 27 delegated
- Pantheon0 takeover-able of 22 delegated
- Campaign Monitor0 takeover-able of 8 delegated
- Wordpress0 takeover-able of 7 delegated
- Hatena0 takeover-able of 7 delegated
- Read the Docs0 takeover-able of 6 delegated
Are you exposed?
Check whether any of your subdomains point at a resource you no longer control — a free read-only scan of your internet-facing surface, no signup.
Check your exposure →How it works
How do you detect a takeover without claiming anything?
We resolve the subdomain’s CNAME; if it delegates to a known service, we make one read-only GET (HTTPS, then HTTP if that returned nothing) and look for that service’s “unclaimed” response (e.g. “There isn’t a GitHub Pages site here”, “No such app”, “NoSuchBucket”). We never register or claim the dangling resource — that would be the attack.
Why is the takeover count usually low?
Because we hold it to a high bar — both the CNAME delegation and the unclaimed fingerprint must match. Most subdomains delegate to live, claimed resources. A confirmed takeover is rare, which is exactly why it’s worth surfacing.
Why don't you list the affected subdomains?
Publishing them would be a ready-made shopping list for attackers. We keep host names private for responsible disclosure to the owners and publish only aggregate counts. Use the scanner above to check your own subdomains.
Frequently asked questions
What is a subdomain takeover?
When a subdomain's DNS record (usually a CNAME) still points at a cloud resource that has been deleted — an S3 bucket, GitHub Pages site, Heroku or Azure app — an attacker can re-create that resource and serve their own content from your subdomain.
Why is a dangling DNS record dangerous?
The attacker controls a real subdomain on your domain, which enables convincing phishing, cookie and session theft, OAuth-redirect abuse, and bypass of domain-based trust. It is hard for users to spot because the subdomain genuinely belongs to you.
How does EchelonGraph detect subdomain takeovers?
It resolves subdomains and flags CNAMEs pointing at unclaimed or deprovisioned third-party targets, then makes one read-only GET to the host root — two if the first returns nothing over HTTPS and we retry over HTTP. Confirming a wildcard delegation or a GitHub Pages claim adds DNS lookups only, up to ten per candidate including a probe label of our own. Every request is identified as EchelonGraph and carries a signed receipt you can verify at /verify-scan. It is detect-only: it never registers or claims the resource, which is the actual takeover. Results are aggregate and host-redacted.
How do I fix a dangling subdomain?
Remove or update the DNS record the moment you decommission the resource it points to, audit your DNS for CNAMEs aimed at services you no longer own, and reclaim the target resource if it is still available before an attacker does.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; [email protected]) and a From: [email protected] header. It is a single, minimal check — we never log in, exploit, or read your data. Confirming an MCP endpoint or an exposed datastore needs a protocol-level exchange rather than a plain GET; on Redis our client names itself so the connection is identifiable in your own CLIENT LIST. Who we are, exactly what each check sends, and how to opt out → Genuine requests also carry a signed receipt you can validate at /verify-scan.