A dangling CNAME is one of those quiet bugs that goes unnoticed for years until somebody actually looks. This is the story of a high-severity subdomain takeover I disclosed through a private bug bounty program, the kind of issue that hands an attacker a fully trusted subdomain to serve arbitrary content from. Per the program's disclosure terms, the target identifiers are redacted throughout.

Severity: High (P2). CVSS classification withheld per program disclosure terms.
Target: [REDACTED subdomain] belonging to [REDACTED program].
Outcome: Accepted, rewarded, and fixed within days of triage.

Three-panel diagram showing the subdomain takeover lifecycle: legitimate setup with a CNAME pointing at an active Yumpu publication; orphaned state where the publication was deleted but the CNAME remains; attacker reclaim where the attacker registers the same hostname on Yumpu and serves malicious content under the customer's TLS.
Fig. 1: Legitimate → orphaned → attacker reclaim. The CNAME never moved.

What is a subdomain takeover?

A subdomain takeover happens when a DNS record (typically a CNAME) still points at a third-party service that the owner no longer controls. The third-party (Heroku, GitHub Pages, Shopify, Tumblr, S3 buckets, document hosts like Yumpu) usually lets anyone claim an unused custom hostname. An attacker who registers the same hostname inherits the trust of the original domain: cookies scoped to the parent domain, SSO sessions, CSP allowlists, password-manager auto-fill, and user habit.

This is what makes the bug class so dangerous. The vulnerability isn't a clever payload. It's a paperwork failure where the DNS team forgot to remove a record after sunsetting an integration.

How the Yumpu integration works

Yumpu is a document publishing service used to host PDF magazines, brochures, and reports as embedded web viewers. Customers can map a custom domain (e.g. publications.example.com) to their Yumpu account by adding a CNAME in their DNS pointing at Yumpu's infrastructure, then registering that hostname inside Yumpu's dashboard.

The vulnerability appears when the publication is deleted, the account is closed, or the custom-domain claim is released on Yumpu's side, but the CNAME on the customer's DNS is left in place. Yumpu now treats the hostname as available. Anyone with a Yumpu account can claim it, upload a document, and have it served from the original subdomain.

Recon: finding the dangling CNAME

I was working through subdomains on a private program. Standard pipeline:

subdomain pipeline # 1. Enumerate subfinder -d [REDACTED-target.tld] -all -silent > subs.txt amass enum -passive -d [REDACTED-target.tld] >> subs.txt sort -u subs.txt -o subs.txt # 2. Resolve & check status cat subs.txt | httpx -sc -title -tech-detect -silent # 3. Pull CNAME chains cat subs.txt | dnsx -cname -resp-only -silent | sort -u

One subdomain stood out. It returned a Yumpu-branded error page suggesting the document was no longer available. The CNAME pointed at Yumpu's infrastructure, but the actual publication had vanished. That mismatch is the entire bug.

dig output (sanitized) $ dig +short [REDACTED].[REDACTED-target.tld] [REDACTED].[REDACTED-target.tld]. 300 IN CNAME [redacted].yumpu.com. [redacted].yumpu.com. 60 IN A 5.6.7.8 $ curl -sI https://[REDACTED].[REDACTED-target.tld]/ HTTP/2 404 server: nginx content-type: text/html; charset=UTF-8 <-- Yumpu "Magazine not found" template -->

Verifying the takeover

The proof of exploitability for this bug class is simple but irreversible-ish, so I documented every step and kept the claim within scope:

  1. Created a new Yumpu account using a throwaway email.
  2. From the Yumpu dashboard, started a new Custom Domain mapping and entered the redacted subdomain.
  3. Yumpu's interface accepted it. No DNS verification challenge was required because the existing CNAME already resolved to their platform.
  4. Uploaded an innocuous PoC document clearly labelled "Security Research, Hassan Jawaid, Please do not panic." with a non-intrusive disclaimer.
  5. Captured screenshots of the document being served at https://[REDACTED].[REDACTED-target.tld]/ with the target's TLS certificate intact (because the cert covers the subdomain, not Yumpu).
  6. Immediately released the claim and removed the document so the dangling record was back in its original, vulnerable state for the security team to reproduce.
Impact: Full content control over a trusted subdomain. An attacker can serve phishing pages branded with the target's domain (and a valid TLS lock), exfiltrate cookies scoped to the parent domain via Set-Cookie Domain=.target.tld tricks where applicable, bypass CSP allowlists that name the subdomain, or run drive-by malware delivery against staff and customers who already trust the brand. This is High severity because of network-reachable, unauthenticated, full-impact compromise of a name in the trust boundary.

Disclosure timeline

Report submitted via private program
Triaged within 24 hours, severity confirmed as P2 / High
Vendor removed the orphaned CNAME within 48 hours
Re-test confirmed the takeover vector was closed
Rewarded · P2 High · Hall of Fame

Remediation: what should have happened

For the affected target

  • Delete the dangling CNAME as soon as the third-party integration is sunsetted. This is the only fix that closes the vector definitively.
  • Run periodic DNS audits. Diff your zone file against a list of in-use integrations every quarter. Anything pointing at a SaaS hostname you no longer use is a candidate for removal.
  • Use nuclei -t takeovers/ or can-i-take-over-xyz as part of your continuous monitoring.

For platforms like Yumpu

  • Require domain-verification (TXT challenge) on first claim of a custom hostname, not just whether the CNAME already resolves.
  • Re-verify periodically so a claim can't outlive the customer's actual ownership of the domain.
  • This pattern has been fixed by Heroku, Shopify, Fastly and others, but is still found regularly on smaller SaaS platforms.

Takeaways

Subdomain takeovers are easy to find, easy to fix, and absolutely brutal in impact. They aren't a vulnerability in your application code. They're an artefact of how your organisation manages DNS and third-party services over time. Every quarter that CNAME sits there is another quarter an attacker can claim your name.

If you have a sprawling DNS surface, a long tail of marketing-team integrations from years past, and no inventory of which records point where, you almost certainly have at least one of these live right now. The good news: a single afternoon of dnsx + nuclei takeovers against your own zones will surface them.