Global Namespace Bucket Hijacking: Universal Cloud Data Exfiltration via Storage Bucket Name Reclamation (AWS S3 / GCP Cloud Storage / Azure Blob)
Global Namespace Bucket Hijacking (TL-2026-0905), also tracked as Global Namespace Risk, is a high-severity software vulnerability, first published 2026-06-22. It has no confirmed attribution, affects Amazon Web Services Amazon S3 (global bucket namespace), maps to 16 MITRE ATT&CK techniques (T1078, T1485, T1526), and is covered by 9 detection rules and 17 indicators of compromise.
Key facts for TL-2026-0905
- Threat ID
- TL-2026-0905
- Also known as
- Global Namespace Risk, Universal Bucket Hijacking, Bucket Namesquatting, Bucket Sniping, Storage Bucket Name Reclamation
- Severity
- HIGH
- Status
- MONITORING
- Category
- VULNERABILITY
- First published
- 2026-06-22
- Last reviewed
- 2026-06-22
- Attribution confidence
- NONE
- Motivation
- UNKNOWN
- Target sectors
- technology, financial, government, healthcare, cloud-service-customers, saas
- Target regions
- Global, North America, Europe, Asia-Pacific
- Detection rules
- 9
- Indicators of compromise
- 17
Unit 42 (Palo Alto Networks) disclosed a cross-provider architectural weakness in which globally unique cloud storage bucket names can be reclaimed by an attacker after the original bucket is deleted, then recreated under the attacker's own account. Data pipelines that reference the destination by name only — logging sinks, replication, diagnostic exports, streaming delivery — silently reroute to the attacker-controlled bucket, enabling stealthy data exfiltration across AWS, Google Cloud, and Microsoft Azure. No in-the-wild exploitation has been observed; impact was demonstrated by researcher proof-of-concept.
How Global Namespace Bucket Hijacking works
On June 22, 2026, Unit 42 researcher Yahav Festinger published 'The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration', detailing an architectural class of attack that affects AWS S3, Google Cloud Storage (GCS), and Azure Blob Storage. The root cause is that cloud storage buckets are addressed by a globally unique name rather than by an immutable, account-bound identity. Data-stream configurations (logging sinks, object replication rules, streaming/diagnostic exports) reference their destination bucket purely by that name. Because the name is the only binding, an actor who can delete a victim bucket can immediately recreate an identically named bucket under their own account, and every pipeline that pointed at the old bucket continues to deliver data — now into attacker-controlled storage.
The attack chain has five stages. (1) The attacker obtains credentials carrying bucket-deletion authority — storage.buckets.delete on GCP, the s3:DeleteBucket action on AWS, or Microsoft.Storage/storageAccounts/delete on Azure. Critically, these coarse delete permissions bypass the granular update permissions (logging.sinks.update, pubsub.subscriptions.update, storagetransfer.jobs.update on GCP) that would normally be required to retarget a pipeline, so the attacker never needs to touch the sink configuration itself. (2) The attacker deletes the victim's storage bucket. (3) The attacker recreates a bucket with the same globally unique name in their own account/project. (4) Pre-existing data pipelines that reference the destination by name automatically resume delivery to the new, attacker-owned bucket. (5) Sensitive telemetry — audit logs, network flow records, replicated objects, diagnostic exports — flows continuously to the attacker with no configuration error surfaced to the victim.
Affected pipelines differ by provider. On Google Cloud the technique abuses Cloud Logging aggregated/log sinks, Pub/Sub export subscriptions, and Storage Transfer Service jobs whose destinations are GCS buckets. On AWS it abuses S3 cross-region/same-region Replication destinations, Amazon Data Firehose S3 delivery, CloudTrail log delivery to S3, and VPC Flow Logs delivered to S3. On Azure the analogous vector is Azure Monitor diagnostic settings that export resource logs/metrics to a storage account; Azure storage accounts can be hijacked across subscriptions (not across tenants) by exploiting DNS name resolution of the storage endpoint, and the technique requires that storage-account soft-delete / name-retention protections be disabled so the name can be re-registered.
The attack is intrinsically stealthy: after recreation the sink/replication/diagnostic configuration still appears valid on inspection, no delivery errors are raised, and the only high-fidelity signal is the original bucket-deletion API event followed shortly by a same-name creation event — often in a different account. Unit 42 reported the findings to all three providers. Google Cloud adjusted how router/sink resources interact with destination buckets; AWS offered account-scoped regional S3 namespaces (which eliminate global name reuse for opted-in buckets, building on the broader account-regional namespace capability S3 introduced in 2026); and Microsoft pointed to DNS subdomain-takeover prevention guidance and storage soft-delete. The researchers note the pattern is portable to other name-addressed cloud resources and providers beyond the three studied. No CVE was assigned and the source states no CVSS score.
MITRE ATT&CK techniques used in TL-2026-0905
Initial Access
Impact
T1485 Data Destruction; T1565 Data Manipulation
Discovery
T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery; T1619 Cloud Storage Object Discovery
Collection
Exfiltration
T1537 Transfer Data to Cloud Account
Credential Access
Defense Evasion
defense-impairment
T1578 Modify Cloud Compute Infrastructure; T1685 Disable or Modify Tools
Resource Development
T1583 Acquire Infrastructure; T1584 Compromise Infrastructure
Reconnaissance
Execution
Affected products and versions in Global Namespace Bucket Hijacking
- Amazon Web Services — Amazon S3 (global bucket namespace)
Vulnerable versions: Global bucket namespace (default, pre-opt-in)
Fixed in: Account-scoped regional S3 namespace (opt-in for new buckets) - Google Cloud — Google Cloud Storage (GCS) + Cloud Logging sinks / Pub/Sub / Storage Transfer Service
Vulnerable versions: Global GCS bucket namespace with name-bound sink/transfer destinations
Fixed in: Adjusted router/sink resource-to-bucket interaction - Microsoft — Azure Blob Storage / Storage Accounts + Azure Monitor diagnostic settings
Vulnerable versions: Storage accounts with soft-delete/name-retention disabled, cross-subscription DNS name reuse
Fixed in: Soft-delete / name retention enabled; DNS subdomain-takeover prevention guidance
Remediation for Global Namespace Bucket Hijacking
Patches
- Google Cloud adjusted router/sink resource interaction with destination buckets
- AWS offers account-scoped regional namespace option for new S3 buckets
- Microsoft Azure references DNS subdomain-takeover prevention and storage-account soft-delete / name retention
Immediate actions
- Enforce least privilege for bucket-deletion authority: restrict s3:DeleteBucket (AWS), storage.buckets.delete (GCP), and Microsoft.Storage/storageAccounts/delete (Azure) to a minimal break-glass set of identities
- Alert on every bucket/storage-account deletion API call, prioritizing buckets used as logging, replication, or diagnostic destinations
- Detect rapid recreation of an identically named bucket, especially when the creating account differs from the deleting account
- Inventory all data pipelines (log sinks, replication rules, Firehose/Data Transfer jobs, diagnostic settings) and baseline their expected destination buckets
Workarounds
- Enable Azure storage-account soft-delete / name retention to prevent immediate name re-registration
- Use uniquely randomized, non-guessable bucket names to raise the cost of pre-claiming
- Restrict bucket creation in trusted projects/accounts to pre-approved naming patterns enforced by policy
Longer-term hardening
- Adopt AWS account-scoped regional S3 namespaces for new buckets to eliminate global name reuse
- Deploy a data-perimeter architecture on AWS using Service Control Policies (SCPs) and VPC endpoint policies to block cross-account data writes
- Define Google Cloud VPC Service Controls perimeters around projects holding sensitive storage
- Deploy Data Security Posture Management (DSPM) and cloud runtime/behavioral security to flag anomalous data-movement destinations
- Bind pipeline destinations to immutable resource identity (project/account-scoped) rather than global name wherever the provider supports it
Weaknesses (CWE) in Global Namespace Bucket Hijacking
CWE-284, CWE-639, CWE-708, CWE-350
Timeline of Global Namespace Bucket Hijacking
- AWS S3 launches with a single global bucket namespace, establishing the name-as-identity binding that underlies the technique; S3 retained global naming for ~18 years.
- AWS introduces account-regional S3 namespaces, an opt-in path that scopes bucket names to the owning account and region and eliminates global bucket-name reuse for new buckets.
- Microsoft recommends Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers; storage-account soft-delete/name-retention must be disabled for the name to be re-registered, and cross-tenant name reuse is blocked for several days.
- Google Cloud adjusts how router/sink resources interact with destination storage resources to reduce automatic rerouting to recreated same-name buckets.
- Unit 42 shares the bucket-hijacking findings with Google Cloud, Amazon Web Services, and Microsoft Azure ahead of public disclosure.
- Threadlinqs Intelligence ingests the technique as TL-2026-0905 for multi-cloud detection and hunting coverage.
- Unit 42 reports no real-world threat actor has yet been identified using this attack technique; impact is demonstrated only via researcher PoC.
- Proof-of-concept demonstrates silent data rerouting via deleted-then-recreated buckets across AWS S3 replication/Firehose, GCS Cloud Logging sinks / Pub/Sub / Storage Transfer Service, and Azure Monitor diagnostic settings.
- Unit 42 researcher Yahav Festinger publicly discloses 'The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration' with cross-provider proof-of-concept.
Sources cited for Global Namespace Bucket Hijacking
- The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration
- AWS S3 Introduces Account-Regional Namespaces, Ending 18 Years of Global Bucket Name Collisions
- What is S3 Bucket Namesquatting, and How Do You Prevent It?
- The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts of S3 Buckets Without a Trace
- Amazon S3 bucket permissions for VPC flow logs
- Remediating a potentially compromised S3 bucket - Amazon GuardDuty
- AWS CDK Risk: Exploiting a Missing S3 Bucket Allowed Account Takeover
- MITRE ATT&CK T1537: Transfer Data to Cloud Account
- MITRE ATT&CK T1578: Modify Cloud Compute Infrastructure
Threats related to Global Namespace Bucket Hijacking
- Cloud Bucket Hijacking — Global Namespace Risk: Silent Data-Stream Redirection via Statically-Named Storage Buckets (AWS / Google Cloud / Azure)
- ShutterGap: Ephemeral Public Exposure of AWS RDS/DocumentDB Snapshots, AMIs & SSM Documents Evades CSPM/CNAPP Scan Cycles
- Pickle in the Middle: Vertex AI Model Upload Hijacking via GCS Bucket Squatting Enables Cross-Tenant RCE (google-cloud-aiplatform v1.139.0/v1.140.0)
- Lone Attacker Uses AI-Assisted Workflows to Breach Large AWS Cloud Environment in 72 Hours (Sygnia Investigation)
- CosmosEscape: Gremlin API Sandbox Escape Exposed Platform-Wide Key for Every Azure Cosmos DB Database
- Azure Blob Storage Ransomware: Four Storage-Encryption Abuse Methods (BlackCat/ALPHV, STORM-0501)
Detection coverage for TL-2026-0905
As of 2026-06-22, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0905 across Splunk SPL, Microsoft KQL and Sigma, covering 17 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.