New “LeakyLooker” Flaws in Google Looker Studio Could Enable Cross-Tenant SQL Queries

Cybersecurity researchers have disclosed nine cross-tenant vulnerabilities in Google Looker Studio that could have permitted attackers to run arbitrary SQL queries on victims’ databases and exfiltrate sensitive data within organizations’ Google Cloud environments.

The shortcomings have been collectively named LeakyLooker by Tenable. There is no evidence that the vulnerabilities were exploited in the wild. Following responsible disclosure in June 2025, the issues have been addressed by Google.

The list of security flaws is as follows –

• Cross Tenant Unauthorized Access – Zero-Click SQL Injection on Database Connectors
• Cross Tenant Unauthorized Access – Zero-Click SQL Injection Through Stored Credentials
• Cross Tenant SQL Injection on BigQuery Through Native Functions
• Cross-Tenant Data Sources Leak With Hyperlinks
• Cross Tenant SQL injection on Spanner and BigQuery Through Custom Queries on a Victim’s Data Source
• Cross Tenant SQL Injection on BigQuery and Spanner Through the Linking API
• Cross-Tenant Data Sources Leak With Image Rendering
• Cross-Tenant XS Leak on Arbitrary Data Sources With Frame Counting and Timing Oracles
• Cross Tenant Denial of Wallet Through BigQuery

“The vulnerabilities broke fundamental design assumptions, revealed a new attack class, and could have allowed attackers to exfiltrate, insert, and delete data in victims’ services and Google Cloud environment,” security researcher Liv Matan said in a report shared with The Hacker News.

“These vulnerabilities exposed sensitive data across Google Cloud Platform (GCP) environments, potentially affecting any organization using Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage, and almost any other Looker Studio data connector.”

Successful exploitation of the cross-tenant flaws could enable threat actors to gain access to entire datasets and projects across different cloud tenants.

Attackers could scan for public Looker Studio reports or obtain access to private ones that use these connectors (e.g., BigQuery) and seize control of the databases, allowing them to run arbitrary SQL queries across the owner’s entire GCP project.

Alternatively, a victim creates a report as public or shares it with a specific recipient, and uses a JDBC-connected data source such as PostgreSQL. In this scenario, the attacker can take advantage of a logic flaw in the copy report feature that makes it possible to clone reports while retaining the original owner’s credentials, enabling them to delete or modify tables.

Another high-impact path detailed by the cybersecurity company involved one-click data exfiltration, where sharing a specially crafted report forces a victim’s browser to execute malicious code that contacts an attacker-controlled project to reconstruct entire databases from logs.

“The vulnerabilities broke the fundamental promise that a ‘Viewer’ should never be able to control the data they are viewing,” Matan said, adding they “could have let attackers exfiltrate or modify data across Google services like BigQuery and Google Sheets.”