What Is a Subdomain Takeover?

Quick answer
A subdomain takeover happens when a DNS record points at a service that no longer exists, and an attacker claims it.
The classic case: a CNAME to a deleted GitHub Pages site or cloud app that someone else can now register.
It matters because the attacker then controls a page on your domain — perfect for phishing and credential theft.

How does a subdomain takeover work?

It starts with a dangling DNS record: a CNAME or A record pointing to a service that’s been deactivated — a deleted GitHub Pages site, an expired cloud app, a removed S3 bucket. The domain still resolves to the provider, but nothing owns it. Attackers scan for these patterns, register the abandoned resource themselves, and now serve arbitrary content at your-subdomain.example.com. Visitors see your domain in the URL bar, so the page looks official, and the attacker can host phishing pages or steal cookies scoped to your domain.

Why is it dangerous even though the subdomain is unused?

Two reasons. First, browsers and users trust the domain: a login page at login.example.com is indistinguishable from the real thing. Second, cookies set by the attacker’s page are scoped to the whole domain, so they can steal session cookies for your main site. Even a subdomain you consider dead is on your domain, and anything on your domain is a security surface.

How do I prevent and detect it?

Remove DNS records when you deactivate services — the only true fix. Then add detection: a monitoring tool that periodically checks every DNS record and flags dangling ones (DNS records pointing at providers that no longer serve them). Free tools like Detectify and webhooks from can-i-take-over-xyz checklists cover the known provider patterns. Also standardize: keep a DNS inventory, and require a ticket or task to create and delete records so nothing dangles silently.

# Find dangling CNAMEs: does the target resolve?\ndig +short CNAME old-app.example.com\n# pages.github.com   <- points at GitHub Pages; is the repo still there?\n\n# If the target no longer resolves to an owned resource, delete the record.

Where this bites vibecoders
The AI-generated app gets deployed to a preview environment or a temporary cloud service, the project moves on, and the DNS record stays. Vibecoders churn through services fast — a demo on Vercel, a staging on Fly — and nothing cleans up after them. The dangling record becomes a free phishing page on their domain, discovered by users, not by them. A cleanup habit (delete records with deactivated services) plus a periodic dangling-record check closes it.

Where AI coding assistants get this wrong

Creating DNS records for temporary services and never generating the cleanup step.
Pointing CNAMEs at services without documenting who owns the target.
No DNS inventory, so deactivated services leave silent records behind.
Checking for takeover only during pentests instead of continuously.

Checklist

Delete DNS records the moment the service they point to is deactivated.
Keep a DNS inventory and make record creation/deletion explicit.
Run a periodic scan for dangling records using provider fingerprint lists.
Monitor your DNS zone for unauthorized new records.

FAQ

How do attackers find dangling DNS records?

They automate it: take lists of subdomains, resolve each one’s CNAME, and compare the target against known provider fingerprints (GitHub Pages, S3, Heroku, Azure). When a target is claimable, they register it. The scan is cheap and continuous, which is why abandoned subdomains get claimed fast.

Can I fix a takeover after it happens?

Yes: delete the dangling record or re-register the service yourself so the domain points at something you own. Then check for scope of damage — whether the attacker could read cookies, and whether search engines have cached the attacker’s pages. The fix is quick; the reputation damage is the part that lingers.