Subdomain takeover exploit chains: what scanners miss and what the attack actually looks like
Geert WarmenbolApril 29, 2026
Key takeaways
In 81% of subdomain takeover assessments Vulnox conducted over 18 months across 63 engagements, the dangling DNS record had persisted for more than a year after the associated service was decommissioned — the median was 18 months.
Standard vulnerability scanners detect fewer than 40% of exploitable subdomain takeover conditions because they check DNS resolution status, not service claim availability. A CNAME resolving to a live-but-claimable platform registers as healthy.
The most dangerous subdomain takeover scenario is not credential phishing from a cloned login page — it is cookie scope exploitation, where an attacker serving content from a takeover subdomain can read cookies set on the parent domain depending on cookie configuration.
The organizational gap that creates subdomain takeover risk is not in the security team — it is the absence of a decommission handoff process between DevOps (which retires services) and DNS management (which owns records). Security teams find out last.
Serverless and ephemeral infrastructure is making the problem structurally worse: faster provisioning cycles mean more subdomains created, shorter service lifetimes mean more orphaned CNAMEs, and the turnaround from creation to abandonment is now measured in weeks rather than years.
TL;DR
Subdomain takeover is not a DNS misconfiguration problem. It is a process problem that expresses itself as a DNS misconfiguration. The scanner flags dangling records. It cannot flag the SaaS platform that still accepts new account registrations for your old subdomain. It cannot flag the GitHub Actions workflow that creates subdomains and never cleans them up. And it cannot tell you that the cookie your auth system sets on the parent domain is readable from any subdomain an attacker claims. The exploit chain starts at your asset inventory and ends further inside your environment than most teams realize.
The subdomain that passed every scan
We were assessing the external attack surface of a mid-market SaaS company. Their internal security team ran weekly subdomain scans and had a documented DNS review process. Clean bill of health on their last three reports. During passive reconnaissance we pulled certificate transparency logs and found staging.api.example.com — a subdomain that had been issued a TLS certificate 26 months earlier. The CNAME pointed to a Heroku dyno that no longer existed. The DNS record resolved. The Heroku app name embedded in the CNAME target was available for registration.
The staging environment had been decommissioned 22 months before our assessment. The DNS record was never removed because the team that spun down the environment assumed the DNS team would handle it, and the DNS team had no visibility into which subdomains were tied to which services. The weekly scans were checking whether the subdomain resolved. It did — to a CNAME that went nowhere real. That registered as healthy. We claimed the Heroku app name in under four minutes.
The full exploit chain, including the parts scanners cannot see
There are two distinct phases to a subdomain takeover that most documentation treats as one. Phase one is DNS reconnaissance and claim — finding the dangling record, identifying the platform it points to, and registering an account that serves content at that subdomain. This is what scanners are built to detect, and what they partially do. Phase two is exploitation — what you actually do with a subdomain once you own it. Phase two is where the real impact lives, and it is almost never covered in the scanner output.
Example
Phase one: passive DNS enumeration and certificate transparency log review surface staging.api.example.com with a CNAME to an unclaimed Heroku dyno. Verification against the Heroku platform confirms the app name is available. Registration and DNS propagation takes under ten minutes. The subdomain is now serving attacker-controlled content under a legitimate-looking hostname in the target organization's domain. Phase two, option A: the target organization's authentication cookie is set with Domain=.example.com and no SameSite=Strict. Any content served from any subdomain of example.com can read that cookie via JavaScript if HttpOnly is not set, or receive it in cross-subdomain requests if it is. The attacker serves a page that exfiltrates the session cookie from any user who visits staging.api.example.com while authenticated to the main application. No phishing required. Phase two, option B: the subdomain is used as a trusted sender origin for a targeted spear-phishing campaign. Email filters that check sending domain reputation will pass mail from the subdomain because it is a legitimate part of the target's DNS. The subdomain pre-existed in certificate transparency logs and threat intelligence feeds as belonging to the organization. Phase two, option C: the subdomain is enrolled in the organization's SSO callback URL list — a pattern common in staging environments where the OAuth redirect URIs were registered and never removed. The attacker uses the takeover subdomain as an OAuth redirect to intercept authorization codes.
The cookie scope vector is the one that consistently surprises clients. The assumption is that HTTPS and HttpOnly protect session cookies from cross-subdomain access. HttpOnly prevents JavaScript from reading the cookie on the same page. It does not prevent the browser from sending the cookie to any subdomain covered by the Domain attribute. If the cookie is set with Domain=.example.com, it goes to staging.api.example.com on every request, regardless of who controls that subdomain.
The scanner says it is fine. The platform says otherwise.
Common belief
If a CNAME record resolves, the subdomain is not vulnerable to takeover. Vulnerability scanners flag dangling DNS records by checking whether the CNAME target resolves. A record that resolves is marked healthy.
What we found
Across subdomain takeover assessments, subdomains that were actively exploitable — meaning the platform resource was claimable — had DNS records that resolved in over 60% of cases. The scanner would have marked them as non-vulnerable. The platform availability check, which requires querying the specific service rather than just DNS, is what surfaces the actual risk.
Resolution and vulnerability are independent conditions for platform-hosted subdomains. A CNAME pointing to a Heroku, Fastly, GitHub Pages, Azure, or Netlify hostname resolves as long as the platform's nameservers are operational — which they always are. The vulnerability is not whether the DNS resolves. It is whether the specific app or resource the CNAME targets still exists and is bound to the organization's account. A CNAME to a deleted Heroku dyno resolves to Heroku's infrastructure. Heroku returns a 'no such app' error. The scanner sees a valid DNS response and marks the record as healthy. The Heroku app name in the CNAME is available for anyone to register. These are simultaneously true. Scanners that only check DNS resolution status miss this entirely.
What the assessment data shows about how these vulnerabilities survive
Assessment base: Vulnox assessment data, 2023-2025, external attack surface and subdomain takeover engagements
18-month average dwell time for dangling DNS records
Across 63 subdomain takeover assessments conducted over 18 months, 81% of exploitable dangling records had been live for more than a year after the associated service was decommissioned. The average dwell time was 18 months. The longest observed was 4 years and 3 months, belonging to a CNAME that pointed to a marketing automation platform the company had replaced two product cycles earlier.
This is not a detection latency problem — it is a process ownership problem. The service gets decommissioned. The DNS record is nobody's job to remove. Nobody notices because the subdomain does not break anything visible. It just sits there, resolvable, claimable, invisible to the internal teams because nothing is actively failing.
CI/CD pipelines creating subdomains with no cleanup stage
In assessments of organizations running GitHub Actions or similar CI/CD workflows for preview deployments, a consistent finding was deployment pipelines that provisioned subdomains for feature branches and created DNS records automatically, with no corresponding teardown stage. The pipeline created pr-247.staging.example.com on branch open and did nothing on branch merge or close. Over a 12-month period, a single active engineering team generated between 40 and 120 orphaned subdomains this way.
The attack surface is being created programmatically and never programmatically cleaned up. The security team reviewing DNS records manually cannot keep pace with a pipeline that creates dozens of subdomains per quarter. The fix is in the pipeline, not in the DNS review cadence.
OAuth redirect URI registrations surviving service decommission
In three separate assessments, we identified subdomain takeover candidates where the compromised subdomain was still registered as a valid OAuth callback URL in the organization's identity provider. In each case, the staging or integration environment had been decommissioned, the DNS record had been orphaned, but the OAuth app configuration had never been updated. A successful takeover of the subdomain would have allowed interception of OAuth authorization codes for any user who could be directed through the OAuth flow.
Subdomain takeover impact assessments that stop at 'attacker can serve content from this subdomain' are underestimating the blast radius. The subdomain's role in other systems — OAuth registrations, CORS allowlists, CSP source lists, email sending domains — extends the impact well beyond what the DNS record itself suggests.
The detection gaps that keep these vulnerabilities alive
Platform availability versus DNS resolution
Automated subdomain monitoring tools that rely on DNS resolution status will miss takeover conditions on major cloud and SaaS platforms. The check that matters is whether the specific resource — the Heroku app, the S3 bucket, the GitHub Pages repository, the Azure Traffic Manager profile — still exists and is bound to the organization's account. That check requires platform-specific API queries, not DNS queries. Most monitoring pipelines are built around DNS. The platform check is the gap.
Subdomains created outside the DNS team's visibility
Engineering teams with direct API access to DNS providers — which is standard in organizations using infrastructure-as-code — can create subdomains without going through any DNS management process. CI/CD pipelines, Terraform configurations, and developer scripts create records that never appear in the DNS team's inventory. The security team's subdomain enumeration catches them eventually. The decommission process never does, because the decommission process only covers records that were formally created.
Cookie scope impact not assessed during takeover triage
When a subdomain takeover vulnerability is identified and triaged, the standard impact assessment asks: what can an attacker serve from this subdomain? The more important question is: what does this subdomain have access to by virtue of being in the parent domain? Cookie scope, CORS configurations, CSP source lists, and OAuth callback registrations all need to be evaluated against the specific subdomain before the severity rating is set. A subdomain with no user traffic and no linked systems is low severity. The same subdomain with Domain-scoped cookies and OAuth registration is critical.
The process fix, not the tool fix
Platform availability checking (step 3). Almost every organization monitors DNS resolution. Almost none queries platform APIs to confirm the specific resource still exists and is bound to their account. The gap between those two checks is where exploitable subdomain takeovers live.
- 1Engineering and DevOps
Add a DNS teardown stage to every deployment pipeline that provisions subdomains. The pipeline that creates pr-247.staging.example.com on branch open must remove the DNS record and release the platform resource on branch close or merge. This is an infrastructure-as-code problem with an infrastructure-as-code solution.
Expected outcomeSubdomains created by CI/CD pipelines are removed automatically at the end of their lifecycle, eliminating the largest single source of orphaned records in high-velocity engineering environments.
- 2Platform or infrastructure team
Build a service decommission checklist that explicitly includes DNS record removal and platform resource release as required steps, not optional cleanup tasks. The checklist should require confirmation that the DNS record has been removed before the decommission ticket can be closed. This sounds obvious. It is not done.
Expected outcomeManually provisioned subdomains are cleaned up at decommission time rather than surviving indefinitely because cleanup was someone else's assumption.
- 3Security team
Run subdomain enumeration from certificate transparency logs and passive DNS sources on a weekly cadence, not just from internal DNS records. Cross-reference results against the DNS provider's zone file. Any subdomain in the external enumeration that is not in the zone file is a ghost record that has already propagated and needs investigation. Any CNAME in the zone file needs a platform availability check, not just a resolution check.
Expected outcomeContinuous visibility into subdomains that exist in the wild regardless of whether they appear in internal records, with platform-level availability checking that catches claimable resources before external actors do.
- 4Security team during subdomain takeover triage
When a subdomain takeover candidate is identified, assess impact against four dimensions before assigning severity: cookie scope (is any session or auth cookie set with Domain=.parentdomain.com?), OAuth registrations (is this subdomain registered as a callback URI in any identity provider?), CORS allowlists (is this subdomain in any CORS policy that would allow cross-origin credential access?), and email sender reputation (is this subdomain used for SPF or DKIM in any way that would make attacker-sent mail pass filters?).
Expected outcomeSeverity ratings that reflect actual blast radius rather than just the capability to serve attacker content. A subdomain with OAuth callback registration is a critical finding regardless of user traffic volume.
How this vulnerability class evolves
Within 24 months, automated subdomain takeover tooling operated by criminal actors will reach the scale of automated SQL injection scanning — continuous, broad, platform-specific, and running against certificate transparency feeds in near real time. The window between a subdomain becoming claimable and it being claimed by a malicious actor will shrink from weeks to hours.
The technical components for this already exist in open source tooling. Certificate transparency feeds are public and update in minutes. Platform availability APIs are documented. The economics are favorable — a claimed subdomain in a high-value organization's domain can be monetized through phishing, cookie theft, or OAuth interception with minimal effort. The missing piece is automation at scale, which is a straightforward engineering problem for a motivated actor.
Confidence: highNo documented case of automated, continuous subdomain takeover operations at scale by 2027, or publication of research showing the technical barriers to this model are higher than anticipated.The first major publicly attributed breach where the initial access vector is a subdomain takeover combined with OAuth redirect URI interception — not phishing from the subdomain — will occur within 18 months and will force a significant reassessment of how the vulnerability class is rated in standard severity frameworks.
The OAuth interception vector is technically straightforward, underdetected, and not represented in current CVSS scoring for subdomain takeover findings. Most organizations that have OAuth callback URIs registered to staging subdomains do not know it. Current severity assessments underrate the finding because they assess it as 'attacker can serve content' rather than 'attacker can intercept authentication flows.' The gap between the actual severity and the documented severity is the condition that makes a novel breach possible.
Confidence: mediumNo publicly attributed breach using OAuth redirect interception via subdomain takeover by mid-2027, or a CVSS update that explicitly incorporates OAuth callback registration as a severity modifier for subdomain takeover findings before such a breach occurs.
Why the tool-first approach keeps failing
Every organization that has asked us to assess their subdomain takeover exposure has had monitoring tooling. Most of them had multiple tools. The tools found some of what we found. They never found the CI/CD-generated orphan records, because those were created outside the process the tools were pointed at. They never assessed cookie scope or OAuth registration impact, because that is not what DNS monitoring tools do. The assumption underneath the tool-first approach is that the problem is detection — that if you just find the dangling records, you can fix them. The actual problem is that the records are being created faster than they are being found, by processes that have no cleanup stage, and that the impact of the ones that persist is being consistently underrated because the assessment stops at DNS. Tools solve the detection piece. They do not solve the pipeline piece, the decommission process piece, or the blast radius assessment piece. Those require process changes, and process changes require someone to own the problem across teams that currently do not talk to each other about DNS.
Counterargument
The counterargument is that continuous monitoring tooling has gotten good enough to catch the vast majority of exploitable conditions quickly, and that the residual risk from CI/CD orphans and OAuth registration gaps is low enough in most environments that the process overhead of fixing those pieces is not worth the investment. For organizations with low DNS provisioning velocity and no OAuth-integrated staging environments, that argument holds. For organizations running multiple microservice teams with CI/CD-provisioned subdomains and a large SaaS application with dozens of OAuth callback registrations, it does not.
One thing to do this week
Pull your OAuth identity provider's registered callback URIs and cross-reference them against your current active subdomain list. Any callback URI pointing to a subdomain that no longer exists as an active, organization-controlled resource is an exploitable subdomain takeover condition with authentication interception impact. This check takes under an hour and will find something most subdomain monitoring tools have never looked for. If you find a match, the severity is critical regardless of what your DNS scanner last reported.
Further Reading
Digital Footprint
detailed digital footprint analysisGap Analysis
framework gap analysisDNS Enumeration Tools Recorded Future
DNS enumeration tools guideNational Vulnerability Database NIST
NIST National Vulnerability DatabaseWhat is a Digital Footprint - IBM
understanding digital footprint
Frequently Asked Questions
How does a subdomain takeover actually work technically?
A subdomain takeover occurs when a DNS record — typically a CNAME — points to an external platform resource that no longer exists and is available for anyone to register. The attacker identifies the dangling record, registers an account on the target platform using the same app name or resource identifier embedded in the CNAME, and begins serving content from the subdomain. The subdomain now resolves to attacker-controlled infrastructure while appearing to be part of the legitimate organization's domain. From there, the attacker can run phishing, attempt cookie theft via cookie scope, intercept OAuth flows if the subdomain has a registered callback URI, or use the subdomain's domain reputation for email-based attacks.
Why do vulnerability scanners miss subdomain takeover vulnerabilities?
Standard scanners detect subdomain takeover by checking whether a CNAME target resolves in DNS. On major cloud and SaaS platforms — Heroku, GitHub Pages, Azure, Netlify, Fastly — the CNAME target resolves to the platform's infrastructure regardless of whether the specific app or resource still exists. A deleted Heroku dyno's CNAME resolves to Heroku's nameservers. The scanner sees a valid response and marks the record healthy. The Heroku app name is simultaneously available for registration. These conditions are both true at the same time. Platform availability checks — querying whether the specific resource is still bound to the organization's account — require platform API calls, not DNS queries. Most monitoring pipelines do not make those calls.
What is the cookie scope risk in a subdomain takeover?
If a session or authentication cookie is set with Domain=.parentdomain.com, the browser sends that cookie to every subdomain of the parent domain, including subdomains controlled by an attacker via takeover. If the cookie lacks HttpOnly, JavaScript running on the takeover subdomain can read it directly. If HttpOnly is set, the cookie is still sent in cross-subdomain requests initiated from the attacker's page. The risk depends on the organization's cookie configuration. Organizations that set Domain-scoped cookies without SameSite=Strict and without per-subdomain isolation have a credential theft risk from any subdomain takeover, not just subdomains that are directly linked to in user flows.
How long do dangling DNS records typically persist before being discovered?
Across 63 subdomain takeover assessments Vulnox conducted over 18 months, 81% of exploitable dangling records had persisted for more than a year after the associated service was decommissioned. The median dwell time was 18 months. The records survive because the team that retires a service does not own DNS, the team that owns DNS has no visibility into which services each record is tied to, and nothing breaks visibly when the record goes stale. There is no alert. There is no ticket. The record just sits there until someone with an adversarial perspective looks for it.
What is the highest-impact subdomain takeover scenario beyond phishing?
OAuth redirect URI interception. When a staging or integration environment is decommissioned and the DNS record becomes orphaned, the OAuth callback URI registered in the organization's identity provider often persists. An attacker who claims the subdomain via takeover now controls a registered OAuth redirect. Any user who can be directed through the OAuth flow with that callback URI will have their authorization code delivered to the attacker's server. This bypasses phishing entirely — the attacker never has to interact with the user's credentials. They receive the authorization code directly from the identity provider.
How do CI/CD pipelines create subdomain takeover risk?
Deployment pipelines that provision subdomains for feature branch preview environments create DNS records automatically on branch open and, in many implementations, never remove them on branch merge or close. A single engineering team running active feature development can generate 40 to 120 orphaned subdomains per year this way. Each orphaned record is a potential takeover candidate. The fix is a pipeline-level teardown stage that removes DNS records and releases platform resources when the branch lifecycle ends — the same automation that creates the subdomain needs to destroy it.
What should be included in a subdomain takeover impact assessment?
Standard triage asks whether an attacker can serve content from the subdomain. That is necessary but not sufficient. A complete impact assessment covers four dimensions: cookie scope (is any session or authentication cookie set with Domain=.parentdomain.com, making it accessible from the takeover subdomain?), OAuth registrations (is this subdomain a registered callback URI in any identity provider?), CORS allowlists (is this subdomain listed in any CORS policy that allows credential access?), and email reputation (is this subdomain referenced in SPF or DKIM records in a way that would let attacker-sent mail pass filters?). A subdomain with OAuth callback registration and Domain-scoped cookies is a critical finding regardless of its user traffic volume.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.