✓ Human-authored analysis; AI used for formatting and proofreading.
The attack that requires no skill
A subdomain takeover doesn't require exploiting a vulnerability. No buffer overflow, injection or zero-day. The attacker looks at a DNS record, checks whether the resource it points to is unclaimed, and claims it. The subdomain now serves their content under the victim's trusted domain.
This has happened to Firefox, Shopify, and GitLab. To organizations with dedicated security teams and active bug bounty programs. The attack is trivially simple, and it keeps working because the misconfiguration that enables it is invisible until someone checks.
Firefox: trusted domain, attacker content
A subdomain under firefox.com had a CNAME record pointing to a hosting provider. The registration at that provider had lapsed. A security researcher claimed the resource and demonstrated that they could serve arbitrary content under the firefox.com domain.
The researcher's proof of concept went further: by serving a page that set large cookies via HTTP, they could block individual users from accessing www.firefox.com. A tracking pixel embedded anywhere on the web could trigger this silently. The user's browser visits the attacker's page under the trusted subdomain, receives oversized cookies scoped to .firefox.com, and subsequent requests to the real Firefox site fail because the cookie header exceeds server limits.
The domain's CAA records prevented the attacker from obtaining a TLS certificate, limiting the attack to HTTP. Without that protection, the attacker could have served convincing phishing pages over HTTPS under firefox.com — indistinguishable from legitimate Firefox content to most users.
Shopify: abandoned product, live DNS
Shopify acquired Oberlo, an e-commerce tool. When course.oberlo.com was migrated away from Kajabi, the DNS CNAME remained but the Kajabi registration was released. An attacker registered the endpoint on Kajabi and served their own content under course.oberlo.com.
Shopify's response was instructive: they parked the domain and closed the report as resolved, but declined to pay a bounty because the subdomain didn't host authenticated content. The impact was limited to social engineering and phishing.
The assessment is technically correct — no user data was at risk from this specific takeover. But it reveals a common blind spot: organizations evaluate dangling DNS records by their current impact rather than their potential impact. Today the subdomain hosts nothing sensitive. Tomorrow it could be repurposed for an authenticated service. The dangling record persists either way.
GitLab: verification window as attack surface
GitLab Pages allows users to add custom domains to their pages sites. The platform serves content for the custom domain before verification completes. There's a 7-day window where unverified domains are live.
A researcher found that docs-dev.gitlab.com had a CNAME pointing to gitlab-com.gitlab.io. By creating a GitLab Pages site and adding docs-dev.gitlab.com as a custom domain (unverified), the researcher's content was served under GitLab's domain — immediately, without completing verification.
The impact was broader than the Firefox case: the attacker could steal cookies scoped to .gitlab.com, bypass Content Security Policies, circumvent CORS restrictions, and run phishing campaigns under a domain users trust for development tools.
The GitLab case adds a dimension the other two don't have: the hosting provider's own behavior (serving content before verification) amplifies the DNS misconfiguration. The dangling CNAME is necessary for the attack, but GitLab's permissive verification window makes exploitation faster and easier.
One root cause
Three organizations, three hosting providers (generic CDN, Kajabi, GitLab Pages), three bug bounty reports. The root cause is identical in every case:
A DNS record points to a resource the organization doesn't control.
The lifecycle that creates this misconfiguration is mundane:
- Team deploys a service on a hosting provider
- Another or the same team creates a CNAME record pointing the subdomain to the provider
- Service is decommissioned or migrated
- The hosting provider registration is released
- The DNS record is not removed
Step 5 is the failure. Steps 1-4 are normal operations. Nobody intends to leave a dangling record. It's an artifact of the gap between infrastructure decommissioning and DNS cleanup. Different teams often manage these: the application team decommissions the service, the infrastructure team manages DNS. The decommission happens; the DNS cleanup doesn't.
In organizations with hundreds or thousands of subdomains, manually auditing every DNS record against every hosting provider registration is impractical. Records drift. Providers change. Registrations expire. The gap between "what DNS says" and "what actually exists" grows over time.
Why scanning finds it before attackers do
The misconfiguration is detectable from DNS records alone. A CNAME record that resolves to a resource returning an error page, a default hosting provider page, or no response at all is a candidate for takeover. The check is deterministic:
- Enumerate all CNAME records for the organization's domains
- For each CNAME target, check whether the organization controls the resource
- If the target is unclaimed, unregistered, or returning a default/error page — the record is dangling
This check runs against DNS configuration data — no live infrastructure probing needed, no authentication required, no agents to deploy. It's the same class of configuration evaluation that detects public S3 buckets, open security groups, or missing encryption: read the configuration, evaluate a predicate, report the finding.
The finding tells the operator what's wrong and what to change:
DEFECT:
DNS CNAME record points to an unclaimed or
non-existent resource. The subdomain is
vulnerable to takeover by any party that
claims the target resource.
DELTA:
Remove the dangling DNS record, or reclaim
the resource at the hosting provider.
The operator doesn't investigate which hosting provider is involved, whether the registration expired, or what content could be served. The finding carries the triage context: what's wrong (dangling record), how it enables attack (anyone can claim the target), worst case (phishing, cookie manipulation, CSP bypass under trusted domain), and what to change (remove or reclaim).
The compound risk
A dangling DNS record is medium severity alone. It enables phishing and cookie attacks under a trusted domain. Combined with other DNS misconfigurations, the risk compounds:
Dangling record + no domain transfer lock. An attacker takes over a subdomain AND the organization's domain registration has no transfer lock. The attacker can attempt to transfer the entire domain — not just serve content on one subdomain but control all DNS for the domain.
Dangling record + no DNSSEC. Without DNSSEC, DNS responses can be spoofed. An attacker doesn't even need to find a dangling record. They can spoof DNS responses for any subdomain. But a dangling record makes the attack easier and more persistent: the attacker controls real infrastructure at the CNAME target, not just spoofed responses.
Dangling record + wildcard DNS. Some organizations use wildcard DNS records (*.example.com) that resolve to a default endpoint. If the default endpoint is on a provider where anyone can claim subdomains, every possible subdomain under the organization's domain is vulnerable — not just the ones with explicit records.
Compound detection surfaces these combinations. The individual findings (dangling record, no transfer lock, no DNSSEC) are linked when they coexist on the same domain. The operator sees "your domain has multiple DNS security gaps that compound into full domain compromise risk" as one triage unit, not three separate findings they mentally correlate.
Prevention at DNS speed
The three H1 reports share one other characteristic: the organizations learned about the misconfiguration from external researchers, not from internal tooling. In every case, the attacker (or researcher simulating one) found the dangling record before the organization did.
The gap between "record becomes dangling" and "organization removes record" is the attack window. For Firefox, the window was long enough for a researcher to claim the resource and demonstrate cookie manipulation. For Shopify, long enough for an attacker to serve arbitrary content. For GitLab, the 7-day verification window meant the attack was exploitable within hours.
Continuous scanning closes this window. The DNS configuration is evaluated on every cycle. The moment a record becomes dangling. Because a hosting registration expired, a service was decommissioned, or a provider changed their infrastructure, the finding appears. The operator removes the record before an attacker claims the resource.
The three organizations fixed the issue after external reports. Prevention means fixing it before anyone reports it or exploits it.
Tackling the Cloud Resource Lifecycle
Subdomain takeover is not a sophisticated attack. An attacker reads a DNS record, checks a hosting provider, and claims an unclaimed resource. That's the whole attack.
The surprise is that it keeps working. Organizations with security teams, bug bounty programs, and substantial infrastructure budgets still have dangling DNS records. Because the gap between infrastructure changes and DNS cleanup is structural. Different teams, timelines and priorities.
One DNS configuration check — is this CNAME target controlled by us? — prevents every subdomain takeover regardless of hosting provider, service type or attacker's intent. The check is trivial. The consequences of not checking are a trusted domain serving attacker content.
Three breaches. Three providers. One misconfigured DNS record. One control that prevents all of them.
Dangling DNS detection is implemented in Stave, an open-source security CLI that finds misconfigurations before attackers do. CTL.ROUTE53.DANGLING.001 detects DNS records pointing to unclaimed resources. Compound chains surface the combined risk when dangling records coexist with missing transfer locks or absent DNSSEC.
Top comments (0)