On June 22, 2026, Palo Alto Networks' Unit 42 published an analysis of a bucket-hijacking technique that exploits a missing control in major cloud-provider architectures: a storage bucket's identity is bound to its name, not to an immutable ownership identifier. The result is a cross-provider attack in which a threat actor can silently redirect active data flows to an environment under their control without ever touching the source service.
- Storage bucket names are globally unique within each cloud provider but are not anchored to an immutable owner: deleting and recreating a bucket with the same name in another account transfers the destination's identity
- Unit 42 demonstrated the attack against three Google Cloud services — Logging, Pub/Sub, and Storage Transfer Service — with confirmed data exfiltration in every test case
- The attack requires two specific Google Cloud permissions:
storage.objects.deleteto empty the bucket andstorage.bucket.deleteto delete it - The research was shared with three CSPs — Google Cloud, AWS, and Microsoft Azure — but zero threat actors have been identified using this technique in the wild; real-world detection is described as particularly difficult
The Mechanism: Name as Identity, Not Address
The vulnerability does not reside in an implementation bug but in an architectural choice. As Unit 42 documents, cloud providers treat the bucket name as the global identifier of a data flow's destination. When an administrator configures Google Cloud Logging to sink logs to a bucket, or when Pub/Sub archives messages to GCS, the system resolves the destination by querying the global namespace: the name is the destination.
This means that if the bucket is deleted and immediately recreated with the identical name in another project, account, or even organization, the automated flows continue to operate. There is no service interruption, no visible error, no failure notification. The data simply changes destination without the sender's knowledge.
The source describes this characteristic as the "foundational logic" of the attack. The key quote from the analysis: "Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk." The shift from legal ownership to nominal ownership is instantaneous.
The Simulations: Three Services, Three Confirmed Exfiltrations
Unit 42 built proof-of-concepts against three Google Cloud services, demonstrating that the technique does not depend on a specific implementation but on the shared namespace model. In the Google Cloud Logging case, researchers configured a sink to a GCS bucket, deleted the bucket, recreated it in a controlled project, and verified the arrival of logs. The flow did not break.
The same procedure worked on Pub/Sub, where messages destined for an archival bucket were hijacked, and on Storage Transfer Service, configured for automated transfers between buckets. In all three cases, exfiltration occurred without any alteration of the source-side configuration. No compromise of the emitting service was required.
The required permissions are narrowly scoped: storage.objects.delete to empty the contents and storage.bucket.delete for the final deletion. No project-admin privileges or access to the data-generating systems are needed. The attacker strikes the endpoint, not the path.
"real-world attempts to use this attack technique would be difficult to detect"
The Cross-Provider Dimension: S3 and Azure in the Risk Perimeter
The analysis does not stop at Google Cloud. Unit 42 explicitly mentions AWS S3 buckets and the corresponding Azure Blob Storage service within the theoretical scope of the technique and notified all three providers before publication. However, the dossier contains detailed evidence only for the Google ecosystem. For AWS and Azure, the source does not document published simulations or list specific permissions equivalent to those tested on GCS.
Coordinated disclosure with three major CSPs suggests that the global-namespace logic is not a Google exception but a shared characteristic, at least in nominal structure. The text notes that the research was shared "before any mitigations were provided," without clarifying whether mitigations have since been released.
Organizations operating across multiple clouds cannot assume protection exists on one provider simply because another has been studied more deeply.
What to Do Now
For organizations using Google Cloud, the immediate priority is to verify who holds the two critical permissions identified by Unit 42: storage.objects.delete and storage.bucket.delete on buckets that receive automated flows from Logging, Pub/Sub, or Storage Transfer Service. Removing these permissions from roles that do not strictly require them reduces the documented attack surface.
For buckets serving as destinations for automated data pipelines, it is necessary to check that no configurations exist with implicit dependencies on the bucket name without owner verification. This applies especially to centralized logging sinks and scheduled transfer jobs.
In multi-cloud environments, the operational step is mapping active buckets as endpoints of data flows, not merely as static storage. Bucket deletion must be treated as a persistent risk event: the name remains available in the global namespace and can be reclaimed.
Monitoring bucket access logs is the only documented control with potential effectiveness against this technique, given that the attack generates no service errors. Visibility into the actual change of ownership — not just configuration — remains the weak point highlighted by the research.
Why It Matters
The source does not quantify the number of potentially exposed buckets or estimate the attack surface across the three providers. The list of vulnerable services is described as a "representative subset," implying that other services with automated flows to buckets may exhibit the same characteristics.
The most relevant datum for risk assessment remains the difficulty of detection. Because the attack generates no errors and does not interrupt service, its effectiveness in real-world scenarios depends entirely on the ability to monitor bucket access logs.
The absence of identified threat actors does not mitigate the technique's relevance. On the contrary, the combination of low visibility, narrowly scoped access requirements, and silent impact makes it an ideal vector for long-term espionage operations, where persistence is the priority over immediacy.
For enterprises with automated data pipelines on cloud, the critical point is awareness that deleting a resource does not equate to its disappearance from the risk perimeter. The name survives as an active address until someone else claims it.
Information is based on the cited source and current as of publication.