Google patched nine “LeakyLooker” flaws in Looker Studio that exposed cross-tenant data risks

Google has patched a set of nine security flaws in Looker Studio that researchers say could have let attackers reach data across tenant boundaries, run arbitrary SQL queries, and in some cases modify or delete records in connected services. The issues, disclosed by Tenable and collectively named “LeakyLooker,” affected the way Looker Studio handled shared reports, linked data sources, and credential models. Google says it found no evidence of active exploitation and that customers do not need to take action.

The bugs matter because Looker Studio is designed to pull live data from services such as BigQuery, Google Sheets, Cloud Storage, Spanner, PostgreSQL, and MySQL. That live connection makes dashboards useful, but it also creates a larger attack surface when permissions, report sharing, and credential handling do not behave as expected. Tenable says the flaws opened both zero-click and one-click attack paths, depending on whether a report used owner credentials or viewer credentials.

At the center of the research is a simple problem. Looker Studio supports two ways to access data. With owner credentials, viewers can see report data through the report owner’s authorization. With viewer credentials, each person opening the report must authenticate with their own access. Google’s own documentation explains that difference clearly, and Tenable says both models created distinct ways to cross trust boundaries if abused.

What researchers found

Tenable says the most serious flaws could let attackers do more than read dashboard output. In several cases, they could inject SQL into backend queries, leak connected data sources across tenants, abuse the Linking API, or trigger denial-of-wallet activity through BigQuery. The company’s write-up lists nine separate issues and says the overall impact included potential data exfiltration plus insert, update, and delete operations in victims’ environments.

One attack path targeted reports that used owner credentials. In that scenario, Tenable says an attacker could craft requests against a public or shared report and force Looker Studio to fetch or manipulate data using the owner’s identity. Because the action happened on the server side, the report owner did not need to click anything. Tenable describes this as a zero-click path.

Another path targeted viewer credentials. In those cases, the attack needed user interaction, such as opening a manipulated report or visiting a malicious page. Tenable says that still gave attackers a route to inject queries under the victim’s own identity, which could then expose metadata and data from connected sources.

The “sticky credential” issue stood out

One of the most alarming findings involved Looker Studio’s Copy Report feature. Tenable says that when a viewer copied a report connected to certain JDBC data sources, including PostgreSQL or MySQL, the cloned report could retain the original owner’s stored database credentials. If that happened, the attacker who created the copy became the owner of the new report and could gain access to features such as Custom Query without knowing the victim’s password. Tenable says this could allow arbitrary CRUD actions against the connected database.

That claim lines up with the broader design risk Google already documents around owner credentials. Google notes that owner credentials let other users access data by using the credential owner’s authorization, and Google Workspace admins can control whether users may set data sources to owner credentials. That setting exists because owner-based access can expose more data than many organizations expect if it is used too broadly.

Google says the issues are fixed

Google’s Cloud security bulletin states that Looker Studio fixed vulnerabilities reported through the Google and Alphabet Vulnerability Reward Program. The company says it found no evidence of exploitation, the issues are resolved, and no customer action is required. Google also says the flaws involved unauthorized access to data through shared reports, data sources with viewer credentials, the Studio Linking API, and Conversational Analytics.

That official wording is important because it confirms both the scope and the status. The flaws were serious enough to merit a formal bulletin, but Google treats them as fully remediated service-side issues. Since Looker Studio is a managed cloud product, Google deployed the fixes globally rather than asking customers to install a patch locally.

Why this matters for defenders

Even though Google has already fixed the vulnerabilities, the findings highlight a wider security lesson for analytics and BI platforms. Dashboards often sit on top of highly sensitive systems, but teams sometimes treat them like presentation tools instead of live data brokers. When those dashboards rely on stored credentials, public links, embedded images, or cross-service APIs, a small logic flaw can become a path into cloud data that was never meant to leave its original boundary. This is an inference based on the research and on Google’s own credential model documentation.

Security teams should also revisit who can view, copy, and share reports. Google provides admin controls to restrict external sharing, govern connector use, and limit who can use owner credentials. Those controls will not fix a vendor-side bug after the fact, but they can reduce blast radius when a future flaw affects shared analytics workflows.

Breakdown of the nine flaws

Source for the table: Tenable’s LeakyLooker disclosure.

What organizations should review now

• Audit who has view access to public and private Looker Studio reports.
• Review whether teams really need owner credentials on shared data sources.
• Restrict external sharing and unnecessary third-party connectors where possible.
• Treat BI connectors as part of the production attack surface, not just reporting tools. This point follows from the Tenable research.

FAQ