June 22, 2026
# Chaining Subdomain Takeovers with CORS Misconfigurations for Session Hijacking
An elegant exploit often relies not on a single critical vulnerability, but on the clever chaining of two seemingly low or medium-severity…
By Prince T Philip
3 min read
An elegant exploit often relies not on a single critical vulnerability, but on the clever chaining of two seemingly low or medium-severity flaws. Individually, a dangling DNS record or a relaxed Cross-Origin Resource Sharing (CORS) policy might cause minor compliance alerts. Chained together, they can form a critical attack vector capable of bypassing modern browser security boundaries and hijacking user sessions.
In this write-up, we will break down the mechanics of a real-world assessment where an unclaimable subdomain pointing to cloud infrastructure was paired with a dynamic CORS reflection policy to expose authenticated user data.
The Components of the Chain
To understand the exploit chain, we must look at how the target architecture handled external origins across its infrastructure. The layout involved two distinct assets:
- A Legacy Subdomain: A public-facing web asset that had been decommissioned but retained active DNS records.
- A Production API Gateway: The central backend handling authenticated user sessions and data retrieval.
Component 1: The Dangling CNAME
During passive infrastructure profiling, a DNS lookup revealed that a sub-asset (www.legacy-sub.target.com) maintained a dangling CNAME record pointing to Google's hosting infrastructure:
dig +short [www.legacy-sub.target.com](https://www.legacy-sub.target.com) CNAME
# Output: ghs.googlehosted.com.
When navigating to the domain via a browser or command-line utility, the cloud provider returned a generic server signature indicating that no active resource was bound to the host:
curl -s -I [http://www.legacy-sub.target.com](http://www.legacy-sub.target.com)
# Output: HTTP/1.1 404 Not Found
# Server: ghs
Component 2: Dynamic CORS Whitelisting
Simultaneously, an analysis of the core API gateway (api.target-api.com) revealed a highly permissive Cross-Origin Resource Sharing logic. Instead of validating incoming requests against a strict, static whitelist of trusted origins, the API gateway used a regular expression that dynamically trusted any subdomain matching the parent domain (*.target.com).
When an Origin header pointing to the dangling subdomain was simulated, the API gateway reflected the origin dynamically and explicitly appended the credentials flag:
GET /user/profile HTTP/2
Host: api.target-api.com
Origin: [https://www.legacy-sub.target.com](https://www.legacy-sub.target.com)
---
HTTP/2 200 OK
Access-Control-Allow-Origin: [https://www.legacy-sub.target.com](https://www.legacy-sub.target.com)
Access-Control-Allow-Credentials: true
Vary: Origin
The Exploit Logic & The SameSite Boundary
The critical nature of this configuration stems from how modern browsers handle session storage and cookies. Under standard security models, an external attacker operating from a malicious domain (e.g., attacker.com) cannot easily read an API's responses due to the Same-Origin Policy (SOP).
Furthermore, modern SameSite=Lax cookie configurations prevent session identifiers from being automatically transmitted during cross-site asynchronous requests (fetch or XMLHttpRequest).
However, because the dangling subdomain shares the same registrable top-level domain (target.com) as the organization's primary ecosystem, browser-level isolation rules shift.
If an attacker can execute code from within the *.target.com space, they achieve two immediate advantages:
Bypassing Cross-Site Restrictions: The browser treats the origin as an internal asset rather than an untrusted external site.
Credential Transmission: The Access-Control-Allow-Credentials: true header explicitly commands the browser to include the victim's active session cookies alongside the cross-origin request.
The Attack Flow
The Victim Visits the Asset: An authenticated user with an active session on the primary application is lured to the hijacked subdomain (https://www.legacy-sub.target.com).
Silent Script Execution: A hidden JavaScript payload loads seamlessly under the trusted corporate SSL certificate of the subdomain.
The Authenticated Fetch: The script triggers a background request to api.target-api.com. Because of the Access-Control-Allow-Credentials flag, the browser attaches the user's active session cookies automatically.
Dynamic Trust and Exfiltration: The API gateway reads the origin, matches the wildcard rule, reflects it back, and processes the request.
The script reads the sensitive JSON response and silently exfiltrates it to an external server controlled by the attacker.
The Defense-in-Depth Reality Check
During the triage phase of this specific finding, a critical operational hurdle was identified regarding modern cloud provider defenses.
Many cloud hosting providers (including Google's modern app and site hosting infrastructure) have implemented strict domain verification parameters.
To successfully map a custom domain to an instance, the platform often requires proof of ownership via specific DNS verification tokens (such as a unique TXT record).
Because an outside attacker cannot alter the target's authoritative DNS zone files, they cannot complete the verification handshake. Consequently, the subdomain remains in an unclaimable "dangling" state—rendering the direct takeover path non-viable.
Why the CORS Finding Remains Vital
Even when a cloud provider's verification logic prevents an external takeover, relying on dynamic wildcard reflection (*.target.com) poses an immense defense-in-depth risk.
If an internal asset, a staging server, or an approved partner domain within the corporate namespace is ever compromised natively through a separate vulnerability (like a Cross-Site Scripting or a local server breach), the API gateway will instantly trust that compromised asset. It acts as an open door, turning a localized frontend compromise into a widespread session-harvesting event across the entire user base.
Remediation Strategies
Fixing this vulnerability requires a dual approach targeting both infrastructure cleanliness and secure development practices.
1. Rigorous DNS Hygiene
Organizations must implement automated asset inventory tools to scan zone files for decommissioned resources.
If a cloud instance, bucket, or third-party service is deleted, the corresponding CNAME, A, or AAAA record in the DNS server must be purged immediately.
2. Strict CORS Policies
Never build dynamic reflection loops that echo back the Origin header verbatim alongside credential allowances, especially using wide wildcard patterns.
Implement Static Whitelisting: Define a strict, hardcoded array of fully qualified domain names (FQDNs) that absolutely require API access (e.g., https://dashboard.target.com, https://app.target.com).
Avoid Dynamic Subdomain Matching: If subdomains must be trusted dynamically, ensure they undergo rigorous validation against an active inventory of live, verified corporate assets rather than accepting the entire wildcard space blindly.dig +short [www.legacy-sub.target.com](https://www.legacy-sub.target.com) CNAME
# Output: ghs.googlehosted.com.
When navigating to the domain via a browser or command-line utility, the cloud provider returned a generic server signature indicating that no active resource was bound to the host:
curl -s -I [http://www.legacy-sub.target.com](http://www.legacy-sub.target.com)
# Output: HTTP/1.1 404 Not Found
# Server: ghs
Component 2: Dynamic CORS Whitelisting
Simultaneously, an analysis of the core API gateway (api.target-api.com) revealed a highly permissive Cross-Origin Resource Sharing logic. Instead of validating incoming requests against a strict, static whitelist of trusted origins, the API gateway used a regular expression that dynamically trusted any subdomain matching the parent domain (*.target.com).
When an Origin header pointing to the dangling subdomain was simulated, the API gateway reflected the origin dynamically and explicitly appended the credentials flag:
GET /user/profile HTTP/2
Host: api.target-api.com
Origin: [https://www.legacy-sub.target.com](https://www.legacy-sub.target.com)
---
HTTP/2 200 OK
Access-Control-Allow-Origin: [https://www.legacy-sub.target.com](https://www.legacy-sub.target.com)
Access-Control-Allow-Credentials: true
Vary: Origin
The Exploit Logic & The SameSite Boundary
The critical nature of this configuration stems from how modern browsers handle session storage and cookies. Under standard security models, an external attacker operating from a malicious domain (e.g., attacker.com) cannot easily read an API's responses due to the Same-Origin Policy (SOP).
Furthermore, modern SameSite=Lax cookie configurations prevent session identifiers from being automatically transmitted during cross-site asynchronous requests (fetch or XMLHttpRequest).
However, because the dangling subdomain shares the same registrable top-level domain (target.com) as the organization's primary ecosystem, browser-level isolation rules shift.
If an attacker can execute code from within the *.target.com space, they achieve two immediate advantages:
Bypassing Cross-Site Restrictions: The browser treats the origin as an internal asset rather than an untrusted external site.
Credential Transmission: The Access-Control-Allow-Credentials: true header explicitly commands the browser to include the victim's active session cookies alongside the cross-origin request.
The Attack Flow
The Victim Visits the Asset: An authenticated user with an active session on the primary application is lured to the hijacked subdomain (https://www.legacy-sub.target.com).
Silent Script Execution: A hidden JavaScript payload loads seamlessly under the trusted corporate SSL certificate of the subdomain.
The Authenticated Fetch: The script triggers a background request to api.target-api.com. Because of the Access-Control-Allow-Credentials flag, the browser attaches the user's active session cookies automatically.
Dynamic Trust and Exfiltration: The API gateway reads the origin, matches the wildcard rule, reflects it back, and processes the request.
The script reads the sensitive JSON response and silently exfiltrates it to an external server controlled by the attacker.
The Defense-in-Depth Reality Check
During the triage phase of this specific finding, a critical operational hurdle was identified regarding modern cloud provider defenses.
Many cloud hosting providers (including Google's modern app and site hosting infrastructure) have implemented strict domain verification parameters.
To successfully map a custom domain to an instance, the platform often requires proof of ownership via specific DNS verification tokens (such as a unique TXT record).
Because an outside attacker cannot alter the target's authoritative DNS zone files, they cannot complete the verification handshake. Consequently, the subdomain remains in an unclaimable "dangling" state—rendering the direct takeover path non-viable.
Why the CORS Finding Remains Vital
Even when a cloud provider's verification logic prevents an external takeover, relying on dynamic wildcard reflection (*.target.com) poses an immense defense-in-depth risk.
If an internal asset, a staging server, or an approved partner domain within the corporate namespace is ever compromised natively through a separate vulnerability (like a Cross-Site Scripting or a local server breach), the API gateway will instantly trust that compromised asset. It acts as an open door, turning a localized frontend compromise into a widespread session-harvesting event across the entire user base.
Remediation Strategies
Fixing this vulnerability requires a dual approach targeting both infrastructure cleanliness and secure development practices.
1. Rigorous DNS Hygiene
Organizations must implement automated asset inventory tools to scan zone files for decommissioned resources.
If a cloud instance, bucket, or third-party service is deleted, the corresponding CNAME, A, or AAAA record in the DNS server must be purged immediately.
2. Strict CORS Policies
Never build dynamic reflection loops that echo back the Origin header verbatim alongside credential allowances, especially using wide wildcard patterns.
Implement Static Whitelisting: Define a strict, hardcoded array of fully qualified domain names (FQDNs) that absolutely require API access (e.g., https://dashboard.target.com, https://app.target.com).
Avoid Dynamic Subdomain Matching: If subdomains must be trusted dynamically, ensure they undergo rigorous validation against an active inventory of live, verified corporate assets rather than accepting the entire wildcard space blindly.