Researchers at Focal Security recently disclosed GatewayToHeaven (CVE-2025-13292) , a critical cross-tenant vulnerability in Google Cloud’s Apigee. This flaw could allow attackers to gain unauthorized read and write access to logs and analytics data belonging to thousands of organizations.
Fortunately, no exploitation in the wild was detected, and the issue was quickly fixed by Google following our report. However, this vulnerability serves as a vital case study: if an attacker had exploited this vulnerability, could an organization have preemptively mitigated the damage through better cloud configuration and architectural decisions?
In this article, we use GatewayToHeaven as a case study to examine which defense techniques can defenders deploy to protect themselves against cross-tenant vulnerabilities, and what lessons can we learn for the future.
In cloud computing, a cross-tenant vulnerability occurs when a flaw in the provider’s shared infrastructure breaches the logical isolation between different customers. In a multi-tenant environment hosting various organizations, these bugs allow a malicious actor to bypass security boundaries and “pivot” from their own account into other accounts. This lateral movement grants unauthorized access to a neighbor’s data or resources without credentials, fundamentally compromising the provider’s guarantee of data sovereignty.
These vulnerabilities are notoriously difficult to defend against as a customer, because they occur within the cloud provider’s managed code and infrastructure. Customers cannot patch the Apigee cloud deployment itself; that remains Google’s responsibility under the Shared Responsibility Model.
GatewayToHeaven (CVE-2025-13292) is a cross-tenant vulnerability within the Google Cloud Apigee infrastructure. It allowed an attacker to gain unauthorized read and write access to the analytics data and access logs of other Apigee organizations.
The potential impact was severe. The exposed logs often contained sensitive information, including JWT access tokens and PII. Furthermore, the write access meant an attacker could theoretically modify logs, injecting fictitious data to cover their tracks or confuse audit trails.
Once Focal Security notified the Google Cloud VRP, they quickly deployed a fix and confirmed that this vulnerability was not abused in the wild.
Although GatewayToHeaven—and cross-tenant vulnerabilities in general—are nearly impossible to prevent without a provider patch, organizations can implement defense-in-depth strategies. These measures help limit exposure and preserve data integrity, even when the provider’s infrastructure is compromised.
As a fundamental security practice (preventing CWE-532), sensitive information should NEVER appear in URLs or GET parameters. These fields are routinely captured by load balancers, proxies, and browser history, making them unsafe for secrets.
This risk is not unique to Apigee; many cloud products inadvertently log data that engineers assume is ephemeral. Therefore, it is critical to understand the analytics and logging flows of your cloud products and aggressively scrub sensitive data.
The Case Study Application: In the case of GatewayToHeaven, the Apigee platform logged URL contents and query strings to the vulnerable cross-tenant datastore. Organizations that ensured sensitive values were passed only in the request body (POST/PUT) or HTTP headers effectively neutralized the data leakage risk, as those fields were not stored in the compromised logs.
A key aspect of GatewayToHeaven was the potential for attackers to modify access logs. If an organization relied solely on default Apigee-hosted logs during an incident, they could be misled by tampered data. State-backed attackers, in particular, often attempt to hide their operations by manipulating logs.
If log integrity is a priority, organizations should never rely solely on the cloud’s native access logs. Instead, maintain log immutability using cryptographic signing or by shipping logs to a separate, isolated store for cross-reference.
The Case Study Application: Apigee supports the MessageLogging policy, which can stream logs to an external, customer-controlled sink such as Cloud Logging or a Syslog server. By leveraging an external log sink, organizations ensured their audit trails bypassed the vulnerable cross-tenant datastore, remaining immutable and trustworthy even while the vulnerability existed.
For security reasons, organizations should only enable features they absolutely need. Any unused feature can unnecessarily expand the attack surface.
The Case Study Application: The GatewayToHeaven vulnerability stemmed from how logs and analytics data were managed in the upstream infrastructure. Organizations can opt out of this collection by disabling the analytics add-on.
While the component handling access logs is independent of the analytics engine, analytics data is far more verbose and contains richer request details. Disabling this add-on removes a significant volume of data from the cross-tenant datastores, effectively minimizing the information available to an attacker during a cross-tenant exploit.
There are significant security benefits to using self-hosted deployments of cloud products. Because the runtime components are under the organization’s direct control, there is greater flexibility to modify or disable components, effectively shrinking the attack surface. Furthermore, hosting on user-managed infrastructure insulates the organization from infrastructure-level cross-tenant vulnerabilities that has the potential to affect public cloud environments.
The Case Study Application: Apigee Hybrid was not affected by GatewayToHeaven. This is because Apigee Hybrid employs a fundamentally different architecture for analytics and log aggregation that does not use the vulnerable cross-tenant datastore.
Trade-offs: This enhanced control comes at the cost of operational overhead, as organizations must manage the underlying infrastructure (such as a managed GKE cluster or on-premise hardware) themselves. Additionally, under the Shared Responsibility Model, opting for Hybrid implies the organization is confident it can manage infrastructure security better than Google.
For smaller organizations with less technical know-how, the fully managed cloud version remains the recommended approach. However, for those prioritizing data sovereignty and isolation, the physical separation of the data plane is invaluable.
This case study highlights that while patching a cloud provider’s infrastructure is impossible for the customer, the situation is not helpless.
To reduce exposure to cross-tenant vulnerabilities, organizations should:
In Conclusion, There is no “one-size-fits-all” cloud architecture. Organizations must align their deployment model with their risk tolerance, carefully weighing the convenience of managed services against the control and isolation of hybrid alternatives.
Align your cloud strategy with your actual risk profile. Focal Security specializes in threat modeling and secure cloud architecture.
Make sure to follow us on either LinkedIn or X (Twitter) to get an update whenever a new article or writeup is posted.