The Docket: When Your Analytics Tool Leaks Everyone's Analytics

Google Looker Studio just patched nine cross-tenant vulnerabilities that could have let attackers run arbitrary SQL queries on victims' databases and exfiltrate sensitive data across Google Cloud environments. Tenable, the security firm that discovered the flaws (collectively named "LeakyLooker"), found no evidence of exploitation before the patch. But the legal exposure window was real.

What Happened

Looker Studio is Google's business intelligence platform. Organizations use it to visualize data from BigQuery, Cloud SQL, and other databases. The nine vulnerabilities all stemmed from the same architectural problem: insufficient tenant isolation. An attacker in Tenant A could craft requests that accessed Tenant B's database connections and credentials.

The attack chain looked like this:

1. Attacker creates a Looker Studio report in their own Google Cloud environment
2. Exploits cross-tenant flaw to inject SQL into victim's data source
3. Exfiltrates victim's database contents via the attacker-controlled report
4. Victim never sees logs of the query because it originated from Google's infrastructure

Google patched all nine vulnerabilities before Tenable's public disclosure. No organizations need to take action. But the design flaw existed for years before discovery.

The Legal Problem

This is a third-party risk scenario. If you store customer PII or financial data in BigQuery and connect it to Looker Studio, a vulnerability in Google's product could trigger your breach notification obligations. The data never left Google Cloud, but unauthorized access occurred.

Three regulatory implications:

1. Breach notification: Most state laws define a "security breach" as unauthorized acquisition of personal information. LeakyLooker qualified. Even though Google patched it before exploitation, companies using Looker Studio with sensitive data would have faced disclosure obligations if evidence of exploitation emerged later.
2. Third-party vendor risk: SOC 2, ISO 27001, and HIPAA all require organizations to assess vendor security controls. A critical cross-tenant vulnerability in a Google product is exactly the scenario those requirements exist to catch. Boards ask: "Did we validate Google's multi-tenant isolation before connecting production databases?"
3. Contractual liability: If your SaaS product uses Looker Studio to provide customer analytics dashboards, and a LeakyLooker exploit exposed your customers' data, your customers will invoke the indemnification clause in your MSA. Google's patch doesn't shield you from contractual exposure.

What Changed

Google's disclosure was thin. The fixes landed quietly. No CVEs were assigned. Tenable coordinated responsible disclosure, but the timeline suggests Google treated this as an architectural fix rather than an emergency patch.

The absence of CVEs matters. Many organizations trigger vendor risk reviews based on CVE severity scores. Without CVEs, LeakyLooker won't show up in automated vendor risk dashboards. But the legal exposure was identical to a scored vulnerability.

Takeaway

Analytics platforms are now attack surfaces. If your BI tool connects directly to production databases, assume cross-tenant vulnerabilities exist. The mitigation isn't "switch vendors" (every multi-tenant SaaS has this risk). The mitigation is "don't connect production databases directly to third-party BI tools without data masking, read-only replicas, or dedicated service accounts with minimal privileges."

LeakyLooker was patched before exploitation. Next time might be different.

Sources

• New LeakyLooker Flaws in Google Looker Studio Could Enable Cross-Tenant SQL Queries
• Tenable Research: LeakyLooker Vulnerabilities
• Google Cloud Looker Studio Documentation
• NIST SP 800-53: Third-Party Risk Management