A subdomain takeover happens when a DNS record — typically a CNAME — still points a subdomain (like app.yourcompany.com) at a third-party service (GitHub Pages, Heroku, an S3 bucket, Netlify, and similar), but the corresponding resource on that service was deleted or never claimed. Anyone can then register that same resource on the third-party service and have it start serving content on your subdomain, under your domain name, with your DNS still pointing at it.
Why this happens with AI-built projects specifically
It's common to spin up a subdomain pointed at a hosted preview, docs site, or staging environment while iterating on a project — then abandon that service (switch hosts, delete the project, stop paying for it) without ever removing the DNS record that pointed at it. The subdomain still resolves; it's just now pointing at a resource that doesn't belong to anyone. On many platforms, someone else can then create a resource with the exact identifier your abandoned DNS record still references, and your subdomain starts serving their content.
Why it's dangerous beyond defacement
A taken-over subdomain still shows your real domain name in the browser's address bar and often still qualifies for a valid HTTPS certificate, so it can be used to host convincing phishing pages, steal cookies scoped to your parent domain, or receive OAuth redirect callbacks meant for your real app — all while looking, to a user or to automated trust checks, like it belongs to you.
How to fix or prevent it
Remove the DNS record entirely for any subdomain pointing at a service you no longer use. If you're actively using the service, make sure the corresponding resource (the S3 bucket, the Heroku app, the GitHub Pages repo) still exists and is claimed under your account — the vulnerability is specifically the gap between "DNS still points here" and "resource still exists."
Frequently asked
Does subdomain takeover require the attacker to compromise my DNS?
No — that's what makes it dangerous. Your DNS is untouched and still "correct" in the sense that it points where it always did. The vulnerability is entirely on the third-party service side: the destination resource no longer exists or was never claimed, and someone else claims it instead.