Inside can-i-take-over-xyz: The Crowdsourced Database Securing Subdomain Hygiene

Hook

A forgotten CNAME record pointing to a deleted Heroku app can let an attacker serve content on your company's subdomain—and there are over 70 services where this can happen. One GitHub repository tracks them all.

Context

Subdomain takeovers represent a peculiar class of vulnerability where organizations inadvertently leave the door open long after the service has left. The attack pattern is deceptively simple: Company X creates a subdomain blog.example.com with a DNS CNAME pointing to their-blog.provider.com. Later, they abandon the provider account but forget to remove the DNS record. An attacker claims their-blog.provider.com and suddenly controls content served from blog.example.com—complete with cookies, session tokens, and user trust.

Before can-i-take-over-xyz emerged in 2017, security researchers maintained scattered notes about which services were vulnerable. Bug bounty hunters would rediscover the same vulnerabilities repeatedly, and defensive teams had no centralized reference for auditing their DNS records. Ed Foudil (EdOverflow) recognized that subdomain takeover knowledge needed to be democratized—not locked in private notes or expensive security platforms. The solution was radically simple: a markdown table on GitHub where the security community could collectively document every service's vulnerability status, required fingerprints, and mitigation steps.

Technical Insight

The genius of can-i-take-over-xyz lies in its dual representation: human-readable markdown for researchers and machine-readable JSON for automation. The core data structure is a markdown table in README.md, with each row representing a service and columns indicating vulnerability status, fingerprint, and documentation. A Python script (generate_fingerprints.py) parses this table and outputs fingerprints.json, enabling integration with automated scanning tools.

Here's how the fingerprint generation works:

# Simplified example of fingerprint extraction
import re

def parse_markdown_table(content):
    services = []
    lines = content.split('\n')
    
    for line in lines:
        if '|' not in line or line.startswith('|---'):
            continue
            
        parts = [p.strip() for p in line.split('|')[1:-1]]
        if len(parts) >= 5:
            service = {
                'service': parts[0],
                'cname': parts[1],
                'fingerprint': parts[2],
                'vulnerable': parts[3].lower() == 'yes',
                'discussion': extract_issue_number(parts[4])
            }
            services.append(service)
    
    return services

The fingerprints themselves are the critical intelligence. When you encounter a dangling DNS record, you need to identify which service it points to and whether that service allows account creation that could lead to takeover. For example, a CNAME pointing to *.azurewebsites.net with an HTTP response containing "404 - Web app not found" indicates a potentially vulnerable Azure App Service. The repository documents this as:

Azure | *.azurewebsites.net | 404 - Web app not found | Yes | #49

The CI/CD pipeline is where automation meets validation. Contributors submit new services via GitHub Issues using templates that enforce structured data entry. Before merging, automated checks verify that fingerprints are unique and that DNS patterns are properly formatted. This prevents duplicate entries and ensures the JSON output remains parsable.

What makes this architecture particularly clever is the separation of concerns. The markdown table serves as the single source of truth for human readers—security researchers can quickly scan for a service and understand its status. The generated JSON feeds into tools like subjack, Nuclei templates, and custom scanning scripts. This means the repository doesn't need to implement scanning logic itself; it simply provides authoritative data that other tools consume.

The issue-based contribution model creates valuable context. Each service links to a GitHub issue where contributors discuss edge cases, service changes, and mitigation strategies. For instance, issue #162 discusses GitHub Pages, where the vulnerability status changed over time as GitHub implemented protections. This historical context helps researchers understand not just whether a service is vulnerable, but why and how protections evolved.

The repository also distinguishes between different vulnerability severities. Some services (marked "Yes") allow immediate takeover—you can create an account and claim the dangling resource. Others (marked "Not anymore") had the vulnerability patched. A third category exists for services where takeover requires specific conditions, like expired accounts or API access. This nuance prevents researchers from wasting time on dead ends.

Gotcha

The repository's primary limitation is its reactive nature—it documents vulnerabilities that the community has already discovered, not emerging threats. If a new cloud service launches tomorrow with takeover vulnerabilities, it won't appear in can-i-take-over-xyz until someone discovers it, verifies it, and submits an issue. For actively scanning infrastructure, you're always working with slightly outdated intelligence.

More critically, the repository explicitly disclaims accuracy guarantees. Services frequently change their behavior—a provider might implement domain verification, rate limiting, or account restrictions that render documented fingerprints obsolete. The burden falls on you to verify findings independently before reporting to bug bounty programs. I've personally encountered situations where a service marked "Yes" had quietly implemented protections months earlier, and the repository hadn't been updated. Automated scanning based solely on this data will generate false positives unless you build verification layers on top.

The fingerprint approach also has blind spots. Some services use dynamic error messages, making static fingerprints unreliable. Others implement soft protections like account verification that aren't binary "vulnerable" or "not vulnerable" states. The markdown table format doesn't capture these nuances well—you get a yes/no answer when reality is often "maybe, if you can bypass X." For sophisticated security work, you'll need to read the linked issues and perform original research.

Verdict

Use if: You're conducting bug bounty hunting, penetration testing, or security audits where subdomain takeover is in scope, and you need a comprehensive starting point for reconnaissance. The repository excels as a checklist—scan your DNS records, cross-reference against this list, then verify manually. It's also valuable for building defensive tooling; parse the JSON to create automated monitoring that alerts when your organization's DNS records point to vulnerable services. Skip if: You need guaranteed real-time accuracy for compliance reporting, you're building a fully automated scanner without human verification, or you're researching novel takeover techniques—this repository documents known vulnerabilities, not cutting-edge research. For production security monitoring, combine this data with active verification and multiple intelligence sources rather than treating it as authoritative truth.