Nine Programs, Nine Organizations, One Forgotten DNS Record: How FireCompass’s Agentic AI Penetration Testing Found Subdomain Takeover Risk Across Five Cloud and CDN Providers

Introduction

A subdomain takeover starts with a decommissioning step nobody remembered to do. A team points a company subdomain at a third-party resource, a CDN edge, a cloud app, a storage bucket, a static-site build, and later deletes or renames that resource without ever removing the DNS record that pointed to it. The subdomain keeps resolving, now to a name the provider considers unclaimed. Anyone who notices can register that same name on the same provider, and from that moment on, they control whatever gets served under the company’s own, trusted domain.

Across a series of independent bug bounty assessments spanning confectionery and food manufacturing, aviation and travel technology, insurance, multi-brand retail franchising, food service and facilities management, gaming and interactive entertainment, personal care and grooming, financial services, and fundraising and donor technology, FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs surfaced 9 candidate dangling-DNS and subdomain-takeover findings. Every single one came from a different organization, 9 candidates, 9 distinct programs, no repeats. Four of those findings, spanning 4 distinct programs, were validated by the affected programs as genuine issues, resolved, triaged, or confirmed as duplicates of an already-known valid report, and all four surfaced within the same quarter (2026 Q2).

A note on the 5 findings closed informative or not applicable: this is the starkest example in this series of why that classification should not be read as “inaccurate.” The excluded set contains all 3 of the sample’s critical-severity findings and one of its four high-severity findings, the more severe half of the sample by rating, not the less credible half. Programs close subdomain-takeover reports informative for reasons specific to this vulnerability class: the subdomain may be low-traffic, already scheduled for decommissioning, or judged low business impact even though the takeover path itself was real and confirmed claimable.

Because that distinction matters here more than anywhere else in this series, this article covers all 9 candidates, not only the four the affected programs acted on. Each finding below is grouped by the type of provider involved, with its actual status and severity noted.

To protect the affected organizations, all identifying information, including company names, domains, endpoints, and HackerOne report identifiers, has been removed throughout this article. Each finding is referenced only by industry and vulnerability mechanics; third-party CDN and cloud providers are named only where naming them does not identify the client program itself. Technical descriptions below are representative compositions of each finding’s mechanics, written to convey how the issue works without disclosing exploit-ready specifics.

The Nine Findings

The 4 findings resolved, triaged, or confirmed as duplicates of an already-known valid report are listed first; the 5 findings closed informative or not applicable follow.

The DNS Cleanup Gap Behind Every Dangling Record

In every one of these 9 findings, decommissioning a resource and removing the DNS record that pointed to it were treated as two separate tasks, and only the first one made it onto anyone’s checklist. The provider changes each time, a CDN, a cloud app platform, an object store, a static-site host, or a generic hostname, but the missing step is identical.

The flow that recurred, with only the provider changing, looked like this:

From Anomaly to Proof: A Three-Stage Validation Model

A subdomain-takeover scanner can flag that a CNAME points somewhere that returns an error page. It cannot, on its own, tell a defender whether that error means the name is genuinely claimable or just temporarily down, and it should never complete an actual takeover to find out, because unlike a reversible API write, a real subdomain takeover cannot be safely undone once content is served under the company’s domain. Across all 9 candidates, FireCompass’s Agentic AI Penetration Testing for Web Apps and APIs ran the same three-stage discipline, adapted for that constraint:

That adaptation, proving claimability through the provider’s own signals and stopping there, is what separates an evidence-backed finding from both a false-positive scanner alert and an irresponsible live takeover.

How the Pattern Played Out Across Four Provider Types

Correlating the 9 candidates after the fact grouped them into four recurring provider categories, each hit by the identical DNS cleanup gap.

Pattern 1: Dangling CDN Custom Domains (3 findings)

The most repeated provider category in the sample, and the only one that recurred on the exact same CDN vendor three separate times, at a retail franchise group, a gaming publisher, and a fundraising technology platform:

Apex domain CDN mapping (Retail / Multi-Brand Franchising, High, Not Applicable): a retired brand site’s apex domain remained mapped to the CDN vendor’s edge network after the underlying site was retired, with no active origin behind it.

Gaming platform domain mapping (Gaming / Interactive Entertainment, High, Duplicate): a decommissioned promotional site’s CDN domain mapping remained active after the campaign ended, confirmed as a duplicate of an already-known valid report.

Fundraising platform custom domain (Fundraising / Donor Technology Platform, Critical, Informative): a custom domain used for a specific reporting or campaign subdomain remained mapped to the CDN vendor after the underlying deployment was retired.

Pattern 2: Dangling Cloud PaaS and Object-Storage CNAMEs (2 findings)

The same gap on infrastructure providers rather than a CDN, at a travel technology company and an insurer:

Cloud app CNAME (Aviation / Travel Technology, High, Resolved): an administrative subdomain’s CNAME pointed at a cloud PaaS app instance that had since been deleted, returning the provider’s default app-not-found page.

Object storage bucket CNAME (Insurance, Critical, Informative): a subdomain’s CNAME pointed at an object-storage bucket that no longer existed, with the provider returning a bucket-not-found response that specifically indicates the name is available to re-register.

Pattern 3: Dangling Static-Site and Config-Platform Domains (2 findings)

The same gap on platforms built for marketing microsites and content management, at a personal-care brand and a financial-services firm:

Survey microsite custom domain (Personal Care / Grooming, High, Duplicate): a customer-survey microsite’s custom domain remained connected in DNS to a static-site hosting platform after the site itself was removed from the platform, confirmed as a duplicate of an already-known valid report.

Investor-relations subdomain (Financial Services / Insurance & Retirement, Critical, Informative): an investor-relations-related subdomain remained connected in DNS to a CMS-hosting platform configuration that no longer had an active site behind it.

Pattern 4: DNS Hygiene Gaps Beyond a Single Vendor (2 findings)

The fourth pattern isn’t a single-vendor mechanism at all, it’s evidence that the same underlying habit, once present in a team’s DNS management process, produces stale records across more than one provider at once:

Multi-subdomain CNAME sprawl (Food Service / Facilities Management, Unrated, Informative): a review of the organization’s subdomain footprint found multiple CNAME records, spanning more than one backing provider, that no longer resolved to an active, matching service.

Dangling real-time messaging domain (Confectionery / Food Manufacturing, Unrated, Triaged): a subdomain provisioned for a real-time messaging or notification feature remained pointed at a hostname the underlying service no longer answered for.

Why This Matters

Every Single Candidate Came From a Different Organization: 9 candidates, 9 distinct programs, zero repeats, the strongest signal in this entire series that a vulnerability class is systemic rather than one team’s isolated mistake.

The Excluded Set Was the More Severe Half, Not the Less Credible Half: all 3 critical-rated findings and one of the four high-rated findings were closed informative or not applicable, while every validated finding that carried a rating was high, underscoring that closure status here tracks business-impact judgment, not technical severity.

No Authentication or Injection Required: every finding in this sample was detectable from public DNS records and public provider responses, no credentials, no backend access, and no application logic flaw were involved.

Cross-Provider, Cross-Industry Recurrence: the identical DNS cleanup gap reproduced independently across five different provider types and nine unrelated industries, with one CDN vendor alone accounting for a third of the entire sample.

Root Cause

Every one of these 9 findings shares one process root cause: decommissioning a resource and decommissioning the DNS record that pointed to it were treated as separate, disconnected tasks, owned by different teams or tools. The application team retires a service; the DNS zone is managed elsewhere, often by a different team entirely, with no automated link between the two. The record survives the resource by default, not by decision, nobody chose to leave it dangling, but nobody was responsible for removing it either.

Remediation and Key Lessons for Organizations

• Make DNS Teardown Part of Resource Teardown, Not a Separate Step: any automation that provisions a CNAME or custom domain for a resource should be the same automation that removes it when the resource is deleted.
• Maintain a Live Inventory of Every Subdomain and What It Points To: a DNS zone accumulates records faster than any team remembers to review it, an authoritative, regularly reconciled inventory is the only reliable defense.
• Monitor for Provider-Specific Not-Found Signals on Owned Subdomains: an automated check that periodically requests every known subdomain and flags provider-default error pages catches dangling records long before a researcher does.
• Prefer Provider Domain-Verification Features Where Available: many CDN and cloud platforms offer a way to lock a custom domain to a specific account even when unused, reducing the window in which a deleted resource’s domain is claimable by anyone else.
• Treat Every Confirmed-Claimable Finding as Urgent Regardless of Traffic Volume: a low-traffic subdomain is still capable of hosting a convincing phishing page under the company’s trusted domain name.
• Audit DNS Hygiene Across the Whole Footprint, Not Provider by Provider: the fourth pattern in this piece shows stale records accumulate across multiple providers at once inside the same organization, a review scoped to a single vendor will miss the rest.

Lessons Learned

Subdomain takeover is one of the few vulnerability classes in this series where the fix is entirely process, not code, there is no patch for a forgotten DNS record beyond removing it. Seeing the identical gap recur across 9 completely unrelated organizations, on 5 different provider types, with zero repeat programs, is about as strong a signal as this dataset produces that DNS lifecycle management is an industry-wide blind spot rather than a one-off oversight.

It is worth being especially disciplined here about what does not belong in the validated count, because this category makes the fairness point more starkly than any other in this series. Of the 9 candidates the agent surfaced, 5 were closed informative or not applicable, and that excluded set contains every single critical-rated finding in the sample. Closure status here reflects a program’s judgment about business impact and traffic on a specific subdomain, not a determination that the underlying takeover path was unreal; every one of those 5 findings was independently confirmed claimable during validation, exactly like the 4 the programs acted on.

How FireCompass’s Agentic AI Penetration Testing Identified and Exploited These Bugs

Across all four patterns, the same autonomous sequence produced every finding: enumerate the subdomain footprint, detect DNS records pointing at resources that no longer answer as their original service, validate claimability through each provider’s own signals, then document the confirmed exposure without ever completing a takeover that could not afterward be undone. No step required a human operator to manually check each subdomain, and no step created a live, exploitable takeover as part of proving the risk was real.

The advantages this demonstrates for an agentic platform over manual DNS audits:

Continuous, Unscoped Coverage: the same discipline enumerates and re-checks every subdomain autonomously, not a periodic manual sweep, which is how the identical cleanup gap got caught across nine unrelated organizations.

Evidence-Backed Findings, Not Guesses: every candidate is confirmed claimable through the provider’s own signals before being reported, so defenders receive proof of exposure instead of a guess from a stale-looking CNAME.

Consistent Methodology at Scale: the same detect/validate/document sequence applies identically across a CDN, a cloud PaaS, an object store, or a static-site host, producing comparable results across an entire program portfolio.

Safe by Construction: the agent proves a resource is claimable and stops there, deliberately never registering it, because a real takeover cannot be reversed once content is served under the company’s domain.

Faster Time to Validated Finding: enumeration, provider-signal validation, and safe proof-of-availability happen autonomously, freeing human researchers for the judgment calls the agent flags rather than manually checking every subdomain a scan turns up.

For defenders, the broader takeaway stands regardless of platform: DNS teardown belongs in the same checklist as resource teardown, and every subdomain a company owns should be periodically re-verified against exactly the kind of provider-signal check this pattern relies on, before a researcher, or an attacker, finds the gap first.