As part of our ongoing mission to make the cloud more secure for everyone, Focal Security reported GatewayToHeaven, a read/write cross-tenant vulnerability in Google Cloud’s Apigee. This vulnerability was assigned CVE-2025-13292.
This article provides a high-level explanation of the vulnerability and its impact. The full technical analysis can be found here.
GatewayToHeaven was discovered during our deep-dive cloud security research. If you are concerned about cross-tenant risks or advanced attack surfaces in your own GCP environment, contact Focal Security to discuss a targeted assessment.
In cloud computing, providers (like AWS, Azure, or Google Cloud) use an architecture called multi-tenancy. This allows them to host the data and applications of multiple, unrelated customers (tenants) on the same underlying infrastructure.
A cross-tenant vulnerability occurs when the security boundaries between these tenants fail. This flaw allows one customer to break out of their isolated environment and access the sensitive data or resources of other customers sharing the platform.
Apigee is a proxy that lets organizations expose their backends to end users in a secure, centralized fashion.
Instead of letting end users connect directly to your sensitive backend servers, they connect to Apigee first. Apigee handles the request, checks if it is safe, and then passes it along to the correct internal system. When it receives the response from the backend, Apigee forwards it to the appropriate end user.
Apigee is a managed service. This means Google takes responsibility for setting up the resources necessary to run it - you are not required to set up or maintain your own servers to run the Apigee infrastructure.
As explained earlier, Apigee is a managed cloud service. The infrastructure is managed by Google, and the customer (you) does not have direct management access to it. These resources are stored inside a logical unit called a Tenant Project. Each customer gets a completely isolated and separated set of resources.
In the schematic above, you can see that each Apigee enabled project is asociated with a different isolated tenant project. The example.io organization has two GCP projects with Apigee enabled, and for each of them, Google provisioned an isolated Tenant Project containing all the resources necessary to run Apigee. The organization organization.net also has an Apigee-enabled project, which is associated with a different Tenant Project.
The attack relied on chaining together small misconfigurations to achieve a massive impact:
This is a simplification of the actual flow. In reality, every step presented many challenges that took a significant amount of time to overcome. Click here for the full technical writeup.
Tenant Projects are a prime target for security researchers because they blur the line between what belongs to the customer and what belongs to Google. We wanted to know: What resources live inside? Are there Google-managed service accounts? Do they have cross-tenant permissions?
To find out, we targeted the Apigee proxy component. Like many other workloads in the cloud, it gets its authentication token from a virtual HTTP server called the metadata endpoint. By configuring Apigee to use this internal endpoint as a backend, we could simply access it and retreives the token of the service account:
While this gave us a valid service account token, it was not a critical vulnerability on its own, as the permissions were limited to our specific Tenant Project. We needed to find a way to move laterally within the project and discover potential cross-tenant issues.
With the token in hand, we surveyed the environment to map available assets. Through our reconnaissance efforts, we discovered that Apigee relies on Dataflow to export analytics to the Google Cloud management console.
We then attempted to dig deeper into the decompiled code of the Dataflow pipeline, reverse engineering its behavior. It quickly became apparent to us that although every tenant has their own Dataflow instance, its service account appeared to have permissions reaching outside the isolated environment - specifically, into a shared, cross-tenant bucket:
As the diagram shows, the Dataflow pipeline in each Apigee Tenant Project connects to this central data store. If we could compromise the Dataflow service account within our own Tenant Project, we could access that shared bucket and all the information within it.
We then targeted the Dataflow service. Looking at the configuration of the pipeline, we noticed that it loaded Java dependencies from a storage bucket that our compromised Apigee account could write to. This offered a clear path: if we patched these files with malicious code, the Dataflow pipeline would execute them for us.
Using Recaf, a Java bytecode editor, we modified the dependencies. The payload was designed to query the Dataflow pipeline’s metadata endpoint, fetch its privileged service account token, and upload it to a storage bucket we controlled.
Once the modified files were uploaded, we flooded the system with analytic events to force the provisioning of a new Dataflow instance. Upon launch, the instance executed our malicious JAR files, and the high-privilege token was sent back to us.
The compromised Dataflow service account had full read/write access to several cross-tenant buckets holding verbose access logs and analytics data of all Apigee tenants.
The most sensitive data exposed were the access tokens tied to end user requests. If these tokens were present in an organization’s analytics data, an attacker could extract them and hijack active sessions, impersonating any end user.
For example, consider “Bank of Cyber,” which uses Apigee to secure their money transfers backends. If a user such as John logs in and to transfer money, his authentication token is logged into the cross-tenant bucket. An attacker could then steal John’s active token from the bucket, and immediately use it to authorize a fraudulent transaction in his name:
Cross-tenant vulnerabilities are uniquely dangerous because a single flaw can expose thousands of different companies simultaneously. This specific issue could have allowed an attacker to harvest sensitive user data from every organization using Apigee and, in many cases, perform actions on behalf of their end users.
Thanks to the research by Focal Security and the swift response from Google’s vulnerability research program, GatewayToHeaven was identified and mitigated before it could be exploited.
This Apigee vulnerability chain shows how multiple misconfigurations can lead to a massive impact. Focal Security finds these complex flaws in your cloud architecture before they affect you.
While customers cannot directly patch the cloud provider’s infrastructure, they can implement defense-in-depth strategies to limit the blast radius of such events. In a future article, we will review GatewayToHeaven as a case study, detailing how organizations can better prepare their environments to withstand cross-tenant compromises such as this one.
Make sure to follow us on either LinkedIn or X (Twitter) to get an update as soon as that article is live.