Mar 12, 2026 · 6 min read
Nine Flaws in Google Looker Studio Could Have Let Attackers Query Your Entire Database
Tenable researchers found cross tenant vulnerabilities that let attackers exfiltrate, modify, and delete data across Google Cloud environments without a single click.
A Dashboard That Could Read Your Entire Database
Google Looker Studio is used by millions of organizations to build dashboards and reports from their cloud databases. It connects to BigQuery, Cloud Spanner, PostgreSQL, MySQL, Google Sheets, and dozens of other data sources. It is supposed to display only what you authorize.
But researchers at Tenable discovered nine vulnerabilities that broke that assumption entirely. Collectively named "LeakyLooker," these flaws could have allowed an attacker to run arbitrary SQL queries against a victim's databases, exfiltrate sensitive data, modify records, or even delete entire datasets, all across different Google Cloud organizations.
Google has patched all nine issues. There is no evidence they were exploited in the wild.
Zero Click Attacks Through SQL Injection
The most dangerous class of LeakyLooker flaws required no victim interaction at all. Tenable researcher Liv Matan discovered that column aliases in Looker Studio were user controlled and directly concatenated into SQL queries. While Google's filters stripped spaces and dots, the researchers bypassed them using SQL comments (/**/) and ASCII character functions (CHR(46) for dots, CONCAT() for path reconstruction).
This "alias injection" technique let attackers embed full SQL queries into report parameters. Because the queries executed with the report owner's credentials, the attacker gained access to every database the owner could reach, including across the owner's entire Google Cloud project.
Additional zero click vectors included credential leaks through the Linking API, data exposure via image rendering, and a "denial of wallet" attack that could run up BigQuery costs by forcing expensive queries.
One Click Attacks That Weaponized Report Sharing
A second class of attacks required a victim to open a shared report or click a link. The most significant was the "copy report" flaw: when a viewer cloned a report that used JDBC database connections (PostgreSQL, MySQL), the original owner's credentials were silently copied to the new report. The viewer, now the new report's owner, could unlock custom query features and execute unrestricted database operations using the original credentials.
Another one click technique used native SQL dimensions to force viewers' browsers to execute attacker controlled queries when loading a report. Frame counting and timing oracles, a type of cross site leak, allowed attackers to extract data through browser timing analysis without direct database access.
How Data Exfiltration Worked
The researchers demonstrated a blind exfiltration technique that could reconstruct entire databases character by character. The method worked by:
- Creating public "exfil" tables in the attacker's own BigQuery project, one for each alphanumeric character
- Embedding SQL that queried the victim's
INFORMATION_SCHEMAto enumerate all tables and columns - Executing sequential queries attempting to read from each exfil table
- Monitoring their own GCP access logs where each attempt appeared, reconstructing data one character at a time
This approach is slow but nearly invisible to the victim. All query execution happened under the report owner's identity, and the exfiltration traffic appeared as normal inter project access in Google Cloud.
Every Looker Studio Connector Was Potentially Affected
The scope of these vulnerabilities was enormous. Nearly every Looker Studio data connector was potentially affected: BigQuery, Cloud Spanner, PostgreSQL, MySQL, Google Sheets, Cloud Storage, and more. Any organization with public Looker Studio reports or reports shared with external collaborators was at risk.
The cross tenant nature of the attack meant that separate Google Cloud organizations, which are supposed to have completely isolated environments, could be breached through a single shared report.
Google's Response and What to Do Now
Tenable disclosed the vulnerabilities to Google's Vulnerability Reward Program in June 2025. Google patched all nine issues globally, and because Looker Studio is a fully managed service, no customer action was required for the fixes to take effect.
However, organizations should still take steps to reduce their exposure:
- Audit "View" access permissions on all Looker Studio reports, both public and private
- Treat BI platform connectors as critical attack surface, not just internal tooling
- Remove access to unused data connectors via Google account permissions
- Monitor credential usage patterns in connected data sources for anomalies
LeakyLooker is a reminder that business intelligence platforms sit at the intersection of user facing dashboards and backend databases. When the boundary between "viewing" and "querying" breaks down, the consequences extend far beyond a single report.