Bucket Namespace Hijacking: Cross-CSP Data Exfiltration via Global Name Reuse

Unit 42 has identified a systematic weakness in how major cloud service providers manage global bucket namespaces. Because bucket names must be globally unique across all users within a CSP (and in many cases, across CSPs), attackers can register buckets using names that organisations previously used but have since deleted, or predict future bucket names based on common naming conventions. This creates a window of vulnerability where data pipelines, configuration files, or hardcoded references continue pointing to a bucket name that is now under attacker control.

The technical foundation of this attack relies on organisations failing to account for namespace reuse risk. When a bucket is deleted, the name typically enters a grace period before becoming available for re-registration. During this window or immediately after, an attacker can claim the name and begin receiving data destined for the original bucket. If applications reference buckets by name rather than by immutable identifiers, or if backup and disaster recovery configurations reference deleted buckets, data can flow directly to attacker-controlled storage. The attack is particularly effective against organisations using default naming patterns, predictable naming schemes, or buckets created during mergers and infrastructure migrations.

All three major CSPs are affected because the vulnerability is architectural rather than implementation-specific. AWS S3, Azure Blob Storage, and Google Cloud Storage all enforce global namespace uniqueness, and all allow bucket name recycling after deletion. Organisations relying on any of these platforms are potentially exposed if they have deleted buckets, use shared naming conventions within their industry, or fail to lock down bucket name references in their infrastructure code.

Defenders should immediately audit deleted buckets and their grace periods, enforce immutable bucket identifiers in infrastructure-as-code, implement strict bucket access controls and logging, and avoid hardcoding bucket names in applications. Organisations should also review backup and failover configurations to ensure they do not reference buckets that no longer exist. Cloud storage access should be mediated through identity and access management policies that do not assume bucket ownership based on naming alone.

This finding highlights a fundamental tension in cloud design: global uniqueness is operationally convenient but creates a persistent security surface. The attack is low-cost to execute, difficult to detect at scale, and affects organisations across all industries that manage sensitive data in cloud storage. It is a reminder that infrastructure security requires defence in depth and cannot rely on namespace isolation as a control boundary.