In September, a government agency's website address started serving pages its owners had never seen. First a copy of the agency's own homepage, built by someone else. Later, fake sports-streaming pages and adult spam, which Google indexed under the agency's name. The real website was fine the whole time. Nobody broke into it, guessed a password or changed a file. The stranger never touched the site at all. They took its www address instead, which nobody had claimed.
This is what happened, why it was possible, what we changed so it can't happen again on sites we host, and how to check your own domains in about ten minutes. The agency isn't named, and neither is the platform involved. The gap has been fixed there, and the same class of problem exists on many platforms, so naming one would only suggest the rest are safe.
The setup that made it possible
Modern hosting platforms rarely give each website its own IP address. They put a large shared network in front of every customer, and when a visitor arrives, the network looks at the hostname the browser asked for and routes the request to whichever customer's site claims that name. The IP address a customer is told to point their DNS at belongs to the platform, not to them.
That design is fast and cheap to run, and it creates a specific weakness. The platform only knows where to send www.example.gov if some site in some account has claimed it. If DNS points the name at the edge and no site claims it, the name is up for grabs, and the next customer who types it into their own dashboard gets it.
When the agency connected its domain to its new hosting in early September, the bare domain was attached and www was not. Their DNS provider still had a www record pointing at the bare domain, which in turn pointed at the shared edge. So for visitors, www landed on the platform and found no owner. It simply didn't load, and nobody noticed for a while, because everyone types the bare domain.
How someone claimed it
Claiming the name took no proof of ownership. The platform's quick domain setup checked that the hostname reached its edge over HTTP, and of course it did: the agency's own DNS sent it there.
The certificate followed automatically. Let's Encrypt, like other certificate authorities, can validate a domain over HTTP by fetching a token from /.well-known/acme-challenge/ on that hostname. The shared edge answers that path for any hostname pointed at it, on behalf of whichever account claimed the name. The DNS record that the agency had left in place was, in effect, the proof of control. No TXT record was required, and a CAA record wouldn't have helped either, because the agency used the same certificate authority.
So the stranger got a working, trusted HTTPS site at the agency's www address, with a padlock in the browser.
What visitors saw
We reconstructed the timeline afterwards from public records, because the stranger's account wasn't ours to inspect:
- Certificate Transparency logs list every publicly trusted certificate. They showed four certificate pairs for the agency's www address issued to someone else, the first on September 11, two days after the domain was connected, and the last on September 25.
- The Wayback Machine had captured the www address on September 12. It showed a WordPress clone of the agency's homepage, built in a different install, with no forms and no scripts that collected anything.
- The agency's own server logs, once www was back under its control, showed visitors still arriving for 187 spam URLs under www: fake streaming pages, sports piracy and adult content. Hundreds of those visits came from Google search results, which means the spam had been crawled and indexed under the agency's name.
On September 25 the agency's IT staff spotted the problem and opened a ticket with us.
The night it was found
When we tried to attach the www name to the agency's site, the platform refused: the hostname was already in use. That refusal was the proof that another account held it.
The containment steps, in the order they happened:
- The agency deleted the www DNS record. With no record, visitors' browsers stopped reaching the stranger's site immediately. It's the one step that doesn't depend on anyone else.
- We filed an urgent ticket with the platform with the hostname, the certificate times from the CT logs, and the exact refusal. They removed the name from the other account within a couple of hours and checked for other names under the agency's domain on unauthorized accounts. They found none.
- We attached www to the agency's site by its exact name, and the agency restored its DNS record. www now redirects to the bare domain on the agency's own certificate.
- We checked the real site properly before saying anything about it: file checksums, administrator accounts, the site address settings and the server's own logs across the whole window. Requests to the stranger's www never reached the agency's container, because the two sites ran in separate accounts.
Only then did we tell the agency that we'd found no indication its site had been accessed. The platform deployed a fix for the claiming gap the next morning.
What the timeline taught us
Our first estimate of when this started was wrong, twice over. We first read the earliest certificate we had found as the start, and a Let's Encrypt certificate's "not before" date is backdated by an hour, so the time was off as well. The full Certificate Transparency search and the Wayback capture moved the start back two weeks. If you're ever reconstructing one of these, check CT logs and archive captures before you tell anyone when an exposure began.
What we changed
Our own monitoring didn't watch www, and that part was ours to fix. Since September 26:
- Every attached hostname is checked against its sibling. Every six hours, for every domain on every site we host, we probe the www or bare-domain counterpart. If it reaches the platform's edge and the site doesn't list it, we attach it to the right site on the spot.
- "Already in use" is treated as an incident. If the platform refuses because another account holds the name, the site gets a critical alert and we follow the playbook above, starting with the DNS record.
- Connecting a domain without www is refused when www already points at the site. Leaving www off is fine when it truly isn't in DNS. It isn't fine when the record is already sending visitors to the edge.
The first run of the new check was noisy. It flagged dozens of names that were in fact covered by wildcard entries, which the platform's domain list reported differently. We now judge every suspect name against the platform's live domain list, and attach by exact name anything not explicitly covered, because an exact claim in another account outranks a wildcard in yours.
Check your own domains in ten minutes
You don't need to host with us to do any of this.
- List every DNS record. Export your zone from your DNS provider. If the record types are new to you, our DNS basics for site owners explains them. For each CNAME and A record, write down where it points.
- Match each record to something you control. For every hostname pointing at a hosting platform, site builder, storefront, help desk or landing-page tool, log into that service and confirm the exact name (www included) is attached to your account. If you can't find an account that owns it, delete the record.
- Remove what's retired. Records for old hosts, old mail or chat systems and abandoned SaaS trials are the usual culprits. On the agency's zone, the same audit found an FTP record still pointing at a previous shared host and records for a retired chat system.
- Watch Certificate Transparency. Search your domain at crt.sh or Cert Spotter. Every certificate for your names should be one you or your providers asked for. Both offer free alerts for new certificates, which would have caught this on September 11. Our SSL and HTTPS guide covers how certificates are issued.
- Search your own site in Google.
site:www.yourdomain.comandsite:yourdomain.comshow what Google thinks lives there. Spam URLs under your name are worth knowing about early, and our guide to recovering from SEO spam covers getting them out of the index.
If you find a name someone else holds, delete the DNS record first, then contact the platform with the hostname and the certificate history from the CT logs.
Why this happens to careful organizations
Nobody here did anything reckless. The checkbox that would have attached www was presented as a convenience, and nobody knew what leaving it off would mean. The platform accepted a government hostname without any proof of ownership beyond DNS. And the monitoring, ours included, watched the domain people typed, not its sibling. Every part was reasonable on its own. Together they left a door open.
That's the argument for a host that treats domains as part of security rather than setup. At TopSyde, every domain on every site we host is now checked this way, around the clock, as part of managed WordPress hosting, and our SLA and pricing are public. If you'd like a second pair of eyes on your site's security, start with our free malware scanner, or read what else we look for in WordPress security best practices.
Frequently asked questions
What is a subdomain or hostname takeover?
It's when someone else gains control of what loads at one of your hostnames, usually because a DNS record still points at a platform where nobody (or no longer you) has claimed that name. The attacker claims it in their own account and serves whatever they like, often with a valid HTTPS certificate.
Was the agency's website hacked?
No. The real site, its files, its administrator accounts and its data were never accessed. The stranger served pages from a separate site in a separate account. The weakness was a DNS record pointing at a shared platform where the www name was unclaimed.
How did they get an HTTPS certificate for a domain they didn't own?
Certificate authorities like Let's Encrypt can validate a domain by fetching a token over HTTP from the hostname itself. Because the agency's DNS sent the www name to the shared platform, and the platform answered for whichever account claimed the name, the stranger passed that check without any DNS access.
Would a CAA record have prevented it?
Not in this case. A CAA record limits which certificate authorities may issue for your domain, and the agency already used the same one the stranger did. CAA helps if you use a less common authority, but deleting or claiming the dangling record is the fix that works.
How do I check whether my domain is exposed?
Export your DNS records, confirm every hostname pointing at a third-party platform is attached to an account you control, delete anything you can't account for, and search Certificate Transparency logs at crt.sh for certificates you didn't request. Setting up a free CT alert covers you going forward.
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
