Dangling Records
AWS S3 Bucket Subdomain Takeover
A CNAME to a deleted S3 bucket is dangerous: if someone recreates that bucket name in the same region, your subdomain can instantly start serving their files.
How it happens
- You create a subdomain pointing to
bucket-name.s3.amazonaws.com. - You delete the S3 bucket.
- The CNAME stays in DNS.
- An attacker creates the same bucket name in the same region.
- Your subdomain serves their files.
The fingerprint
Deleted bucket targets return NoSuchBucket. If your DNS still points there, that record is often claimable.
Why S3 is particularly dangerous
S3 bucket names are globally unique per region. An attacker who finds your bucket name in a dangling CNAME can create it in the same region quickly and hijack that hostname.
How to check
Run DomainPreflight Dangling Records to detect CNAMEs pointing at S3 endpoints and match the NoSuchBucket fingerprint.
How to fix
Delete the dangling CNAME right away. If the hostname is still needed, recreate and lock down the bucket first.
Fix it step by step
*.s3.amazonaws.com.Scan your domain for dangling provider records
Open Dangling Records Scanner →FAQ
What is an AWS S3 subdomain takeover?
When a CNAME points to a deleted S3 bucket, anyone can recreate that bucket name in the same region and serve content on your subdomain.
How do I know if my subdomain is vulnerable?
Run DomainPreflight Dangling Records. It checks CNAME targets and known fingerprints including S3.
What does the S3 takeover page look like?
Look for NoSuchBucket. If your subdomain resolves to that, the CNAME is likely dangling and claimable.
How do I fix a dangling S3 CNAME?
Delete the DNS CNAME. If you need the subdomain, recreate the S3 bucket first.
Can I prevent this from happening again?
Always delete DNS records when decommissioning services. Run Dangling Records scans quarterly.