Delete a Bucket, Steal the Data: Cross-Cloud Namespace Risk

Palo Alto Networks’ Unit 42 and the Cloud Security Alliance both published research this year on the same underlying flaw, from different angles: cloud storage bucket names live in a namespace that’s globally unique but not permanently owned. Delete a bucket and its name goes back in the pool, up for grabs by any account on that provider — including an attacker’s (Unit 42, Cloud Security Alliance). Nothing about that is new — bucket squatting has been a known nuisance for years — but the research reframes it as a systemic exfiltration technique against live, unattended data pipelines, not just an opportunistic grab of an abandoned name.

Root cause

The precondition is narrower than “attacker finds a deleted bucket”: in the active-hijacking variant, the attacker needs an identity inside the target’s own cloud account with bucket-deletion permission — s3:DeleteBucket, storage.buckets.delete, or the Azure equivalent. That permission shows up far more often than it should, bundled into broad “storage admin” roles that were never scoped down to the narrower set of actions a human or pipeline actually needs. From there the attack is almost boring: delete the bucket that a CloudTrail trail, a Cloud Logging sink, a Data Firehose stream, or a cross-account replication job writes to, then immediately recreate a bucket with the identical name under the attacker’s own account. The upstream configuration doesn’t change — it still points at a bucket that exists and accepts writes — so there’s no error, no failed-delivery alert, nothing that distinguishes “still working” from “now working for someone else.” Logs, telemetry, and replicated objects keep flowing, just to the wrong owner.

A second, more startling variant needs no privileged access at all. WatchTowr researchers registered around 150 bucket names abandoned by real commercial and open-source software, government agencies, and CI/CD pipelines — for roughly $400 total — and logged over 8 million requests in two months: software update checks, precompiled binaries, VM images, CloudFormation templates, even SSL VPN configs, arriving from government, military, and Fortune 500 networks that had no idea the bucket they trusted had changed hands (watchTowr). CSA’s writeup adds a third flavor specific to AWS CDK: its bootstrap process generates staging bucket names from a predictable pattern (cdk-{qualifier}-assets-{account-id}-{region}), so anyone who knows a target’s account ID — rarely a secret — can squat that name the moment it’s deleted.

Blast radius

The active-hijacking variant is the one that should worry infrastructure teams most, because it targets exactly the systems meant to detect compromise. An attacker who redirects a CloudTrail or Cloud Logging destination doesn’t just steal data — they blind the audit trail for whatever else they do next, and do it without touching IAM policy or triggering an anomaly on the logging pipeline itself, since from the producer’s side nothing failed. Replication jobs and Firehose streams carry application and customer data outright. The supply-chain variant is lower effort and higher reach: no compromise of the victim required, just patience and a few hundred dollars, with a blast radius measured in every downstream system that still references a name someone forgot to retire — the exact shape of risk that made the SolarWinds compromise so damaging, minus the initial intrusion.

Remediation

• Scope down deletion permissions. *:Delete* on storage should never ride along in a role meant only to configure logging destinations or replication rules — treat it as a distinct, tightly held privilege.
• Adopt AWS account regional namespaces for new S3 buckets — a March 2026 feature that scopes bucket names to your account and region instead of the global pool, so no other account can ever claim your suffix (AWS). It’s opt-in and prospective only, so existing buckets stay exposed until migrated (AWS migration guide).
• Enable soft-delete on Azure storage accounts and GCS buckets, with a retention window long enough to actually notice and react to a deletion event — this only helps if deletion alerts have a shorter response latency than the retention period, so pair it with real alerting, not just the toggle.
• Never route audit or telemetry destinations through a bucket type that ** could itself be hijacked and recreated** without a same-account or same-organization restriction — use aws:ResourceAccount conditions on CloudTrail/Firehose destinations and VPC Service Controls or SCPs to keep logging pipelines from ever being re-pointable outside the org.
• Before deleting any bucket that’s ever been referenced anywhere — code, CI/CD, IaC templates, DNS records, monitoring configs — search for that reference and retire it first. Treat a bucket name like a domain name: a durable identifier, not disposable infrastructure.

None of the providers have a full fix shipped for existing infrastructure; account regional namespaces close the door for new AWS buckets, but the underlying global-namespace model is baked into how S3, GCS, and Azure Blob have worked since launch. Until that changes structurally, the mitigation is operational discipline — knowing exactly what deletes a bucket name back into public reach, and never letting that action happen without checking who’s still depending on it.