Focal Security recently reported three critical cross-tenant vulnerabilities to Google affecting Gemini Enterprise, Cloud Run, and Vertex AI. These flaws allowed attackers to compromise data and execute arbitrary code inside organizations they had no prior access to.
The root cause of all three exploits was bucket squatting - a technique where an attacker preemptively creates a storage bucket they expect a victim’s service to use in the future.
This article breaks down how these vulnerabilities worked and their impact:
These vulnerabilities were discovered during our deep-dive cloud security research. If you are concerned about cross-tenant risks in your GCP environment, contact Focal Security to discuss a targeted architectural assessment.
Cloud providers like Google Cloud use a multi-tenant architecture, hosting the resources of multiple, unrelated customers on the same underlying infrastructure.
A cross-tenant vulnerability occurs when the security boundaries isolating these customers fail. It allows an attacker in one environment to break out and access the sensitive data or compute resources of another customer sharing the platform.
If you are interested in reading more about cross-tenant vulnerabilities, feel free to check out our GatewayToHeaven article about a cross-tenant vulnerability in GCP’s Apigee.
In GCP, all organizations share a single, globally unique namespace for bucket names. Once a bucket name is taken, no one else can own it - for that reason, you won’t be able to create a bucket with the name gs://test.
If an attacker can guess the bucket naming convention an organization intends to use, they can pre-claim, or “squat” it. If a workload of the organization later attempts to write data to that bucket without verifying who owns it, they will end up writing it to the attacker’s squatted bucket.
Let’s look at the following pseudocode script of a vulnerable service:
bucket_name = 'gs://my-org-{now.year}-{now.month}'
if not bucket.exists(bucket_name):
bucket.create(bucket_name)
bucket.upload(bucket_name, log_file)The script uses a predictable naming format: gs://my-org-[year]-[month]. If the workload sees that the bucket does not exist, it will create it. Either way, the logs are uploaded to the bucket.
If an attacker targeting this service recognized the pattern being used, they could create the bucket gs://my-org-2026-03 in February. Come March, the victim’s workload will follow the set pattern and check if gs://my-org-2026-03 exists. Because it does, it proceeds to dump logs into the bucket, without knowing it’s owned by the attacker:
This could have been avoided if the workload verified ownership of the bucket, or used any of the mitigation techniques highlighted in our bucket squatting mitigation article.
The prerequisites for bucket squatting are:
GeminiSquat (CVE-2026-1727) affected Gemini Enterprise (previously Agentspace), Google’s premium AI platform for large-scale business use. Unlike the personal-use version of Gemini, it allows the agent to access an organization’s internal and external data so it can automate workflows rather than just answer questions.
When ingesting data from certain sources, Gemini Enterprise utilized a bucket with a highly predictable naming format to stage the data:
gs://<project_number>_<location>_import_<data_source_type> Just like our bucket squatting example, Gemini Enterprise never verified who owned the bucket. Because data_source_type and location are easily guessable, an attacker only needed the victim’s GCP project number, which is simple to find using basic enumeration techniques.
By squatting this staging bucket, an attacker could read and modify data ingested by Gemini Enterprise from Cloud SQL, BigQuery, and other data sources. This vulnerability could have allowed for sensitive data leaks, manipulated AI responses, and potential prompt injection attacks.
MountSquat affected Cloud Run, Google’s serverless compute platform for containerized applications. When deploying a container, users can create a volume mount - a folder synced with a GCS bucket.
This feature lets containers natively integrate with GCS buckets without modifying their code. The workload simply writes to a Linux path, and the mount layer itself manages synchronization with the storage bucket.
If a user enabled this feature without specifying a bucket, Cloud Run would default to provisioning one with a predictable name:
gs://<project_number>-<service_name>-<region>-compose-volumesJust like Gemini Enterprise, Cloud Run lacked any bucket squatting protections, making it vulnerable to any attacker who knew which name to squat. In MountSquat’s case, it’s even easier - the project number, service name, and region are all visible in the Cloud Run deployment’s public URL (e.g., https://service-1234567890123.us-central1.run.app).
MountSquat’s impact was just as severe as GeminiSquat’s. An attacker squatting the mount volumes bucket could have gained real-time read and write access to all files in the mounted volume.
VertexSquat is a bucket squatting variant in Vertex AI, Google’s machine learning platform. One of its features is Vertex AI experiments, which make it easy to compare how different weights and configuration values affect a model’s performance.
The vulnerability is found in Vertex AI’s Python SDK. When saving and loading experiments, the SDK used the following default bucket pattern:
gs://<project_id>-vertex-staging-<region>As with the other vulnerabilities, Vertex AI lacked bucket ownership checks, making it susceptible to bucket squatting. However, VertexSquat’s impact was much more severe, because experiment artifacts contain serialized Python pickle files.
Pickle is Python’s built-in serialization format that converts Python objects into a byte stream, allowing them to be saved to disk or transmitted over the network, then reconstructed later. While convenient for preserving complex Python objects, pickle has a critical security flaw: during deserialization, it automatically executes code embedded in the file.
As the official Python documentation warns:
It is possible to construct malicious pickle data which will execute arbitrary code during unpickling. Never unpickle data that could have come from an untrusted source, or that could have been tampered with.
By squatting the bucket, an attacker could inject malicious RCE payloads into the pickle files. If an engineer loaded the experiment in a Vertex AI notebook or their local machine, the malicious pickle file would have been unserialized, executing the attacker’s embedded code. The payload would then be used to compromise the computer and identity of the victim, furthering the attacker’s control over the organization.
Thanks to the research conducted by Focal Security and the swift response from Google’s vulnerability research program, GeminiSquat, MountSquat, and VertexSquat were patched and mitigated before they could be exploited in the wild.
As shown in this article, bucket squatting is a common issue that can happen to everyone, whether it’s your own organization or a cloud service developed by Google. Luckily, it’s possible to preemptively mitigate bucket squatting and cross-tenant threats by using the appropriate defensive configuration.
Our article, Mitigating Bucket Squatting in Google Cloud, explains how to configure your GCP projects to withstand bucket squatting in both your workloads and in Google’s own infrastructure.
Cross-tenant flaws allow attackers to achieve massive impact without prior access to your organization. Focal Security helps you design resilient architectures to prevent that from ever happening.
Make sure to follow us on LinkedIn or X (Twitter) to get updates every time we publish new cloud security research.