September 26, 2026
I Took Over the Infrastructure. The CDN Still Said No.
A clean subdomain takeover, a live PoC with full administrative control โ and a CDN error that meant none of it mattered.
By 0x_specter
2 min read
I Took Over the Infrastructure. The CDN Still Said No.
Subdomain takeovers usually come down to one question: can I claim the thing the DNS record points to? I could. I registered the exact third-party platform identifier a target company's own DNS had been pointing to for years, stood up a live instance, hosted a proof-of-concept page on it, and had a screenshot to prove it. And the finding still closed as Not Applicable โ for a reason worth understanding properly, because it's not the reason most takeover writeups warn you about.
The finding
A subdomain on a large enterprise's domain had a CNAME pointing to a tenant on a third-party SaaS platform (a partner-portal provider). Archive data confirmed it was once a live partner portal for the company. The original tenant had since been deprovisioned, but the DNS record was never cleaned up โ the identifier was sitting there, unclaimed, free for anyone to register on the platform.
I registered it. Full administrative access โ branding tools, homepage templates, the works. I customized the instance and hosted a PoC page on it, exactly as the triager requested.
Where it broke down
The actual subdomain still returned a CDN-level DNS resolution error the entire time. A CDN sat in front of the domain, and it wouldn't complete the handshake to a newly claimed backend tenant without a DNS verification record on the company's own zone โ which I don't control, so that record doesn't exist, so the CDN never bridges the connection.
Here's the part that's easy to conflate, and I did at first: the CNAME pointing to that identifier proves the company's DNS used to depend on it. It doesn't mean the identifier is still part of the company's trust boundary once the original tenant is gone. The moment the platform frees it up, it's just an available slot โ like an unclaimed username โ fully decoupled from anything the company controls. Claiming it makes you the owner of a generic tenant that happens to share a name with something the company once used. It doesn't put you inside their infrastructure.
What would put you there is real traffic โ an actual visitor to the real subdomain landing on content you control. That step never happens. The CDN blocks it categorically, independent of anything happening on the platform side.
The lesson
Full administrative control over a claimed endpoint isn't the same as the claim being reachable. When a CDN, WAF, or reverse proxy sits in front of the vulnerable subdomain, it can act as its own independent security boundary โ one that doesn't care whether you've claimed the backend, only whether you can prove control of the DNS zone in front of it. You can win the backend and still lose the actual attack path, because the CDN was never part of the thing you took over in the first place.
Takeaway for hunters
Before reporting a takeover, check what sits in front of the vulnerable subdomain. If it's proxied through a CDN, ask whether that CDN independently gates traffic on DNS-level verification you don't control โ because if it does, "I claimed the backend" and "I control what real users see" are two different claims, and only the second one is the vulnerability that matters.
Don't forget to follow and subscribe to get more posts about bug bounty.