LeakyLooker: the tenant crossing failure at Looker Studio that could exfilter Google Cloud data

Earlier this year, security researchers revealed a set of failures that affected Looker Studio, Google's tool to create reports and panels from various data sources. Tendable baptized that package of defects as LeakyLooker and described it as a series of weaknesses of "cross-tenant" capable, at worst of the scenarios, of allowing an attacker to run arbitrary SQL consultations against foreign databases and extract sensitive information hosted within Google Cloud projects.

Although there is no indication that these holes were exploited in real environments, the research made it clear that the potential impact was serious. Following a responsible notification in June 2025, Google applied corrections. The public report of Tenable on these investigations is available with detailed technical explanations, for example in this general analysis published by the Tenable.

The identified vulnerabilities include multiple different vectors: SQL injections that do not require user interaction (zero-click), credentials abuses stored in JDBC connectors, native function failures that allowed to inject into BigQuery, data source leaks through links or image renderization, time-filtering techniques and frame counting, and even a way to cause resource denial effects in BigQuery. Tendable documented each case with its own technical data sheet, publicly accessible, for example here about injection through stored connectors and credentials TRA-2025-28 and TRA-2025-29 or specific problems related to BigQuery and Spanner TRA-2025-27 and TRA-2025-37.

What makes these failures particularly disturbing is not only the possibility of executing malicious SQL sentences, but the cross-cutting nature of the problem: many organizations connect Looker Studio with services such as BigQuery, Spanner, Google Sheets, PostgreSQL, MySQL or Cloud Storage to build panels. If an attacker manages to exploit one of these chains, he could scan public reports or use a shared report to reach credentials and, from there, access complete data sets within different GCP projects.

A scenario described by researchers illustrates how an apparently innocent flow - for example, making a visualization public or sharing it with a collaborator - can become an attack vector. Thanks to a failure in the logic of copying reports, an opponent could clone a report and retain the credentials of the original owner, with the subsequent ability to alter or delete tables in the linked database. In other documented cases, it was enough for the victim to open or visualize a report designed ad hoc for his browser to run code that contacted a project controlled by the attacker, facilitating data reconstruction from records.

In the words of the responsible researcher, these vulnerabilities broke one of the fundamental guarantees of the system: that a role of only reading or "spectator" should not be able to manipulate or control the data it visualizes. In fact, the research showed ways in which a user with minimum permits could indirectly cause the exfiltration or modification of information in services such as BigQuery and Google Sheets.

From a defensive perspective, the publication of Tenable and Google's response highlight several practical lessons that any security team or cloud manager should consider. It is recommended to review which Looker Studio reports are publicly exposed, to audit the connectors that store credentials and to apply the principle of minor privilege in service accounts and related credentials. Google maintains documentation about Looker Studio that helps understand how reports are shared and managed, for example at the help center Looker Studio, and those who use BigQuery can review best practices on the page of BigQuery and Google Cloud security guides in cloud.google.com / security.

It is important to stress that the failures were the result of complex logical combinations and not of a single trivial error: the complete attack requires to chain several conditions and leverage unexpected behaviors on the platform. However, the existence of these chains shows that the interfaces between services and the management of credentials are critical areas that require rigid testing and updated threat models.

Responsible disclosure was key to risk reduction: Tenable informed Google in June 2025 and, following the collaboration between the two parties, corrections were made before the technical information was widely disseminated. Such coordination most likely avoided massive malicious use and gave managers time to take preventive action.

For organizations that depend on dashboards and cloud data, this episode should serve as a reminder that the comfort of sharing and visualizing information should not sacrifice basic security controls. Rotate credentials after changes, limit access to sensitive connectors, review sharing policies and monitor unusual consultation attempts in services such as BigQuery are practical steps that reduce the attack surface.

Overall, LeakyLooker is another example of how the complexity of cloud platforms and the interaction between components can generate new attack vectors. The good news is that the problems were parched after the notification, and the technical publication of Tenable offers material for security teams to learn and strengthen their defenses. For those who want to deepen the findings, Tenable published individual technical notes on each vector, including those relating to filtered by images and links ( TRA-2025-30), temporary oracles ( TRA-2025-31) and specific routes to BigQuery and Spanner ( TRA-2025-38).

The morale for technical and management officials is clear: security in shared data environments requires constant monitoring, periodic permit reviews and a firm policy on what is published and shared with. Keep informed about supplier security notices and take advantage of research resources - such as those offered by Tenable - helps to quickly close gaps before they can be exploited.