The “Orphaned Staging Server” Vulnerability: Tracking Expired Dev Subdomains Before They Leak Client IP and Data

Software teams move quickly, and many organizations lean on outside agencies, contractors, and boutique dev shops to spin up proofs-of-concept, preview builds, and testing environments. Those environments typically live on subdomains such as staging.clientdomain.com, dev-v2.clientdomain.com, or client-preview.agency-infra.com.

The trouble starts when the project ends. The agency shuts down the cloud instance, releases the IP address, or deletes the hosted app, but the DNS record that pointed to it stays in place. The result is a dangling DNS record: a live, trusted hostname with nothing behind it, or worse, something anyone can claim.

This is the “orphaned staging server” problem. It is not a new class of bug. Security researchers call it a dangling DNS record or subdomain takeover, and it is documented, actively exploited, and still common. The orphaned staging server is just the version agencies and their clients create most often, because short-lived project infrastructure is exactly what gets provisioned fast and forgotten.

1. Anatomy of an Orphaned Staging Environment

Staging servers are built for agility, not permanence, and teams often treat them as disposable. A typical lifecycle looks like this:

[ Project starts ]  -> Agency launches a staging app on a cloud host
                    -> A DNS record is created:  staging.clientdomain.com -> agency-resource.cloudprovider.example

[ Project ends ]    -> Agency deletes the app, bucket, or VM and releases the IP
                    -> The DNS record is never removed

[ Later ]           -> Anyone who can re-register the same resource name
                       (or, in rarer cases, obtain the same IP)
                       now controls what staging.clientdomain.com serves

MDN describes the underlying mechanism plainly: if you take down a virtual host but leave the DNS entry pointing at the provider, an attacker can create their own virtual host with that provider, claim your subdomain, and host their own content under it.

Where the Handoff Breaks

The gap sits between the business relationship and the technical cleanup:

1. The contract ends. The agency decommissions the VM, deletes the app or bucket, or releases the elastic IP back to the provider’s pool.
2. The DNS blind spot. The client revokes the agency’s logins, but nobody tells whoever administers the DNS zone to delete the matching record.
3. The dangling state. The record keeps resolving to something the client no longer controls: a deleted cloud resource name that can be re-registered (a CNAME takeover), or a released IP address (an A record pointing at reusable address space).

2. The Core Risks

An orphaned staging record is more than housekeeping. It creates several distinct risks, and it helps to separate them.

A. Subdomain Takeover and Brand Impersonation

When a CNAME points to a third-party service and the resource behind it is deleted, the name may become available for anyone to claim. Whoever claims it controls the content served at staging.clientdomain.com, under the client’s real domain.

Not every provider is equally exposed. The OWASP Subdomain Takeover Prevention Cheat Sheet lists Heroku apps as high risk, since any Heroku account can claim a deleted app name, and classes AWS CloudFront as a conditional risk, because adding someone else’s domain as an alternate domain name has not always required proof of ownership. Researchers also maintain public community lists of which services are claimable and what their “not found” error fingerprints look like.

Because the hijacked hostname sits under a trusted parent domain, the consequences go well beyond a defaced page:

• High-credibility phishing and scams. The page really is served from the client’s domain, which helps it past human scrutiny and reputation-based filters.
• Valid HTTPS certificates. The OWASP cheat sheet notes that an attacker who controls a subdomain can obtain a valid TLS certificate for it from certificate authorities that use HTTP-based or email-based domain validation. The padlock then appears, so it no longer works as a warning sign.
• Cookie exposure. MDN notes that a taken-over subdomain can potentially read cookies set from the main domain, run cross-site scripting, or circumvent content security policies. The risk is highest where cookies were scoped to the parent domain (for example .clientdomain.com), because browsers then send them to every subdomain, including the hijacked one. (Cookies flagged HttpOnly can’t be read by page scripts, but they are still sent to the attacker’s server.)
• OAuth and CORS abuse. Redirect-URI allow-lists and cross-origin policies that trust “any subdomain of the company” can turn a hijacked staging hostname into a trusted party in authentication flows.
• Mail risk. The OWASP guidance also flags dangling MX records, which could let an attacker intercept email sent to a subdomain, including password-reset messages.

B. Data and Origin Exposure on Live Staging Servers

Before a staging environment is shut down, it is often a weaker copy of production. Engineers commonly relax controls to speed up debugging, so staging servers can hold hardcoded database credentials, API keys, webhook secrets, verbose error pages, and debug or configuration dumps. If the environment is still running when someone finds it, any of that can leak.

Staging DNS can also expose infrastructure. If staging.clientdomain.com resolves directly to the same origin server that sits behind a CDN for production, it can reveal the origin IP, which makes it easier to bypass CDN protections. This is a configuration risk worth auditing; it is not something that comes from simply reclaiming an IP address.

C. Released IP Addresses: Real, but Harder to Exploit

An A record pointing at a released cloud IP is also dangling. Academic research has shown it can be exploited in principle: one study found over 700,000 domains pointing at free cloud IPs, and researchers have shown it is feasible to repeatedly allocate and release addresses until a target IP is obtained.

The picture from real-world abuse is different, though. A longitudinal study (2020 to 2023) presented at USENIX NSDI 2024 found no IP takeovers among the real-life abuse cases it observed. Attackers instead targeted resources they could claim cheaply by typing in a name, such as an app or bucket name, and avoided the lottery-style assignment of IP addresses. So the sensible takeaway is not “IP reuse is the main danger” but “a dangling IP record is a liability, and a dangling CNAME to a claimable name is the one attackers are actually exploiting.”

D. Shadow IT

Staging subdomains created ad hoc by vendors rarely make it into official asset inventories or vulnerability scanners. Security teams cannot defend assets they do not know exist, which is why a lifecycle gap between agency and client matters more than any single technical control.

3. This Is Happening in the Real World

• Hazy Hawk. In May 2025, Infoblox reported on a threat actor it named Hazy Hawk. The group hijacked subdomains of the U.S. Centers for Disease Control and Prevention through dangling CNAME records pointing to decommissioned cloud resources, and Infoblox linked it to subdomains of organizations including Deloitte, UNICEF, and UC Berkeley. Infoblox says the activity dates to at least 2023, with the CDC case discovered in February 2025. The hijacked domains were used to push scams, malicious redirects, and fake streaming and adult sites through traffic distribution systems, leaning on the parent domains’ credibility and search visibility. Infoblox’s advice to domain owners: remove CNAME records promptly once the underlying cloud resource is retired.
• Abandoned S3 buckets. In 2025, watchTowr Labs re-registered about 150 abandoned S3 bucket names for roughly $420. Over two months those buckets received more than eight million requests, for software updates, executables, VM images, JavaScript files, CloudFormation templates, and VPN configurations, from government, military, and corporate networks. AWS said it blocked the specific bucket names watchTowr reported from being re-created. This case concerns buckets referenced by software rather than DNS, but it shows the same underlying failure: a deleted resource whose name anyone can reclaim.
• Automation at scale. In 2026, Silent Push published its “Danglegeddon” research, a simulation across government, banking, automotive, and pharmaceutical sectors. Working across 12,500 apex domains, it identified 16,000 dangling subdomains and automated takeover of 4,000 of them. Treat it as vendor research from a simulation rather than an incident report, but it illustrates how quickly scripted discovery and takeover can work.

4. How Attackers Find Orphaned Subdomains

Attackers do not guess staging hostnames one by one. They use automated reconnaissance, usually in three phases.

Phase 1: Certificate Transparency Logs and Passive Data

Publicly trusted certificate authorities log the certificates they issue to public Certificate Transparency logs, and search tools such as crt.sh let anyone query them by domain. A certificate issued for staging.clientdomain.com, even for a short-lived project, can therefore surface that hostname years later:

# Example: list hostnames seen in CT logs for a domain you own
curl -s "https://crt.sh/?q=%25.clientdomain.com&output=json" | jq -r '.[].name_value' | sort -u

Two limits are worth knowing. Wildcard certificates (*.clientdomain.com) reveal the wildcard but not the individual hostnames behind it, and certificates from private CAs are not publicly logged. CT logs are one source among several, alongside passive DNS history, search engines, and archives. Researchers believe Hazy Hawk likely had access to historical passive DNS data, since finding vulnerable dangling CNAMEs is hard without it.

Phase 2: Wordlists and Permutation

To catch hostnames that never had a public certificate, attackers run DNS enumeration tools such as OWASP Amass, Subfinder, or Gobuster’s DNS mode against wordlists built around development naming patterns:

• staging, stage, dev, test, uat, qa, sandbox, demo, preview, temp
• Variations with project or client names (dev-v2, client-preview)

Phase 3: Resolution and Fingerprinting

Next they resolve the list and look for takeover signals:

1. A CNAME to an unregistered or non-existent target. If the target domain isn’t registered at all, the dangling CNAME can be exploited by simply registering it.
2. A CNAME to a claimable provider, with a “not found” response. Common fingerprints include NoSuchBucket for S3 and “No such app” for Heroku. Community-maintained lists such as “Can I take over XYZ?” track which services are claimable and how to recognize them.
3. An A record pointing at address space no longer in use. This is the lower-probability case described in section 2C.

NS records deserve special mention: a dangling NS delegation is worse than a dangling CNAME, because whoever claims it controls DNS resolution for the entire delegated subzone.

5. Proactive Defense

1. Fix the Order of Operations

The most effective control is procedural. MDN’s guidance is to start deprovisioning by removing DNS records first, and to start provisioning by claiming the resource first and creating DNS records last.

• Delete DNS before deleting the resource. Remove the CNAME or A record from Route 53, Cloudflare, Azure DNS, or wherever the zone lives before destroying the app, bucket, or VM.
• Create DNS last. Only add the record once the resource exists and is yours.
• Do both steps close together, and have one named person accountable for the zone.

2. Make DNS Cleanup Part of Vendor Offboarding

The root cause is organizational. Add these steps to agency offboarding checklists and contract exit terms:

• A written inventory of every hostname the vendor created or asked you to create under your domains, including their third-party hosting targets.
• A requirement that the vendor confirm in writing when each underlying resource is retired.
• A zone audit at the end of every engagement, checking for records that point at vendor-managed names or addresses.

3. Use the Provider-Side Protections That Actually Exist

Several providers now offer real defenses, but their coverage differs, so check each one rather than assuming.

• Amazon S3. Historically, a deleted bucket’s name could be re-registered by anyone. In March 2026, AWS introduced account regional namespaces for general-purpose buckets, whose names follow the pattern <prefix>-<account-id>-<region>-an. According to AWS, no other account can ever create a bucket name in your namespace, even after you delete a bucket. The protection applies only to buckets created in that namespace; existing global-namespace buckets can’t be renamed into it. AWS also provides an IAM and service control policy condition key (s3:x-amz-bucket-namespace) so organizations can require the new naming.
• Azure App Service. Microsoft recommends creating an asuid.<subdomain> TXT record containing your domain verification ID when you map a custom domain, and using “secure unique default hostnames” for new apps, which it says prevents anyone outside your organization from creating a resource with the same default hostname. Microsoft Defender for App Service includes dangling DNS detection, and Azure DNS alias records can tie a record’s lifecycle to the resource it points at.
• GitHub Pages. Verifying your custom domain with a TXT record stops other users from publishing a Pages site to that domain or its immediate subdomains. GitHub notes that takeovers can happen when a repository is deleted, a billing plan is downgraded, or Pages is otherwise disabled while the domain is unverified, and that the TXT record must stay in DNS to keep the domain verified.
• AWS CloudFront. AWS has added checks that block another account from claiming a domain still pointing at a CloudFront distribution when an alternate domain is removed, but the best fix remains removing the DNS record first.

4. Run Continuous Discovery, Not Annual Audits

A static spreadsheet will be out of date the week after you build it.

• Schedule regular enumeration of your own domains with open-source tools such as OWASP Amass and Subfinder, and compare the results against your DNS zones.
• Monitor Certificate Transparency logs for your domains, so new or unexpected hostnames are noticed quickly.
• Write a simple check that flags any CNAME whose target no longer resolves, any record matching a known takeover-prone provider that returns a “not found” error, and any A record pointing at an address you can’t account for.
• Consider commercial external attack surface management (EASM) platforms such as Censys or SecurityScorecard, or dedicated dangling-DNS tooling, if your estate is large. Evaluate what each product actually detects and validates.

5. Limit the Blast Radius

Assume that one forgotten subdomain will eventually be compromised, and make sure that does not reach production.

• Scope cookies narrowly. Avoid setting cookies on the parent domain (.clientdomain.com) when a host-only cookie on the exact application host will do. Use the Secure and HttpOnly flags and the __Host- cookie prefix where possible.
• Tighten trust lists. Audit CORS allow-lists, OAuth redirect URIs, and CSP rules for wildcard trust of *.clientdomain.com, and list only the exact hosts that need access.
• Keep staging apart from production. Use separate credentials, separate databases with scrubbed data, and separate OAuth clients for staging, and don’t point staging DNS at the same origin that serves production.
• Consider a separate domain for non-production. Hosting staging on a dedicated domain keeps a compromised preview hostname out of your production domain’s trust boundary.

Conclusion

Orphaned staging subdomains are a long-standing, well-documented weakness that attackers have turned into a repeatable, scalable technique. The reliable fix is not exotic. Treat DNS records as assets with owners and end dates, delete DNS before the resource behind it, build record cleanup into every vendor exit, use the verification features your cloud and hosting providers offer, and keep scanning your own domains the way an attacker would.

---

Originally published at https://instarenewal.com/blog/the-orphaned-staging-server-vulnerability-tracking-expired-dev-subdomains