Verifying Subdomain Takeover Reports: Proof, Providers, and False Positives

Subdomain takeover is the bug class most likely to arrive as a claim rather than a proof. "The subdomain promo.example.com points to an unclaimed S3 bucket. Takeover possible." Maybe. Or maybe it's a wildcard DNS record, a parked domain, or a provider that shows a 404 but won't actually let anyone else claim the name. Takeover is real and sometimes serious, but the reporting quality is all over the map, and the verification is specific enough that guessing gets expensive.

The good news: unlike most bug classes, takeover verification has a clean pass/fail. Either you can serve content on the subdomain or you can't. The trick is insisting on that proof instead of accepting the theory.

The dangling-record pattern

Takeover happens when DNS points a name at a resource that no longer exists and that someone else can now create. The two patterns:

• Dangling CNAME: blog.example.com is a CNAME to example.github.io, but the GitHub Pages site was deleted. The DNS record still resolves toward GitHub; the target is unclaimed; anyone who creates a Pages site with that name now controls blog.example.com.
• Dangling NS: a subdomain's NS records delegate to a nameserver / hosted zone that was deleted at the DNS provider. Whoever re-registers the zone controls the entire subdomain tree. Rarer, higher impact.

The signal is a resolvable DNS record pointing at a third-party service that returns a "no such site here" state: a specific provider error page, not a generic timeout.

$ dig +short blog.example.com
example.github.io.

$ curl -sI https://blog.example.com
HTTP/2 404
server: GitHub.com
# body: "There isn't a GitHub Pages site here."

That combination (CNAME to a service target, plus that service's specific unclaimed-resource response) is what a takeover looks like. A generic 404 from the app's own server is not it.

Not every provider is claimable

This is the crux, and where most false positives live. A dangling CNAME to a provider only matters if that provider lets you register the dangling name. Many don't: they've fixed the class by verifying domain ownership, refusing to serve custom domains you can't prove you control, or reclaiming released names into a quarantine.

The community reference here is the can-i-take-over-xyz project, which catalogues services by whether takeover is currently possible, not possible, or edge-case. Before you validate a report, check the specific provider's current status. GitHub Pages, for instance, is famously takeover-prone precisely because the mechanics are simple: create a repo, add a CNAME file with the target hostname, enable Pages, and if no other repo has claimed that hostname you're serving on it. Other providers have added verification steps that close the window, and a "404 from provider X" against one of those is not a takeover no matter how confident the report sounds.

So the provider check is two questions:

1. Is this provider currently claimable (per can-i-take-over-xyz and your own knowledge of recent provider changes)?
2. Does the specific fingerprint match the claimable state, not just any 404?

A report that says "unclaimed, takeover possible" against a provider that verifies ownership is a false positive, and you should say so with the reason, not just close it.

Proof standards: a file, not a theory

The verdict-worthy proof for a takeover is content the reporter placed on the subdomain. Not a 404 screenshot. Not "the CNAME points to an unclaimed bucket." Actual attacker-controlled content served from the target hostname.

The responsible-disclosure standard is a harmless, uniquely-named marker:

$ curl -s https://blog.example.com/poc-a1b2c3.txt
subdomain-takeover-poc for report #4471 - contact: researcher@...

A named text file or a minimal HTML page with the report reference proves control without doing anything hostile. It's checkable (you can curl it yourself and confirm) and it's non-destructive, which is what you want a researcher to have done.

Where reports fall short:

• "404 = takeover": the most common over-claim. A 404 shows the target might be unclaimed. It doesn't show the reporter (or anyone) can actually claim it. Ask for the served-content PoC.
• Claiming it without proving it, for a service that needs verification: some providers require a TXT record to activate a custom domain, which the reporter can't set on your DNS. If they couldn't complete the claim, there's no takeover, and their report should say what step blocked them.
• A PoC on the wrong host: content served from the provider's default domain (attacker.github.io) is not the same as content served from blog.example.com. The proof has to resolve on your subdomain.

If the reporter genuinely took it over, they can serve the file. If they can't serve the file, they probably didn't take it over. That single standard resolves most of the queue.

Severity: which subdomain, and what does it inherit?

A confirmed takeover's severity depends almost entirely on what the parent domain trusts the subdomain to do. The takeover mechanic is the same; the blast radius is not.

• Cookie scope: if the app sets cookies on .example.com (domain-scoped to the parent), a controlled subdomain can read them on requests it induces, potentially capturing session material. Host-only cookies on the apex don't leak this way. Check the Domain attribute.
• CSP trust: if the main app's Content-Security-Policy lists *.example.com or the specific subdomain as a script-src, a takeover gives the attacker a trusted script origin, upgrading it toward XSS on the main app.
• CORS trust: if the API reflects or allowlists *.example.com origins with Access-Control-Allow-Credentials: true, a controlled subdomain can make authenticated cross-origin requests and read the responses.
• OAuth / SSO redirect allowlists: a subdomain trusted as a redirect target can become a token-theft vector.
• Email / SPF: an NS takeover or takeover of a mail-related subdomain can enable convincing phishing from the real domain.

A takeover of a subdomain that's isolated, sets no shared cookies, and appears in no allowlist is real but low: content spoofing and phishing, mostly. A takeover of a subdomain the main app trusts for scripts or cookies is a stepping stone into the primary application, and rated accordingly. This inheritance question is exactly the kind of impact reasoning our severity guide turns on: the mechanism is fixed, the trust relationships decide the number.

False positives to filter

Wildcard DNS is the sneakiest: a *.example.com record means every nonexistent subdomain resolves to the app, so a scanner reports hundreds of "subdomains," none of which are dangling. Confirm the specific record type and target before treating a resolvable name as a finding.

The verification flow

1. Resolve the record: confirm a real CNAME/NS pointing at a third-party service target, not a wildcard.
2. Fingerprint the response: match the provider's specific unclaimed-resource state, not a generic 404.
3. Check the provider is currently claimable (can-i-take-over-xyz + recent provider changes).
4. Require a served-content PoC on the actual subdomain, referencing the report.
5. Rate on what the parent trusts the subdomain for: cookies, CSP, CORS, OAuth, mail.
6. Note the fix: remove the dangling DNS record, or reclaim the resource.

Subdomain takeover is easy to claim and easy to over-rate, and the volume of "404 therefore takeover" reports is relentless. TRIAGERS™ runs on-demand triage teams who insist on served-content proof and rate on real trust inheritance, so parked domains and wildcard noise don't reach your payout queue. If takeover reports are clogging your intake, get in touch.