Inside LookOut: How Researchers Uncovered a Full Compromise Path in Google Looker

Tenable security researchers have uncovered a pair of previously unknown vulnerabilities in Google Looker that, when chained together, could allow attackers to take complete control of a Looker instance and, in cloud environments, potentially reach across customer boundaries. The flaws were were responsibly disclosed through Google’s Cloud Vulnerability Reward Program, and patched on Google-managed systems. The risk now falls squarely on organizations that run Looker themselves.

Looker is not just another analytics dashboard. For many enterprises, it acts as a central nervous system for business data, translating raw databases into real-time insights using LookML, Google’s proprietary modeling language. That role makes it an especially attractive target. A successful compromise does not just expose charts and queries. It opens a door to credentials, internal metadata, and in some cases the infrastructure beneath the platform.

Two vulnerabilities, one complete takeover

Tenable researchers collectively dubbed the findings “LookOut,” a name that reflects both the scope of the attack surface and the severity of the outcome. The first flaw was a remote code execution chain that abused how Looker handles Git repositories for LookML projects. The second was an authorization bypass that enabled attackers to attach to Looker’s own internal database and extract sensitive data.

Individually, each issue was serious. Together, they formed a path to full compromise.

In Google-hosted environments, the remote code execution bug was especially concerning because it broke assumptions about tenant isolation. A successful attacker could potentially move laterally between customer environments by reaching shared secrets on the underlying platform. In self-hosted and on-prem deployments, the impact shifted from cross-tenant exposure to direct control of the Looker server and its surrounding network.

How a BI feature became an attack vector

The remote code execution chain hinged on a feature designed for developer convenience. Looker allows teams to pull in remote LookML dependencies from Git repositories. Under the hood, each LookML project is itself a Git repository, complete with configuration files and hooks that define how Git behaves.

Researchers found that a user-controlled value, the name of a remote dependency, was written directly into Git’s configuration without proper sanitization. By carefully crafting that name, an attacker could manipulate Git’s hooksPath setting and redirect it to an arbitrary location on the server.

That alone was not enough. The attack required several additional steps: forcing Looker to create directories that did not already exist, planting a malicious Git repository with executable hook scripts, and then triggering a race condition so the malicious configuration would be used at exactly the right moment. The final hurdle was Looker’s reliance on JGit, a Java-based Git implementation that does not execute hooks at all. The researchers ultimately identified a deployment flow where Looker falls back to the system’s native Git client, enabling hooks to run.

When all of those pieces lined up, the result was straightforward and devastating. Arbitrary code execution on the Looker server, with the same privileges as the application itself.

A second flaw exposed Looker’s internal database

The second vulnerability took a different route but led to an equally sensitive destination. Looker maintains an internal MySQL database that stores metadata about users, projects, and configuration. Access to that database is meant to be tightly restricted.

By intercepting and modifying a request during project creation, researchers found they could bypass UI-level validation and attach a user-controlled project to an internal database connection that should never have been exposed. From there, they leveraged Looker’s own data testing features to run carefully crafted SQL that leaked database contents through error messages.

Using error-based SQL injection techniques, they demonstrated the ability to extract internal records piece by piece, including configuration details and secrets. After confirming the impact, the researchers stopped short of a full data dump.

Patched in the cloud, exposed on premises

Google moved quickly once the issues were reported, patching its managed Looker service in Google Cloud. Customers using the SaaS version were protected without needing to take action.

That is not the case for organizations running customer-hosted or on-prem versions of Looker. In those environments, patching and infrastructure security remain the customer’s responsibility. Until updates are applied, the vulnerabilities leave a wide attack surface open.

Tenable recommends that self-hosted Looker administrators upgrade to patched releases immediately. Versions 25.12.30 and newer, along with several other specific builds, address the issues. Older deployments remain exposed.

A broader lesson for enterprise software

The LookOut vulnerabilities underscore a familiar but uncomfortable truth in enterprise security. Platforms that sit at the intersection of data access, code execution, and infrastructure management are inherently high-risk. Features that empower developers and analysts can also expand the attack surface in subtle ways.

In this case, a business intelligence tool became a gateway to system-level compromise through a chain of small design decisions. Google’s rapid response limited the fallout in the cloud, but the episode highlights the ongoing challenge for organizations that run complex platforms themselves.

For teams relying on Looker outside of Google’s managed environment, the message is clear. Verify your version, apply the patches, and treat analytics infrastructure with the same scrutiny as any other critical system.