Subdomain Takeover: The Quiet Risk Hiding in Your Wix, Shopify, or GitHub Setup

If you built your business website on Shopify, Wix, Squarespace, or GitHub Pages - and you ever pointed a custom subdomain at one of those platforms - there is a category of vulnerability that most small business owners have never heard of, and that rarely shows up in basic security scans.

It is called subdomain takeover. It does not require a sophisticated attacker. It does not require your password to be weak. It just requires that you cancelled a service, migrated a site, or cleaned up an old project and forgot to remove a DNS record.

What Is a Subdomain Takeover?

Every custom subdomain you configure - shop.yourbusiness.com, blog.yourbusiness.com, staging.yourbusiness.com - works by pointing a DNS record at an external service. When you set up a Shopify store on a subdomain, you create a CNAME record that says "send traffic here to Shopify's servers." Shopify then serves your store when someone visits that address.

The problem happens when the relationship between your DNS and that external service is severed - but the DNS record is not removed.

If you close your Shopify store but leave the CNAME pointing at shops.myshopify.com, that subdomain now resolves to a Shopify page that belongs to nobody. On some platforms, any Shopify user can claim that address by registering a store with a matching name. The same pattern applies to:

• Wix - subdomains pointed at username.wixsite.com after an account is deleted or migrated
• Squarespace - abandoned trial or expired sites where the CNAME still resolves to a Squarespace origin
• GitHub Pages - a CNAME pointed at username.github.io where the repository has been renamed, deleted, or made private
• Netlify, Vercel, and similar hosting platforms - the same DNS-dangling pattern applies broadly

An attacker who claims that unclaimed resource can now publish content under your subdomain. To a visitor's browser - and to many email spam filters - that content appears to come from your domain.

Why This Matters for Small Businesses Specifically

Larger organizations have DNS audits, asset inventory processes, and sometimes dedicated security teams watching for exactly this pattern. Small businesses generally do not.

You might have launched a blog on a subdomain three years ago, moved to a newsletter platform, and completely forgotten the CNAME still exists. Your IT person - if you have one - may not have a list of every subdomain that was ever created. Most domain registrar dashboards do not alert you when a CNAME target goes unclaimed.

The consequences of a successful subdomain takeover can include:

• Phishing pages served under your brand domain, used to collect credentials from your customers or employees
• SEO damage if the attacker publishes content that violates search engine guidelines under your subdomain
• Email spoofing risk in some configurations, depending on how your SPF and DKIM records are scoped
• Reputation damage that is hard to trace back to the root cause, because the attack surface was a forgotten DNS record, not a compromised account

The DNS Sprawl Problem

The typical SMB does not start with a complicated DNS setup. But over time, it accumulates one. You add a marketing subdomain for a campaign. You set up a staging environment. You pilot a new e-commerce platform. You integrate a third-party landing page builder.

Each of those integrations usually involves a DNS change. Few of them involve a process for removing that DNS change when the integration ends.

This is what security teams call "shadow infrastructure" - assets that exist, that are reachable from the internet, that have your name on them, but that nobody on your team is actively watching.

What You Can Do About It

Audit your DNS records regularly. Export your full DNS zone from your registrar or DNS provider and check every CNAME and A record against services you are currently using. If a CNAME target returns a 404 or an unclaimed-account page, that record should be removed immediately.

Document integrations when you make them. When you point a subdomain at a SaaS platform, record it somewhere - a spreadsheet, a ticket, a note in your DNS provider's interface. When you offboard from that platform, the cleanup step should include removing the DNS record before you close the account.

Check before you cancel. Before migrating away from any hosted service, verify that removing your content from their platform will not leave a dangling DNS record pointing at an unclaimed resource.

Monitor continuously, not just at setup. A one-time audit finds what exists today. The problem is that DNS records accumulate over time, and the service you cancelled last month may have only become a risk this week when someone else claimed the underlying resource.

This is where external attack surface monitoring becomes practical for teams without a dedicated security function. A tool that continuously maps your exposed assets from the outside - looking at DNS, open ports, SSL certificates, and security headers from your domain outward - can surface these dangling records as they become exploitable, not months after the fact.

Connecting This to Your Broader Attack Surface

Subdomain takeover is one category within a wider class of problems that fall under external attack surface management (EASM). The common thread is that these risks exist on infrastructure that is internet-facing, associated with your organization, and often outside the visibility of any internal checklist.

Safe Intelligence scans your attack surface continuously from a single verified domain - no agents, no software to install. It maps exposed assets including DNS, open ports, SSL certificates, and security headers, and flags shadow infrastructure that accumulates without teams realizing it. For SMBs running on common SaaS stacks, that includes exactly the kind of dangling DNS exposure described here.

If you want to see what your domain currently exposes, visit safeintel.io to learn more or connect with a partner who can walk you through your results.

Safe Intelligence by Apona | safeintel.io

Published 2 July 2026

This post is about Safe Intelligence.