LeakyLooker: 9 Google Looker Studio Flaws Enabled Cross-Tenant SQL and Data Theft
LeakyLooker: 9 Google Looker Studio Flaws Enabled Cross-Tenant SQL and Data Theft | 2026
Executive Summary
LeakyLooker is the name Tenable gave to a set of nine vulnerabilities in Google Looker Studio that could have let attackers cross trust boundaries inside a cloud analytics platform. According to public reporting, the bugs enabled attack paths ranging from arbitrary SQL execution to cross-tenant data exfiltration and, in some scenarios, the ability to insert, update, or delete records in connected data sources.
What makes this case important is that Looker Studio sits in front of live enterprise data. It can connect to BigQuery, Spanner, Google Sheets, Cloud Storage, PostgreSQL, MySQL, and other sources, so a flaw in the report layer can become a flaw in the organization's real data plane. Google says the issues were remediated, and public coverage reviewed so far does not cite evidence of active exploitation.
What is LeakyLooker?
LeakyLooker is a vulnerability cluster affecting the way Looker Studio handled report sharing, credential reuse, and query construction across connectors. Public write-ups say the issues affected both owner-credential and viewer-credential flows, creating both 0-click and 1-click abuse paths.
That means an attacker might not need to compromise the underlying database directly. Instead, they could abuse the BI layer itself to make Looker Studio run actions on their behalf using existing trust relationships.
Why this matters
1. BI platforms are part of the production attack surface
Analytics tools are often treated as low-risk dashboards, but they frequently hold privileged access to live cloud datasets. If the middleware is vulnerable, the blast radius can extend far beyond reporting.
2. Cross-tenant failures break core cloud trust assumptions
The serious issue here is not just a buggy report. It is the possibility that one tenant's report logic, copied dashboard, or connector state can influence access to another tenant's data path.
3. Data exposure can become data manipulation
Several reports say the impact was not limited to reading data. In some cases, the same weakness pattern could have enabled INSERT, UPDATE, or DELETE operations against connected sources, turning analytics abuse into integrity risk.
Technical overview
Arbitrary SQL through report logic
One of the most severe reported paths involved user-controlled column aliases being concatenated into live BigQuery jobs. If that behavior is accurate as described, an attacker could influence the final SQL execution path without needing traditional direct database access.
Credential reuse in copied reports
Another reported issue involved copied reports retaining original stored JDBC credentials. That kind of behavior can quietly collapse the expected ownership boundary between the copied artifact and the original data connection.
0-click and 1-click attack paths
Public coverage says both 0-click and 1-click scenarios were possible depending on whether the report used owner credentials or viewer credentials. That matters because it lowers the barrier to abuse in collaborative reporting environments.
Timeline
| Date | Event | Status |
|---|---|---|
| 2025 | Tenable reports multiple issues in Google Looker Studio through responsible disclosure | ⚠️ Initial discovery |
| 2025 | Public issue identifiers published for the LeakyLooker vulnerability set | 📢 Public disclosure |
| 2025-2026 | Google remediates the disclosed flaws in the managed service | ✅ Remediated |
| 2026-03-16 | Security teams review exposure and connector trust assumptions after public reporting | 🔍 Continuing review |
Defensive posture: immediate actions
🔴 Review BI connectors as privileged assets
- Inventory every Looker Studio connector tied to sensitive production data.
- Verify which reports use owner credentials versus viewer credentials.
- Reduce unnecessary write access from reporting connectors wherever possible.
🔒 Limit blast radius from analytics tooling
- Separate read-only analytics service accounts from operational write-capable accounts.
- Review who can copy, share, and edit reports connected to sensitive datasets.
- Rotate credentials for high-value JDBC or cloud data source connections when warranted.
👀 Hunt for unusual query and access patterns
- Review BigQuery, Spanner, and database audit logs for unusual query patterns tied to report activity.
- Investigate unexpected data access immediately following dashboard shares, copies, or connector changes.
- Validate whether analytics-linked service accounts have broader privileges than they need.
Example hunting ideas
- Look for analytics service accounts issuing write operations where reporting should be read-only.
- Look for sudden access to datasets unrelated to the normal dashboard owner.
- Look for copied reports that retain legacy connector bindings or unexpected credential paths.
Strategic lesson
LeakyLooker is a reminder that cloud BI security is cloud security. The middleware between users and data warehouses is not a harmless presentation layer when it can execute live queries, store credentials, and mediate access across shared reports.
For defenders, the main lesson is simple: treat reporting platforms as part of the enterprise trust fabric, with the same scrutiny you would apply to internal admin tools, API gateways, and SaaS control planes.
Was LeakyLooker actively exploited in the wild?
The public reporting reviewed for this post does not cite evidence of active exploitation. However, the reported impact is serious enough that organizations should still review connector privileges, report sharing patterns, and audit logs.
What systems were reportedly in scope?
Public coverage says the affected paths involved connectors such as BigQuery, Spanner, Google Sheets, Cloud Storage, PostgreSQL, and MySQL, among others.
Why is this more than a dashboard bug?
Because the analytics layer can hold trusted access to live enterprise data. If that trust layer fails, attackers may be able to read or even manipulate records without compromising the underlying platform directly.
Bottom line
LeakyLooker shows how vulnerabilities in a cloud analytics platform can turn ordinary dashboards into cross-tenant SQL and data exposure paths.
Key takeaways
✅ Treat BI connectors as privileged infrastructure — not as harmless reporting glue.
✅ Reduce write-capable analytics access — especially where owner credentials bridge into production data.
✅ Audit copied reports and connector trust — because middleware trust failures can spread quietly.
If your organization uses Google Looker Studio with sensitive cloud data sources, review connector permissions, sharing models, and query audit trails as part of your normal cloud security program.
References
- Cyber Security News: Google Looker Studio Vulnerabilities Allow Attackers to Exfiltrate Data from Google Services
- Tenable Research on LeakyLooker
Published: 2026-03-16 Author: Invaders Cybersecurity Classification: Public / TLP:CLEAR Reading Time: 5 minutes