Tenable finds critical flaws in Google Looker platform

Tenable has disclosed two security flaws in Google Looker that could be used to take control of servers or extract sensitive internal data from the business intelligence platform.

The research, branded "LookOut," focuses on weaknesses in Looker deployments. Looker is used by more than 60,000 organisations across 195 countries and sits close to corporate reporting and analytics workflows, often connecting to internal databases and cloud data stores.

One issue is a remote code execution chain that could allow an attacker to run commands on a Looker server from a remote location. That level of access could enable an intruder to steal secrets, modify data, or move laterally across a company network.

In some hosted environments, Tenable said the flaw could increase the risk of cross-tenant impact. Tenable did not name affected customers or provide a public estimate of in-the-wild exploitation.

"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, Tenable.

Database exposure

The second flaw concerns Looker's internal management database. Tenable said it extracted the database by having the system connect back to an internal component it described as Looker's "private brain."

The database can include user credentials and configuration secrets. Tenable said its technique relied on an error-based SQL injection pattern against internal Looker database connections, including one it identified as looker__ilooker.

Stolen database contents can create follow-on risk beyond the analytics layer. Credentials and configuration data can expose access to other systems, particularly when service accounts have broad privileges or credentials are reused across environments.

Patch status

Google has applied fixes in its managed cloud service, according to Tenable. The remaining concern is for organisations running Looker on-premises or in private cloud deployments, where administrators control patching and upgrades.

Those customers must apply updates manually. Failure to patch could leave systems vulnerable to administrative takeover, underscoring the operational risk of self-managed deployments of complex data platforms.

Looker is widely used as a reporting interface that sits above data warehouses and operational databases. That position often gives the application network access to data sources and can place it on trusted network segments. Attackers who gain control of such a server may establish a foothold that is difficult to detect, particularly if the intrusion blends into normal query activity.

Detection guidance

Tenable outlined indicators administrators can use to check for exploitation attempts. It advised teams to inspect Looker project folders for unexpected files in the .git/hooks/ directory.

Scripts named pre-push, post-commit, or applypatch-msg warrant attention if they appear unexpectedly. Such files can trigger command execution during routine developer workflows if an attacker places them in a project directory.

Tenable also recommended examining application logs for signs of internal connection abuse, including unusual SQL errors or patterns consistent with error-based SQL injection targeting internal database connections.

Wider implications

The disclosures add to a growing list of security concerns around tools that combine broad data access with features that allow user-defined queries. Analytics platforms need to provide flexible access to data sources while maintaining strict boundaries between user activity and the underlying management plane.

Organisations also continue to face uneven patching across hybrid estates. Managed services often receive vendor patches quickly, while private deployments can lag due to change control processes, testing requirements, and dependencies on other components.

"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.