Google patches RCE, internal database leak flaws in Looker

Google patched two vulnerabilities in its Looker business intelligence and data analytics platform that could have enabled remote code execution (RCE) and exfiltration of sensitive data from an internal database.

Tenable discovered the pair of flaws, which it dubbed “LookOut,” and revealed their proof-of-concept exploits in a blog post Wednesday. The flaws could have been exploited by users with developer permissions in Looker, according to Google.

The first flaw could have led to RCE using a crafted malicious LookML project. Looker Modeling Language (LookML) projects are collections of files that define how data is modeled and presented within Looker.

LookML projects can include remote dependencies to external Git repositories that Looker clones to the system. Looker uses a Git hook configuration with a hooksPath that points to a path containing the dependency name (i.e. ../../git_hooks/[dependency name]).

Tenable found that they could achieve path traversal by adding directory traversal characters (i.e. “../”) to the Git project name.

Related reading:

By creating additional dependencies that triggered Looker to create the /git_hooks/ directory and write a malicious file named “pre-commit” to the location hooksPath now points to, they could cause the malicious file to be executed via a Git hook.

However, this also required the researchers to craft the malicious dependencies to ensure that the malicious file retained the executable permission bit and that the project’s POST parameters were set to work with Git commands rather than JGit, which does not support Git hooks and is the default in Looker.

Additionally, executing the malicious file required the researchers to win a race condition by flooding the APIs that write the path traversal to the configuration file and execute the Git commit. This is because Looker automatically overwrites the config file with the safe path before running the Git command.

By winning the race condition and rewriting the path traversal after the safe overwrite and before the Git commit, they were able to achieve the intended result and execute the malicious file.

In Google Cloud deployments of Looker, this flaw could have led to cross-tenant traversal through access to shared secrets folders. For on-premises deployments, the risk is code execution and lateral movement on the host system.

Second flaw's MySQL data exfiltration

The second flaw, tracked as CVE-2025-12743, could have led to the exfiltration of data from a sensitive internal MySQL database that Looker uses to manage metadata, users and permissions, which is not intended to be accessed by regular users or developers.

The researchers discovered the name of this internal database connection, “looker__ilooker,” by examining Looker logs. Ordinarily, users can only select connections to databases they have access to when creating a new LookML project, but the researchers found they could bypass the user interface restrictions by intercepting and modifying the HTTP request to set the connection parameter to the internal database name.

Once this connection was created, they were able to exfiltrate data from the database by triggering an SQL query error via Looker’s “data tests” feature, which caused pieces of data from looker__ilooker to be returned with the error message. Using a series of crafted error injections, an attacker could eventually extract the entire database, Tenable said.

These flaws were resolved in versions 25.12.30+, 25.10.54+, 25.6.79+, 25.0.89+ and 24.18.209+, with versions 25.13 and above not affected. Looker Studio is also not affected by this flaw.

While the vulnerabilities are already resolved for Google Cloud deployments of Looker, operators of self-hosted and on-premises versions will need to ensure their systems are patched.