How Hackers Find Subdomain Takeovers — The 15-Second Check That Pays $1,000

How Subdomain Takeovers Happen — The Dangling CNAME

Every subdomain takeover follows the same lifecycle. A company creates a staging environment on Heroku, a documentation site on GitHub Pages, or a landing page on an AWS S3 static website. Their DNS admin creates a CNAME: staging.company.com CNAME acme-staging.herokuapp.com. Six months later, the project ends. A developer deletes the Heroku app. The DNS record is never removed — because removing a DNS record requires a separate ops ticket that nobody creates, and DNS record cleanup is nobody’s specific job.

The vulnerability persists silently. Visitors to staging.company.com follow the CNAME to acme-staging.herokuapp.com and receive Heroku’s “No such app” page. Anyone can create a new Heroku app named acme-staging and claim that subdomain name. Once they do, every visitor to staging.company.com receives whatever content they put there — served under the company’s legitimate domain, trusted by browsers, included in the company’s TLS certificate scope.

The 15-Second Check — 3 Commands

The manual subdomain takeover check is three commands run in sequence. Each gives definitive information. Together they take 15 seconds and produce the exact evidence needed for a bug bounty report.

Vulnerable Cloud Services in 2026

The authoritative reference is can-i-take-over-xyz — a community-maintained list tracking which services allow takeover, the fingerprint string to confirm the dangling state, and current vulnerability status. Services are marked Vulnerable, Needs verification, Not vulnerable, or Fixed as the landscape evolves.

Confirmed vulnerable services as of 2026 include GitHub Pages (fingerprint: “There isn’t a GitHub Pages site here”), Heroku (fingerprint: “No such app”), AWS S3 static website (fingerprint: “NoSuchBucket”), Fastly (fingerprint: “Fastly error: unknown domain”), Shopify (fingerprint: “Sorry, this shop is currently unavailable”), and Zendesk (fingerprint: “Help Center Closed”). Services that have added protections include Squarespace (requires domain verification before a CNAME takes effect) and most Azure services (additional owner-verification steps prevent direct takeover).

Automation with subfinder and subjack

Manual checking works for small scopes. Large bug bounty programmes with hundreds of subdomains require automation. The standard workflow is subfinder for passive enumeration followed by subjack for automated CNAME takeover detection.

Impact, Severity and Bug Bounty Payouts

Subdomain takeover severity is determined entirely by the taken-over subdomain’s trust relationship with the main application. This relationship has three dimensions: cookie scope, OAuth configuration, and CORS policy. Understanding each dimension tells you exactly how severe a finding is before you even write the report.

Cookie scope. When the main application at company.com sets cookies with the attribute domain=".company.com" (note the leading dot), those cookies are scoped to all subdomains. An attacker who controls any subdomain — including a taken-over one — can issue Set-Cookie headers that browsers store and then send to the main company.com application on subsequent requests. This enables session fixation attacks: the attacker pre-sets a known session token via the taken-over subdomain, then tricks the victim into authenticating at the main application, at which point the victim’s authenticated session token matches the attacker’s pre-set token. Check for this by examining the Set-Cookie response headers from the main application: if the domain attribute includes a leading dot, all subdomains are in scope.

OAuth redirect_uri whitelist. OAuth 2.0 implementations protect against token theft by validating the redirect_uri parameter in authorization requests against a server-side whitelist. If a subdomain that has been taken over appears in this whitelist — for example, as a callback URL from a previous development environment — an attacker can craft an OAuth flow that redirects the user’s authorization code to their controlled endpoint. The attacker presents the stolen authorization code to the token endpoint and receives a valid access token. This is consistently the highest-severity subdomain takeover scenario. Check OAuth by examining the application’s authorization endpoint and looking for redirect_uri values referencing company subdomains.

CORS policy. Applications that include taken-over subdomains in their Cross-Origin Resource Sharing allowlist allow JavaScript from those subdomains to make credentialed cross-origin requests to the main application. An attacker who controls the subdomain can serve JavaScript that silently exfiltrates sensitive data from the main application whenever a victim visits the taken-over page. Check CORS by looking at the Access-Control-Allow-Origin response headers from the main API endpoints — if they include subdomains, takeover of any listed subdomain enables cross-origin data theft.

Expected payouts: completely isolated subdomain with no cookie, OAuth, or CORS relationship — $200–400 (Medium on most programmes). Subdomain with wide-scoped cookies or CORS inclusion — $500–1,500 (High). Subdomain in OAuth redirect_uri whitelist — $1,000–5,000+ (Critical on most programmes). The key factor is always: can an attacker use control of this subdomain to compromise the main application, or is it just an isolated phishing opportunity?

Advanced Techniques — Finding Subdomains Others Miss

The most competitive subdomain takeover hunters don’t just run subfinder and subjack. They use sources that most hunters ignore, dramatically increasing their hit rate on programmes that have already been heavily tested by automated tools.

Wayback Machine enumeration. The Internet Archive’s Wayback Machine indexes web content going back to the 1990s, including pages that referenced subdomains that never appeared in modern certificate transparency logs or DNS datasets. Old blog posts, press releases, API documentation, and product announcements frequently contain URLs like https://staging.company.com/preview or https://beta.company.com/signup that are not in any current enumeration tool’s database. Search for the target domain on web.archive.org and browse through historical captures to find these hidden subdomains. These old subdomains are often the most neglected — they were set up for a campaign in 2018, forgotten since 2019, and nobody has ever checked them for takeover vulnerabilities because they don’t appear in standard scans.

GitHub code search. Engineers frequently reference internal infrastructure URLs in public repositories — in README files, configuration examples, CI/CD pipeline definitions, and environment variable documentation. A GitHub search for "company.com" CNAME or site:github.com company.com staging can surface subdomain references that have never appeared in any public DNS dataset. Many of these are development and testing subdomains set up once for a specific sprint and never decommissioned.

Job postings and technical blogs. Engineers who write about their infrastructure architecture — on company engineering blogs, personal blogs, or conference talk write-ups — often mention specific internal subdomain patterns. “We use the pattern [service]-[environment].company.com for all our staging environments” in an engineering blog post tells you exactly where to look. Job postings that mention specific cloud services or infrastructure patterns can reveal what third-party platforms the company uses, helping you predict which CNAME patterns to look for before you even start scanning.

DNS zone walking for DNSSEC-enabled domains. Some domains that have DNSSEC enabled are vulnerable to zone walking — iterating through DNS records to enumerate all subdomains, similar to a full zone transfer. Tools like ldns-walk can attempt this for DNSSEC-signed zones. This is a passive technique that only works on misconfigured DNSSEC implementations, but when it does work, it produces a far more complete subdomain list than certificate transparency logs alone.

Reporting to Bug Bounty Programmes

A strong subdomain takeover report needs five pieces of evidence: the vulnerable subdomain URL, the dig CNAME output showing the dangling record, the dig NXDOMAIN output confirming the target is gone, the curl fingerprint output showing the platform’s error page, and the can-i-take-over-xyz reference confirming the service is known-vulnerable. This evidence set is sufficient for most mature programmes — you do not need to register anything to prove the vulnerability is real.

Common mistakes: submitting without NXDOMAIN confirmation, reporting subdomains outside the declared scope (always verify exact scope boundaries), and submitting subjack output without manual verification (false positives are common — always run the 3-command check manually before submitting).