Can I Take Over XYZ: The Crowdsourced Database Preventing Subdomain Takeover Blind Spots
Hook
A single forgotten DNS record pointing to a deleted Heroku app can let attackers serve malicious content on your company’s subdomain—and it happens more often than you think.
Context
Subdomain takeover vulnerabilities represent a peculiar class of security issue where organizational entropy becomes an attack vector. When development teams spin up services on platforms like GitHub Pages, AWS S3, or Heroku, they create DNS records pointing subdomains to those resources. Months or years later, someone deletes the cloud resource but forgets to remove the DNS entry. That dangling pointer becomes a vulnerability: an attacker can claim the now-available resource identifier and serve content on your subdomain, bypassing CSP policies, phishing users with a legitimate domain, or stealing cookies.
The challenge for security researchers and bug bounty hunters isn’t recognizing that dangling DNS records exist—tools can easily detect those. The hard part is determining whether a specific service is exploitable. Does Azure still allow custom domain claims on deleted resources? Has Shopify patched their takeover vector? What’s the exact error message that indicates a vulnerable Bitbucket configuration versus a non-exploitable one? Before EdOverflow’s can-i-take-over-xyz repository, this knowledge lived in scattered blog posts, private notes, and the collective memory of veteran researchers. The project emerged to centralize this tribal knowledge into a single, community-maintained reference that evolves as services patch vulnerabilities and new platforms emerge.
Technical Insight
At its core, can-i-take-over-xyz is a markdown table with superpowers. The main README contains a comprehensive list of services with critical data points: the service name, vulnerability status (Vulnerable, Not Vulnerable, or Edge Case), a fingerprint (either a regex pattern or NXDOMAIN indicator), and links to discussion threads. The repository includes a ‘Verified by CI/CD’ column that appears to indicate automated verification status, though the exact validation mechanism isn’t detailed in the documentation.
The project automatically generates a machine-readable fingerprints.json file based on the markdown table content. For entries marked with NXDOMAIN, the service is identified by non-existent DNS records. For regex patterns, specific error messages or page content indicate vulnerability. The table shows examples like AWS Elastic Beanstalk (marked Vulnerable with NXDOMAIN fingerprint) and various other services with their current status.
The real intelligence lives in the GitHub Issues system. Each service gets a dedicated discussion thread where researchers share edge cases, updated methodologies, and platform-specific nuances. These threads preserve institutional knowledge that can’t be reduced to a simple regex pattern.
The repository also standardizes responsible disclosure practices. Rather than encouraging researchers to serve obvious proof-of-concept content on index pages (which could harm legitimate users or violate bug bounty policies), the documentation recommends serving HTML comments on randomly-named paths:
<!-- PoC by username -->This approach demonstrates control over the subdomain without interfering with user experience or triggering alarm systems. Different bug bounty programs have varying requirements—some accept dangling DNS reports without proof of compromise—so the project emphasizes checking program policies before attempting any takeover.
The architecture choice to use markdown tables instead of a database or structured format is deliberate. It lowers the contribution barrier: anyone can submit a pull request to add a row without understanding database schemas or API contracts. The system handles transformation to machine-readable formats, giving you both human-readable documentation and programmatic access.
Gotcha
The repository’s most prominent feature is its disclaimer, and that’s not an accident. The authors explicitly state they ‘take no responsibility for correctness,’ and this isn’t legal boilerplate—it’s a genuine limitation. The data quality depends entirely on community contributions, which vary wildly in recency and accuracy. A service marked ‘Vulnerable’ might have implemented protections that haven’t been documented yet. The CI/CD verification column exists, but the extent of what it validates isn’t fully detailed in the README.
More critically, this is purely a reference database, not a detection tool. Despite having a machine-readable fingerprints.json file, the repository doesn’t appear to include any scanning functionality. If you want to actually check your domains for takeover vulnerabilities, you need to build your own tooling or use third-party automated scanning solutions. This catches newcomers off guard who expect a ready-to-run security tool rather than a knowledge base. The fingerprints are documented with different types—some use regex patterns, others use NXDOMAIN entries—requiring different detection logic that isn’t always well-documented in the table itself.
Verdict
Use this repository if you’re investigating a specific subdomain takeover during security research or bug bounty hunting and need to quickly determine whether the service it points to is exploitable. It’s invaluable for learning the current landscape of takeover vulnerabilities and understanding safe demonstration techniques that won’t violate disclosure policies. The issue discussions are goldmines of nuanced information you won’t find in automated scanning tools. Skip this if you need an automated solution to scan your infrastructure for vulnerable subdomains—you’ll need to build your own tooling or find third-party scanning solutions. Also skip if you’re looking for authoritative, guaranteed-current information; the community-maintained nature means you must independently verify findings and consult recent issue discussions rather than trusting the table at face value. Think of can-i-take-over-xyz as the security researcher’s field guide: essential for understanding the terrain, but not a replacement for doing the actual reconnaissance yourself.
