Google Looker Studio Vulnerabilities Allow Attackers to Exfiltrate Data from Google Services

A set of nine novel cross-tenant vulnerabilities in Google Looker Studio, collectively dubbed “LeakyLooker,” that could have allowed attackers to run arbitrary SQL queries, exfiltrate sensitive data, and even modify or delete records across Google Cloud environments, all without victims granting explicit permission.

Google has since fully remediated all identified issues following responsible disclosure.

Google Looker Studio (formerly Data Studio) is a cloud-based business intelligence and data visualization platform that connects to live data sources, including BigQuery, Google Sheets, Spanner, PostgreSQL, MySQL, and Cloud Storage, to generate real-time, shareable reports.

Built on Google Cloud infrastructure, it relies on a permission-sharing model similar to Google Docs, where reports can be accessed via specific user credentials or public links. This “live data” architecture, while powerful, became the platform’s central security weakness.

Two Credential Models, Two Attack Paths

The root of the LeakyLooker vulnerabilities lies in how Looker Studio handles authentication. The platform supports two credential modes: Owner Credentials, in which the report fetches data using the report owner’s authentication token regardless of who is viewing it, and Viewer Credentials, in which each viewer must authenticate independently.

Tenable researchers discovered that these two models created two independent, exploitable attack paths:

• 0-click attacks (Owner Credentials): Attackers craft server-side requests to a public or shared report and trigger Looker Studio to fetch or manipulate data using the owner’s identity — no victim interaction required.
• 1-click attacks (Viewer Credentials): Victims unknowingly execute malicious SQL queries simply by opening a manipulated report link or visiting an attacker-controlled website.

Tenable disclosed nine distinct flaws spanning both attack paths:

• TRA-2025-28 — Zero-Click SQL Injection on Database Connectors
• TRA-2025-29 — Zero-Click SQL Injection Through Stored Credentials
• TRA-2025-27 — Cross-Tenant SQL Injection on BigQuery via Native Functions
• TRA-2025-40 — Cross-Tenant Data Sources Leak With Hyperlinks
• TRA-2025-38 — Cross-Tenant SQL Injection on Spanner and BigQuery via Custom Queries
• TRA-2025-37 — Cross-Tenant SQL Injection on BigQuery and Spanner via the Linking API
• TRA-2025-30 — Cross-Tenant Data Sources Leak With Image Rendering
• TRA-2025-31 — Cross-Tenant XS Leak via Frame Counting and Timing Oracles
• TRA-2025-41 — Cross-Tenant Denial of Wallet Through BigQuery

How the Alias Injection (0-Click) Worked

In the most severe 0-click vulnerability (TRA-2025-28), Tenable found that Looker Studio generated user-controlled column aliases that were directly concatenated into live BigQuery SQL jobs.

Attackers bypassed Google’s input filters, which stripped dots and spaces, by using SQL comments (/**/) as whitespace substitutes and CHR(46) with CONCAT() to reconstruct dot-notated project paths at query execution time. This allowed full, arbitrary SQL execution across the report owner’s entire GCP project.

The “Sticky Credential” Logic Flaw

Among the most alarming findings was the “Sticky Credential” flaw (TRA-2025-29) in Looker Studio’s “Copy Report” feature. When a viewer copies a report connected to a JDBC data source such as PostgreSQL or MySQL, the new report retains the original owner’s stored database credentials.

Since the attacker now owns the copied report, they gain access to the Custom Query feature and can execute arbitrary CRUD operations including DELETE * FROM secret_table using the victim’s credentials without ever knowing the actual password.

1-Click Blind Data Exfiltration

For the 1-click path (TRA-2025-27), researchers exploited Looker Studio’s NATIVE_DIMENSION feature, which allows raw SQL injection into calculated fields.

Attackers bypassed Google’s keyword filter by splitting forbidden SQL keywords with empty comments (e.g., SEL/**/ECT). A multi-statement BigQuery script then looped through the victim’s INFORMATION_SCHEMA, extracted all table and column names, and exfiltrated data character by character by querying specially named attacker-controlled public tables (e.g., exfil-a, exfil-b), reconstructing the victim’s entire database from Google Cloud access logs.

Patch Status and Mitigations

There is no evidence these vulnerabilities were exploited in the wild. Since Looker Studio is a fully managed Google service, patches were deployed globally; no customer action is required for remediation.

Security teams should nonetheless take the following precautions:

• Audit all users with “View” access to Looker Studio reports, both public and private
• Treat BI platform connectors as a critical part of your attack surface
• Revoke access for any data source connectors no longer in active use
• Follow Google’s guide to review and restrict Looker Studio’s access to connected Google services.

Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.