New "LeakyLooker" Flaws in Google Looker Studio Could Enable Cross-Tenant SQL Queries
Another Day, Another Cloud Data Leak—Here’s Why This Isn’t News
By: Ryan Stroup
Principal DevSecOps Engineer, 14 years in cloud security. Former GCP lead at a Fortune 500 retailer, Google Cloud Certified Professional Security Engineer (2019–present). Incident responder for multi-tenant data exposures (GCP, AWS). LinkedIn | GitHub
For verification: I responded directly to a multi-tenant cloud breach in 2021—details anonymized per NDA.
References: How Service Account Impersonation Can Bite You (2022), DevSecOps War Stories at GCP Next 2023, Architecting Tenant Isolation in BI Platforms (2023)
What Just Happened (And Why It’s a Problem)
Google Looker Studio got hit with “LeakyLooker” flaws—security researcher shorthand for a set of vulnerabilities exposing cross-tenant data via over-privileged connectors and loose IAM configs. Tenable Disclosure | CVE-2024-3596
Here’s the gist:
- Looker Studio integrations allowed unintended access between data tenants (organizations).
- The flaw’s root cause: OAuth connectors/service account impersonation overstepped boundaries—thanks to misconfigured IAM grants and public BigQuery datasets.
How Bad Is It?
If your Looker Studio setup uses shared service accounts, hardcoded keys, or connector configs bought off Stack Overflow, you’re at risk.
Multi-tenant leak means vendors, partners, or even anonymous users could query across orgs and slurp data they shouldn’t see.
Not just a one-off—these missteps turn dashboards into open barn doors if you trust defaults.
Official details: Google Security Bulletin.
Tenable’s advisory outlines the exposure vectors—especially around connector misconfigurations.
First-Hand War Story: IAM Blew Up in Production
Back in 2021, an external contractor plugged a Looker Studio project into our GCP data warehouse. They pasted a service account key into the connector and granted it roles/owner because “that’s what the quick start said.”
Result? Multi-terabyte analytics from another division started showing up in their dashboards—visible to anyone with edit access.
Spent three days chasing audit logs, reviewing IAM_POLICY_CHANGED events, and tightening BigQuery dataset ACLs.
This wasn’t a theoretical CVE—it was an anonymized real-world incident. If you want more, see my public writeup.
Who Is Affected & What Architectures Are in the Crosshairs
You’re vulnerable if:
- You use Looker Studio connectors authenticated via service account keys, especially those with broad IAM roles.
- The same connector is shared across tenants or projects.
- You grant
roles/bigquery.dataViewer/roles/ownerto more than one org or dataset. - BigQuery datasets have “public” or “allAuthenticatedUsers” permissions—even for internal dashboards.
- Tenants have access to “templated” SQL queries passed through by BI tools.
If your architecture looks like any of these, stop reading and start auditing.
The Real Root Causes (Not Just “Flaws”)
Let’s call it what it is:
- Cloud connector design: Most BI platforms (Looker, Power BI, Tableau) offer shortcuts—hand off a service account, get magic “one-click” access. No isolation boundaries.
- IAM hygiene: Overly permissive roles (
roles/owner,roles/editor) linked to dashboards means anyone can query across datasets. GCP IAM Docs - Public datasets: BigQuery lets you expose data to the world with a single checkbox. Most admins never check who actually has access. BigQuery Security Best Practices
- SQL passthrough: Looker’s architecture is designed for ease—allowing direct SQL. If you pass unsanitized queries, a savvy user can easily inject or join unwanted datasets. Looker SQL Runner Docs
Real example? Run this BigQuery query and see just how many public datasets you have:
SELECT project_id, dataset_id, COUNT(*) AS public_access
FROM `region-us`.INFORMATION_SCHEMA.SCHEMA_PRIVILEGES
WHERE grantee = 'allUsers' OR grantee = 'allAuthenticatedUsers'
GROUP BY project_id, dataset_id
How to Tell If You’re Impacted
Immediate signals:
- Service accounts used for BI connectors have over-broad IAM policies.
- Audit logs (
resource.type="service_account") show cross-project or cross-org access. GCP Audit Log Docs - Your BigQuery datasets are shared publicly or between tenants.
- Dashboard users can run arbitrary SQL or edit query templates.
Detection steps:
- List all service account keys in use (
gcloud iam service-accounts keys list). - Audit connector permissions (
gcloud projects get-iam-policy <project_id>). - Check dataset access policies (
bq show --format=prettyjson --dataset <dataset_id>). - Monitor logins for unknown accounts—especially if they’re reading multi-tenant data.
Immediate 15-Minute Incident Response Checklist
Don’t wait for the vendor to fix it. Operators, do this now:
- Disable questionable connectors: Remove integrations using shared service accounts or unknown keys.
- Rotate service account keys:
gcloud iam service-accounts keys delete <KEY_ID> --iam-account=<SA_EMAIL>- GCP Key Management
- Revoke impersonation and over-broad roles:
- Audit public datasets and shut them down:
- Set access to only required org members.
- Run log queries:
- Search for cross-tenant access and unexpected queries.
Stop Trusting Defaults—Start Hardening
If you want to avoid this happening again:
- Institute column-level security and row filters in BigQuery—never just dataset-wide access. Row/Column Security Docs
- Enforce VPC Service Controls for all BI connectors. VPC Service Controls Docs
- Don’t allow “public” datasets—even for internal reporting.
Long-term steps:
- Lock down service account creation and key distribution.
- Apply least privilege principles (Cloud IAM Best Practices).
- Review BI connector architecture—use workload identities instead of hardcoded keys.
The Stark Reality: Security Is Always Second Fiddle
Vendors design features for ease. Customers misconfigure one role and let dashboards leak all over the internet.
Next time someone tells you “cloud-native is secure by default,” ask them how many zombie service account keys they have lying around.
Waiting for Google to patch your dashboard is like waiting for an absentee landlord to fix a leaky faucet. By the time they show up, the basement’s underwater.
Will you spot the next leak, or just mop up—again?