A set of nine novel cross-tenant vulnerabilities in Google Looker Studio, collectively dubbed \u201cLeakyLooker,\u201d that could have allowed attackers to run arbitrary SQL queries, exfiltrate sensitive data, and even modify or delete records across Google Cloud environments<\/a>, all without victims granting explicit permission.<\/p>\n Google has since fully remediated all identified issues following responsible disclosure.<\/p>\n 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.<\/p>\n 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 \u201clive data\u201d architecture, while powerful, became the platform\u2019s central security weakness.<\/p>\n 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\u2019s authentication token regardless of who is viewing it, and\u00a0Viewer Credentials, in which each viewer must authenticate independently.<\/p>\n Tenable researchers discovered that these two models created two independent, exploitable attack paths:<\/p>\n Tenable disclosed nine distinct flaws<\/a> spanning both attack paths:<\/p>\n 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.<\/p>\n Attackers bypassed Google\u2019s input filters, which stripped dots and spaces, by using SQL comments ( Among the most alarming findings was the \u201cSticky Credential\u201d flaw (TRA-2025-29) in Looker Studio\u2019s \u201cCopy Report\u201d 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\u2019s stored database credentials.<\/p>\n Since the attacker now owns the copied report, they gain access to the Custom Query feature and can execute arbitrary CRUD operations including For the 1-click path (TRA-2025-27), researchers exploited Looker Studio\u2019s Attackers bypassed Google\u2019s keyword filter by splitting forbidden SQL keywords with empty comments (e.g., 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.<\/p>\n Security teams should nonetheless take the following precautions:<\/p>\n Follow us on Google News<\/a>, LinkedIn<\/a>, and X<\/a> for daily cybersecurity updates. Contact us<\/a> to feature your stories.<\/strong><\/p>\n The post Google Looker Studio Vulnerabilities Allow Attackers to Exfiltrate Data from Google Services<\/a> appeared first on Cyber Security News<\/a>.<\/p>\n<\/div>\nTwo Credential Models, Two Attack Paths<\/strong><\/h2>\n
\n
\n
How the Alias Injection (0-Click) Worked<\/strong><\/h2>\n
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEgTPSaoWNHFJtA0f76jiaApNGOb47WI_BJKBIU5bUIPkk0Lhjc5aGgItfNlzC6xJfU0nctUYeV0IrCvcKOmuTd2LUIBiwQc9O23ERYS0VaPk3uNy9at6kp8q4lDfskpYQQQxjGUe_xS1KqZJrHfSseC_0_vZgrQbfpgqWpCJoNR-Y1cB2tBmjLnsCxX96LB\/s16000\/0-click%2520payload.webp?ssl=1\")
<\/figure>\n\/**\/<\/code>) as whitespace substitutes and CHR(46)<\/code> with CONCAT()<\/code> to reconstruct dot-notated project paths at query execution time. This allowed full, arbitrary SQL execution across the report owner\u2019s entire GCP project.<\/p>\nThe \u201cSticky Credential\u201d Logic Flaw<\/strong><\/h2>\n
DELETE * FROM secret_table<\/code> using the victim\u2019s credentials without ever knowing the actual password.<\/p>\n1-Click Blind Data Exfiltration<\/strong><\/h2>\n
NATIVE_DIMENSION<\/code> feature, which allows raw SQL injection into calculated fields.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEjBZo7RFMfHS0bF92EE0wkJJNbpskOt-JnxUmgigm11Fg36cmaAU30reTd_SwlLZq5f4wr32wszpRcgWa2PiMcF01M2663YITHujq5ZjJoQugFPcl5iTTUYihCPgg6qBNrv1_gXd93vtzK4Evdi2mxp1qGTU_BO3UjZDUFKZABliDUxrPZ0j31W-E65WQ4u\/s16000\/1-click.webp?ssl=1\")
<\/figure>\nSEL\/**\/ECT<\/code>). A multi-statement BigQuery script then looped through the victim\u2019s INFORMATION_SCHEMA<\/code>, extracted all table and column names, and exfiltrated data character by character by querying specially named attacker-controlled public tables (e.g., exfil-a<\/code>, exfil-b<\/code>), reconstructing the victim\u2019s entire database from Google Cloud access logs.<\/p>\nPatch Status and Mitigations<\/strong><\/h2>\n
\n