Tenable reveals Looker flaws risking cross-tenant attacks

Tenable Research has disclosed two security flaws in Google Looker that it says could allow attackers to remotely control Looker servers and extract sensitive internal data. Some deployments may remain exposed if customers have not patched self-hosted systems.

The vulnerabilities, dubbed “LookOut”, affect Looker, a business intelligence platform used by tens of thousands of organisations. Tenable estimates Looker is used by more than 60,000 companies across 195 countries.

One issue is a vulnerability chain that leads to remote code execution, allowing an attacker to run commands on a server from a distance and potentially take control of a Looker server.

Tenable also described a second flaw, identified as CVE-2025-12743, that could let an attacker exfiltrate Looker’s internal management database through internal connection abuse. That database may contain user credentials and configuration secrets.

According to Tenable, Google has patched the issues in its managed Looker service on Google Cloud. However, organisations running customer-hosted or on-premises versions remain at risk until they apply the patches.

Cross-tenant risk

The remote code execution chain has additional implications for cloud deployments. Tenable said it could bypass isolation controls in Google-hosted environments, creating a path to cross-tenant access.

Cross-tenant access means an attacker who compromises one customer environment can reach into another. In a multi-tenant cloud service, providers rely on isolation to prevent one customer’s workloads from interacting with another’s data or systems.

Tenable said the chain involved Git hook overrides. Git hooks are scripts that run automatically when specific repository actions occur. Tenable’s findings suggest an attacker could abuse this mechanism in Looker to introduce malicious behaviour and trigger remote command execution.

“This level of access is particularly dangerous because Looker acts as a central nervous system for corporate information, and a breach could allow an attacker to manipulate data or move deeper into a company's private internal network,” said Liv Matan, Senior Research Engineer at Tenable.

Database exposure

The second vulnerability centres on Looker’s internal management database. Tenable said researchers were able to trick the platform into connecting back to its own internal database interface, then use a data extraction technique to pull information from the management store.

Information in that database could include user credentials and configuration secrets, which can increase the impact of a breach by enabling an attacker to maintain access, alter configuration, or reach other systems connected to the analytics platform.

Security teams often treat analytics platforms as high-value targets because they sit close to business data and connect to multiple data sources. Looker deployments commonly integrate with data warehouses and operational databases, and can store credentials and connection settings for those systems.

Tenable said the two flaws illustrate the difficulty of securing platforms that combine rich user functionality with deep access to data, and of maintaining strict boundaries in cloud environments where users can run queries and interact with project resources.

“Given that Looker is often the central nervous system for an organisation's most sensitive data, the security of its underlying architecture is crucial; however, it remains difficult to secure such systems while providing users with powerful capabilities like running SQL or indirectly interacting with the managing instance's file system,” said Matan.

Self-hosted patching

Tenable said Google moved quickly to secure its managed service. Remaining exposure is concentrated among organisations running Looker outside Google’s managed environment, including deployments on private servers and on-premises hardware.

Self-hosted software can lag behind managed services because customers must schedule change windows, validate updates, and deploy fixes. Patch status can vary across large fleets by business unit and geography, even within the same organisation.

For security leaders, this split patching model complicates risk management. A vendor patching its cloud service does not automatically protect the same software running in customer environments.

What to look for

Tenable urged administrators to check for indicators of compromise tied to the described attack paths. It recommended inspecting Looker project folders for unexpected or unauthorised files in the .git/hooks/ directory.

It highlighted scripts named pre-push, post-commit, and applypatch-msg as examples an attacker could use, and advised teams to review application logs for signs of internal connection abuse.

Tenable also recommended looking for unusual SQL errors and patterns consistent with error-based SQL injection targeting internal Looker database connections such as looker__ilooker, as potential signs of attempted database exfiltration.

Organisations running self-hosted Looker should confirm whether they fall outside Google’s managed environment, verify patch levels, and review systems for these indicators while applying vendor updates.