Tenable Research Exposes “LookOut” Vulnerabilities in Google Looker, Raising Stakes for Self-Hosted Users
Key Highlights
- The 'LookOut' vulnerabilities include a remote code execution chain that could give attackers administrative access without authentication.
- Exploitation involves manipulating Looker’s Git workflows and internal database connections, which can be difficult to detect with standard security tools.
- Google has patched cloud-hosted Looker instances, but self-hosted or on-premises deployments remain at high risk until manual updates are applied.
- Compromising Looker can provide attackers with broad visibility into sensitive data and internal networks, making it a high-value target.
Tenable Research has disclosed two critical vulnerabilities in Google Looker, collectively dubbed “LookOut,” that could allow attackers to take full control of vulnerable systems or siphon off sensitive corporate data from one of the world’s most widely deployed business intelligence platforms.
Looker is used by more than 60,000 organizations across 195 countries, often serving as a centralized analytics layer connected to an enterprise’s most sensitive databases. According to Tenable, that central role dramatically magnifies the potential impact of exploitation, particularly for organizations running customer-hosted or on-premises Looker instances, which are not automatically protected by Google’s cloud-side patches.
A ‘Keys to the Kingdom’ Remote Code Execution Chain
The most severe finding uncovered by Tenable researchers is a remote code execution (RCE) chain that could allow an attacker to execute arbitrary commands on a Looker server without authentication. Successful exploitation would effectively grant an adversary administrative-level access to the environment.
“This level of access is particularly dangerous because Looker acts as a central nervous system for corporate information,” said Liv Matan, Senior Research Engineer at Tenable, who led the research. “A breach could allow an attacker to manipulate data, steal sensitive secrets, or pivot deeper into a company’s private internal network.”
In cloud-hosted environments, the RCE chain also introduced the possibility of horizontal movement within shared infrastructure, creating a pathway toward cross-tenant exposure under specific conditions. While Tenable emphasized that Google’s underlying cloud isolation mechanisms remain largely sound, the research underscores that application-layer vulnerabilities can undermine tenant separation by enabling host-level access.
Forcing Native Git to Enable Exploitation
A key component of the exploit involved manipulating Looker’s Git usage. While Looker typically relies on JGit, which does not support Git hooks, Tenable researchers identified a narrow workflow that forces Looker to fall back to the native Git client.
By carefully crafting repository interactions through Looker’s API, attackers could exploit a race condition that enabled malicious Git hooks to execute. Once triggered, those hooks could run arbitrary code on the Looker server.
According to Tenable, this exploitation path would be difficult to detect with traditional SOC monitoring tools, as the activity could appear indistinguishable from legitimate Git operations unless organizations monitor for high-frequency file write/delete behavior or use endpoint detection tools with granular file-integrity controls.
Second Flaw Enables Full Theft of Looker’s Internal Database
In addition to RCE, Tenable identified a second vulnerability that allows attackers to exfiltrate Looker’s internal management database—described by researchers as the platform’s “private brain.”
By abusing internal database connections and leveraging error-based SQL injection techniques, an attacker could extract sensitive information, including:
-
User credentials
-
Configuration secrets
-
Internal operational metadata
“This vulnerability essentially tricks Looker into connecting to itself and spilling its most sensitive data,” Matan explained. “Once exploited, the attacker could download the entire internal database.”
Cloud Customers Patched But Others Remain Exposed
Google moved quickly to remediate vulnerabilities affecting Looker SaaS customers hosted on Google Cloud, significantly reducing risk for organizations using the fully managed service.
However, Tenable warns that organizations running self-hosted Looker deployments—either on-premises or in private cloud environments—remain at high risk until patches are manually applied.
“This research highlights a persistent patching gap,” Matan said. “While Google secured its managed environment, customer-hosted instances place the full burden of infrastructure security on the organization. Until patched, those systems remain vulnerable to complete administrative takeover.”
Why BI Platforms Are High-Value Targets
Unlike many enterprise applications, business intelligence platforms sit at the intersection of data access, analytics, and operational decision-making. Looker often maintains trusted connections to nearly every major database inside an organization.
From an attacker’s perspective, compromising a BI platform can provide:
-
Broad visibility into sensitive business data
-
Access to embedded credentials and service accounts
-
A stealthy pivot point into internal networks
“These vulnerabilities acted like a master key,” Matan noted. “Once inside Looker, an attacker could potentially access everything Looker connects to.”
Indicators of Compromise Organizations Should Review
Tenable advises security and IT teams—particularly those managing self-hosted Looker deployments—to immediately assess their environments for signs of exploitation. Recommended indicators of compromise (IOCs) include:
Suspicious Git Hook Files
Inspect Looker project directories for unauthorized files in the .git/hooks/ path, especially scripts named:
-
pre-push
-
post-commit
-
applypatch-msg
Internal Database Abuse
Review application logs for unusual SQL errors or patterns consistent with error-based SQL injection attempts targeting internal Looker database connections, such as looker__ilooker.
A Broader Lesson for SaaS and Hybrid Environments
While the LookOut vulnerabilities have been addressed in Google’s managed service, Tenable’s research serves as a broader warning for security leaders relying on hybrid or self-hosted deployments of critical business applications.
“The security of powerful analytics platforms is incredibly difficult to balance,” Matan said. “They need deep access to data while also remaining tightly locked down. This research shows how small architectural edge cases can have outsized consequences.”
A full technical breakdown of the LookOut vulnerabilities is available on the Tenable Research blog.
What CISOs Should Do Now
The disclosure of Tenable’s “LookOut” vulnerabilities in Google Looker underscores a broader challenge for security leaders: business intelligence platforms often provide deep data access but limited visibility into security. CISOs should take the following immediate and near-term actions to reduce exposure.
1. Confirm Your Looker Deployment Model
First, determine whether your organization is running:
-
Google-managed Looker SaaS, or
-
Customer-hosted Looker (on-premises or private cloud)
Only the Google-managed SaaS environment received automatic remediation. Customer-hosted instances remain vulnerable until patches are manually applied.
2. Patch Immediately—Then Validate
If you operate a self-hosted Looker instance:
-
Apply all available security updates from Google without delay
-
Validate patch effectiveness by testing for known exploit paths, not just version numbers
-
Document patch status as part of your vulnerability management program
Delayed patching in analytics platforms can equate to full administrative compromise.
3. Audit Git Usage Inside Looker
Looker’s reliance on Git for development workflows introduces an often-overlooked attack surface.
-
Inspect Looker project directories for unauthorized files in .git/hooks/
-
Pay special attention to scripts such as pre-push, post-commit, or applypatch-msg
-
Restrict repository creation and API-driven Git interactions where possible
4. Review Logs for Internal Abuse Indicators
Security teams should analyze application logs for:
-
Unusual SQL errors involving internal Looker database connections
-
Patterns consistent with error-based SQL injection
-
Unexpected internal service-to-service connections
These indicators may signal attempted or successful exploitation of Looker’s internal management database.
5. Treat BI Platforms as Tier-One Assets
Many organizations under-classify analytics platforms in their security architecture.
-
Include BI systems like Looker in Tier 1 asset inventories
-
Apply endpoint detection, file integrity monitoring, and privileged access controls
-
Monitor for lateral movement originating from the analytics infrastructure
6. Reassess SaaS vs. Self-Hosted Risk
Finally, use this incident to reassess whether customer-hosted deployments still align with your risk tolerance.
-
Managed SaaS environments reduce patching and infrastructure risk
-
Self-hosted deployments require disciplined operational security and continuous monitoring
-
Ensure ownership of patching and configuration security is clearly defined
Bottom line: If your BI platform is compromised, your data and often your entire internal network may already be at risk. LookOut is a reminder that analytics systems deserve the same security rigor as identity, cloud, and core infrastructure platforms.
About the Author
Steve Lasky
Editorial Director, Editor-in-Chief/Security Technology Executive
Steve Lasky is Editorial Director of the Endeavor Business Media Security Group, which includes SecurityInfoWatch.com, as well as Security Business, Security Technology Executive, and Locksmith Ledger magazines. He is also the host of the SecurityDNA podcast series. Reach him at [email protected].


