A newly disclosed set of nine cross‑tenant vulnerabilities in Google Looker Studio, collectively named “LeakyLooker,” exposed organizations to severe risks including arbitrary SQL execution, data exfiltration, data modification, and cross‑project access without user consent. Google has fully patched all identified issues following responsible disclosure.

Google Looker Studio — formerly Google Data Studio — is a cloud‑native business intelligence (BI) platform that allows organizations to build live dashboards and reports connected to services such as BigQuery, Google Sheets, Cloud Storage, MySQL, PostgreSQL, and Spanner

Its architecture, modeled after Google Docs’ permission‑sharing system, allows reports to dynamically query backend data sources in real time. While powerful, this design introduced a series of credential and query‑handling flaws that made cross‑tenant attacks possible.

Two Credential Models, Two Attack Paths

Looker Studio supports two authentication modes that became the foundation for two exploit chains:

1. Owner Credentials (0‑Click Attacks)

Reports using Owner Credentials execute queries using the owner’s identity, regardless of who views the report.

Attackers could exploit this by sending crafted server‑side requests to publicly shared or even restricted reports, triggering data access using the owner’s permissions without interaction.

2. Viewer Credentials (1‑Click Attacks)

Reports using Viewer Credentials require each viewer to authenticate.

Attackers crafted malicious links or embedded Looker Studio frames into compromised websites, causing victims to unknowingly execute arbitrary SQL when they opened the report — a classic 1‑click SQL injection scenario.

Researchers from Tenable disclosed nine independent vulnerabilities impacting both attack classes:

TRA‑2025‑28 — Zero‑click SQL injection via database connectors
TRA‑2025‑29 — Sticky Credential flaw with stored JDBC credentials
TRA‑2025‑27 — Cross‑tenant SQL injection on BigQuery
TRA‑2025‑40 — Data leaks via hyperlink rendering
TRA‑2025‑38 — SQL injection on BigQuery & Spanner via Custom Queries
TRA‑2025‑37 — SQL injection via Looker Studio Linking API
TRA‑2025‑30 — Data leaks via image rendering
TRA‑2025‑31 — Cross‑tenant timing‑oracle leak
TRA‑2025‑41 — BigQuery wallet‑exhaustion DoS attack

How the 0‑Click Alias Injection Worked (TRA‑2025‑28)

One of the most severe vulnerabilities stemmed from Looker Studio’s handling of user‑controlled column aliases, which were directly concatenated into BigQuery SQL queries.

Google attempted to filter dangerous characters, stripping dots and whitespace. However, attackers bypassed these filters by using:

/**/ SQL comments as whitespace replacements
CHR(46) combined with CONCAT() to reconstruct dot‑notation

This resulted in full arbitrary SQL execution across the victim’s entire Google Cloud project — including data retrieval, modification, and deletion.

The “Sticky Credential” Vulnerability (TRA‑2025‑29)

The Copy Report feature in Looker Studio allowed users to duplicate reports that connected to JDBC sources such as PostgreSQL or MySQL.

Researchers discovered that the copied report continued to use the original owner’s stored database credentials, even though the attacker now owned the duplicated report.

This created a stealthy and extremely powerful attack route:

Attacker copies a Looker Studio report
Gains full access to the owner’s connected database
Gains ability to run arbitrary SQL, including destructive commands such as: DELETE * FROM sensitive_table;
Without ever knowing the actual password

This flaw allowed attackers to inherit privileged database access silently.

1‑Click Blind Exfiltration (TRA‑2025‑27)

In the 1‑click attack chain, Tenable demonstrated that Looker Studio’s NATIVE_DIMENSION function could be abused for raw SQL injection by bypassing keyword filters using comment splitting (e.g., SEL/**/ECT).

Attackers ran multi‑statement BigQuery workflows that:

Queried INFORMATION_SCHEMA to enumerate all datasets, tables, and columns
Extracted data one character at a time
Wrote the results to attacker‑controlled public tables (like exfil-a, exfil-b)
Reconstructed the victim’s entire database via GCP access logs

This method required only that the victim open a Looker Studio report link.

Patch Status

Google has confirmed that:

All nine vulnerabilities have been fully patched
No evidence of in‑the‑wild exploitation was found
No user action is required for remediation, as Looker Studio is fully managed

Because these flaws could be exploited silently and cross‑tenant, remediation speed was essential.

Recommended Security Actions

Although fixes are live, organizations should still improve BI platform hygiene:

✔ Audit all users with View access to Looker Studio reports

Even public or shared reports may expose sensitive data indirectly.

✔ Treat data connectors as part of your attack surface

BI tools often sit between sensitive backend databases and broad internal audiences.

✔ Revoke unused or orphaned data source connectors

Minimize long‑lived credentials that attackers could inherit.

✔ Follow Google’s permissions‑hardening guidance

Ensure that Looker Studio only has access to datasets actually required for reporting.

Conclusion

The LeakyLooker vulnerabilities exposed a systemic weakness in how cloud‑native BI tools handle:

Cross‑tenant execution
Credential inheritance
Backend SQL compilation
Viewer vs owner identity boundaries

While Google has fully resolved these issues, the incident underscores how BI platforms — especially those performing live queries into production databases — can become high‑value attack vectors.

Organizations should routinely audit BI permissions, treat report‑sharing links as sensitive objects, and maintain strict governance over embedded credentials.

Critical LeakyLooker Flaws Expose Google Cloud Data