# Global Namespace Bucket Hijacking: Universal Cloud Data Exfiltration via Storage Bucket Name Reclamation (AWS S3 / GCP Cloud Storage / Azure Blob)

> 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.

- **Published:** 2026-06-22T00:00:00Z
- **Last reviewed:** 2026-06-22T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0905
- **ID:** TL-2026-0905
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** MONITORING
- **Detections:** 9 · **IOCs:** 17 (full data via the Threadlinqs MCP server — Purple tier)

## Description

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

- T1595 Active Scanning
- T1583 Acquire Infrastructure
- T1078 Valid Accounts
- T1651 Cloud Administration Command
- T1526 Cloud Service Discovery
- T1580 Cloud Infrastructure Discovery
- T1578 Modify Cloud Compute Infrastructure
- T1685 Disable or Modify Tools
- T1574 Hijack Execution Flow
- T1530 Data from Cloud Storage
- T1537 Transfer Data to Cloud Account
- T1565 Data Manipulation
- T1619 Cloud Storage Object Discovery
- T1485 Data Destruction
- T1584 Compromise Infrastructure
- T1552 Unsecured Credentials

## Sources

- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
- [AWS S3 Introduces Account-Regional Namespaces, Ending 18 Years of Global Bucket Name Collisions](https://www.infoq.com/news/2026/03/s3-account-regional-namespaces/)
- [What is S3 Bucket Namesquatting, and How Do You Prevent It?](https://www.varonis.com/blog/preventing-s3-bucket-namesquatting)
- [The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts of S3 Buckets Without a Trace](https://www.varonis.com/blog/exploiting-vpc-endpoints-for-s3buckets)
- [Amazon S3 bucket permissions for VPC flow logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-s3-permissions.html)
- [Remediating a potentially compromised S3 bucket - Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-s3.html)
- [AWS CDK Risk: Exploiting a Missing S3 Bucket Allowed Account Takeover](https://www.aquasec.com/blog/aws-cdk-risk-exploiting-a-missing-s3-bucket-allowed-account-takeover/)
- [MITRE ATT&CK T1537: Transfer Data to Cloud Account](https://attack.mitre.org/techniques/T1537/)
- [MITRE ATT&CK T1578: Modify Cloud Compute Infrastructure](https://attack.mitre.org/techniques/T1578/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0905