Dangling CNAME to a deleted S3 bucket let a researcher take over Bime's subdomain

How a deleted bucket became someone else's asset

In 2016, a security researcher noticed that a2.bime.io, a subdomain belonging to Bime, had a CNAME record pointing at bimeio.s3.amazonaws.com. The bucket named bimeio did not exist at the other end of that record. It was owned neither by Bime nor by anyone else. The researcher created the bucket in their own AWS account, and from that point the subdomain served their content on Bime's domain, presented with the company's SSL certificate to users who trusted it. The finding was filed as HackerOne report 121461, and according to a dev.to write-up revisiting the case, the gap between the bucket's deletion and the researcher's claim lasted days.

The mechanics behind it are simple. S3 bucket names are unique across all of AWS, and once a bucket is deleted its name becomes available to any account immediately. If a DNS record still points at the now-vacant S3 endpoint, the first person to register the name controls what that hostname serves.

Three commands and no exploit

The dev.to piece reproduces the attack with nothing but standard tooling: a DNS lookup exposes the CNAME, an aws s3 ls call returns NoSuchBucket, and a single aws s3 mb claims the name. No credentials, no exploit code, no social engineering. The subdomain then serves the attacker's content until the owner notices — which, in the Bime case, was long after the name had been sitting unclaimed.

The blind spot between two inventories

According to the write-up, conventional tooling has no view of this configuration. Cloud security posture management products inventory the buckets inside an organization's AWS accounts; a deleted bucket simply drops out of that inventory, leaving nothing to scan. Meanwhile the CNAME lives in Route 53, Cloudflare, or a registrar's control panel — outside AWS resource models, absent from AWS Config and Security Hub, and invisible to CSPM findings. The NoSuchBucket response the hostname returns is itself a valid HTTP response, so monitoring reads it as an outage rather than a vulnerability. The mismatch falls squarely between the AWS account, which no longer has a bucket, and the DNS zone, which still has a record, and few organizations run anything that cross-references the two.

The gap typically opens through ordinary workflow. A team ships a feature backed by S3, adds the CNAME, and later deprecates the feature. Deleting the bucket happens in the AWS console; removing the record happens in a separate system, often owned by a separate team, and nothing in the deployment blocks on it. The cleanup task gets forgotten, and months later nobody remembers the subdomain exists.

Treat the reference as the asset

The write-up distills the rule into an invariant: every DNS CNAME pointing at an S3 endpoint must reference a bucket that exists and is owned by the same organization. It is verifiable from a snapshot without touching production — the record points at bimeio.s3.amazonaws.com, the bucket is absent from the account inventory, the name is claimable — and that observation alone is the finding.

The article then shows how a tool called Stave applies that idea by modelling the DNS-to-S3 link as a first-class asset, with properties recording whether the referenced bucket exists and who owns it. A control fires when either check fails, and one of the project's end-to-end tests reconstructs the exact Bime configuration across two snapshots spanning eight days. The broader point holds regardless of tooling: the vulnerability lives in the reference rather than the bucket, which is precisely why bucket-level scanners find nothing to evaluate.

Remediation measured in seconds

Fixing the exposure takes under a minute, per the write-up. One option is to reclaim the bucket name — an empty bucket with all public access blocked is enough to deny the namespace to anyone else, and it avoids waiting on DNS propagation. The other is to delete the CNAME outright, which the author recommends doing regardless, since a subdomain pointing at an empty bucket should not exist at all. The durable process fix is one of ordering: search DNS records for references to a bucket's name and remove them before deleting the bucket, then periodically audit zones for CNAMEs targeting *.s3.amazonaws.com and confirm each referenced bucket exists and belongs to the organization.

Why it matters

The Bime report dates from 2016, but nothing about the mechanics has changed: S3 names are still globally unique, deletion still releases them instantly, and DNS cleanup still lives in a different system from resource deletion. Any organization that has ever deleted a bucket — or any cloud resource a hostname pointed at — can carry the same latent exposure today. The blast radius is not a stray 404; an attacker controls a live hostname inside the company's domain, reached over a certificate users already trust. Detection is cheap once you correlate DNS records with cloud inventory, and remediation costs less time than it takes to read the original report.