{"slug": "three-breaches-three-providers-one-misconfigured-dns-record", "title": "Three breaches, three providers, one misconfigured DNS record", "summary": "Three organizations—Firefox, Shopify, and GitLab—were hit by subdomain takeovers due to misconfigured DNS records pointing to unclaimed resources. A security researcher demonstrated that a dangling CNAME under firefox.com allowed serving arbitrary content and blocking user access via oversized cookies. GitLab's permissive verification window amplified the risk, enabling cookie theft and phishing under gitlab.com.", "body_md": "✓ Human-authored analysis; AI used for formatting and proofreading.\n\nA 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.\n\nThis 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.\n\nA 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.\n\nThe 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](http://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.\n\nThe 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.\n\nShopify 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.\n\nShopify'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.\n\nThe 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.\n\nGitLab 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.\n\nA 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.\n\nThe 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.\n\nThe 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.\n\nThree organizations, three hosting providers (generic CDN, Kajabi, GitLab Pages), three bug bounty reports. The root cause is identical in every case:\n\n**A DNS record points to a resource the organization doesn't control.**\n\nThe lifecycle that creates this misconfiguration is mundane:\n\nStep 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.\n\nIn 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.\n\nThe 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:\n\nThis 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.\n\nThe finding tells the operator what's wrong and what to change:\n\n```\nDEFECT:\n  DNS CNAME record points to an unclaimed or\n  non-existent resource. The subdomain is\n  vulnerable to takeover by any party that\n  claims the target resource.\n\nDELTA:\n  Remove the dangling DNS record, or reclaim\n  the resource at the hosting provider.\n```\n\nThe 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).\n\nA 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:\n\n**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.\n\n**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.\n\n**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.\n\nCompound 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.\n\nThe 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.\n\nThe 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.\n\nContinuous 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.\n\nThe three organizations fixed the issue after external reports. Prevention means fixing it before anyone reports it or exploits it.\n\nSubdomain 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.\n\nThe 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.\n\nOne 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.\n\nThree breaches. Three providers. One misconfigured DNS record. One control that prevents all of them.\n\n*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.*", "url": "https://wpnews.pro/news/three-breaches-three-providers-one-misconfigured-dns-record", "canonical_source": "https://dev.to/bala_paranj_059d338e44e7e/three-breaches-three-providers-one-misconfigured-dns-record-56lh", "published_at": "2026-07-26 11:23:10+00:00", "updated_at": "2026-07-26 11:29:18.839909+00:00", "lang": "en", "topics": ["ai-safety"], "entities": ["Firefox", "Shopify", "GitLab", "Oberlo", "Kajabi"], "alternates": {"html": "https://wpnews.pro/news/three-breaches-three-providers-one-misconfigured-dns-record", "markdown": "https://wpnews.pro/news/three-breaches-three-providers-one-misconfigured-dns-record.md", "text": "https://wpnews.pro/news/three-breaches-three-providers-one-misconfigured-dns-record.txt", "jsonld": "https://wpnews.pro/news/three-breaches-three-providers-one-misconfigured-dns-record.jsonld"}}