Forgotten WordPress subdomains are one of the most common entry points for subdomain takeover attacks, yet they rarely show up on any security team’s radar. This article walks through how forgotten WordPress installations on subdomains create real DNS security risks, what the attack chain actually looks like, and what steps organizations can take to find and neutralize these stale configurations before someone else does.
When a WordPress site spins up on a subdomain – blog.example.com, news.example.com, dev.example.com – a CNAME or A record gets added to DNS pointing to the hosting environment. That record often outlives the site itself by months or years. The WordPress installation gets deleted, the hosting account lapses, the server gets decommissioned. But nobody goes back to clean up the DNS entry. That dangling record is now a liability.
What Actually Happens to Forgotten WordPress Subdomains
Most organizations have more active DNS records than they realize. A marketing team spins up a campaign blog on a subdomain, the campaign ends, and the CMS gets removed. The subdomain entry stays in DNS because nobody owns the cleanup task explicitly – it sits between IT and marketing, and both assume the other handled it.
The problem compounds over time. A subdomain pointing to a WordPress hosting plan that has since expired or been cancelled is no longer resolving to content the organization controls. Depending on the hosting provider, that IP address or CNAME target may become available for re-registration. An attacker who notices the dangling record can claim the underlying resource and effectively take control of the subdomain.
The risks here go well beyond cosmetic defacement. An attacker serving content from blog.yourcorp.com inherits a degree of brand trust. Visitors see your domain in the address bar. Phishing pages, malware distribution, or credential harvesting pages hosted there are far more convincing than anything on an unknown domain.
The WordPress-Specific Attack Surface
WordPress subdomains create a particularly rich attack surface for several reasons. First, WordPress is the most widely hosted CMS on shared and managed hosting platforms – which means the underlying infrastructure has well-known characteristics that attackers understand deeply.
Second, many organizations host WordPress on platforms like WP Engine, Kinsta, Flywheel, or even generic cPanel-based shared hosts. These platforms assign predictable CNAME targets during provisioning. If a hosting account lapses and the CNAME target becomes available again on that platform, claiming it is often as simple as creating a free trial account and registering the same hostname.
Third, WordPress installations often carry their own authentication surfaces – wp-login.php, XML-RPC endpoints, REST API routes. Even a barebones WordPress takeover gives an attacker authenticated endpoints to probe, paths to inject scripts, and a platform that browsers trust because of the parent domain.
A Realistic Scenario Security Teams Will Recognize
Consider a mid-sized SaaS company that ran a developer blog on dev-blog.example.com for two years. The blog was hosted on a managed WordPress platform and mapped with a CNAME record pointing to the provider’s infrastructure. The company switched to a documentation platform, cancelled the WordPress hosting, and redirected the main blog content. Nobody filed a ticket to remove the CNAME.
Eight months later, a security researcher – or an attacker – runs passive DNS enumeration against the domain. They find dev-blog.example.com still resolving, but the CNAME target is now pointing to an unclaimed slot on the hosting provider. Within an afternoon, the subdomain is serving a cloned login page. The company’s own subdomain is now being used in a credential phishing campaign targeting their users, who have no reason to distrust a URL under the company’s own domain.
This scenario plays out regularly. The root cause is almost always a dangling CNAME that was never removed when the underlying service was decommissioned.
Busting the “We’d Notice” Myth
A common assumption is that if a subdomain got taken over, someone would notice quickly – a customer would report it, an uptime monitor would catch it, internal testing would flag it. This is almost never true for forgotten subdomains.
Uptime monitors only watch what they’ve been told to watch. A subdomain that was decommissioned 14 months ago isn’t in anyone’s monitoring list. DNS health checks that run against a defined inventory miss it for the same reason. The subdomain resolves fine – it just resolves to something the organization no longer controls. Standard infrastructure monitoring sees a working DNS record and reports no issues.
The only reliable way to catch this class of problem is continuous subdomain discovery – finding subdomains that exist in DNS regardless of whether they appear in any internal documentation or monitoring config.
How to Find and Eliminate These Risks
The remediation process follows a clear sequence:
1. Enumerate all subdomains. Don’t rely on internal records. Use passive DNS data, certificate transparency logs, and active DNS brute-forcing to build a complete picture of what subdomains exist under your domain. Expect to find subdomains that nobody on the current team created.
2. Identify CNAME chains pointing to external platforms. For every subdomain, trace where the DNS record resolves. CNAME records pointing to WordPress hosting providers, cloud platforms, or CDN endpoints need to be verified against current active accounts.
3. Check for unclaimed targets. If a CNAME target resolves but the hosting account it maps to is no longer active, that’s a critical finding. Treat it as a confirmed risk, not a theoretical one.
4. Remove stale records immediately. If a subdomain is no longer serving content the organization controls, delete the DNS record. There’s no safe way to leave a dangling CNAME in place while investigating – remove it first, investigate second.
5. Establish a decommissioning process. DNS cleanup should be a mandatory step in any project, campaign, or product wind-down checklist. The record that created the subdomain needs to be removed at the same time as the underlying service.
SPF, DKIM, and the Email Angle
Forgotten WordPress subdomains sometimes carry their own email configuration – SPF and DKIM records added when the blog was set up to handle contact forms or comment notifications. If those records are still present but the subdomain is now abandoned, an attacker who takes over the subdomain may be able to send email that appears to originate from a trusted subdomain of your organization.
Missing or misconfigured SPF and DKIM records on subdomains are worth auditing as part of the same cleanup pass. A subdomain that no longer needs to send email should have explicit SPF records denying all senders, or the subdomain DNS records should be removed entirely.
FAQ: Forgotten WordPress Subdomains and DNS Security
How long does it typically take for a forgotten subdomain to be exploited?
It varies, but subdomain takeover attempts are often automated. Scanners continuously monitor certificate transparency logs and passive DNS data for dangling CNAME records. In documented cases, exploitation has occurred within days of a hosting account lapsing. Waiting to clean up DNS records after decommissioning a service is not a safe approach.
Does deleting the WordPress site remove the DNS risk?
No – and this is one of the most common mistakes. Deleting the WordPress installation, cancelling the hosting plan, or even closing the hosting account does not remove the DNS record. The CNAME or A record that maps the subdomain to that hosting environment remains active in DNS until someone explicitly deletes it from the DNS zone. The DNS record and the hosted content are managed in completely separate systems.
Are subdomains on dedicated servers safer than those on shared hosting?
Somewhat, but not categorically. Dedicated server subdomains using A records are less susceptible to classic CNAME-based takeovers, but if the IP address is released and re-assigned, the same risk applies. The more important variable is whether the DNS record is still active after the server or service has been decommissioned – that’s the condition that creates the vulnerability, regardless of hosting type.
Closing: The Cleanup That Never Gets Scheduled
Forgotten WordPress subdomains don’t announce themselves. They sit quietly in DNS, pointing to infrastructure that no longer belongs to the organization, waiting for someone to notice before an attacker does.
The practical lesson is straightforward: DNS records should be treated as configuration artifacts with a lifecycle tied directly to the services they support. When the service ends, the record ends. Building that discipline into project and campaign workflows eliminates the entire category of risk discussed here. Until that process is in place, regular subdomain enumeration and DNS health monitoring is the only reliable way to catch what’s already been forgotten.