Nate Nelson, Contributing Writer February 4, 2026 5 Min Read Source: Postmodern Studio via Alamy Stock Photo Researchers have identified two five-alarm security issues in a popular Google data service, either of which could allow attackers access to sensitive secrets useful for rampant lateral movement. Looker — not to be confused with the more pared down Looker Studio — is a heavyweight business intelligence and data analytics platform. It's basically a dashboard for modeling data, creating visualizations, and more. According to data aggregator TheirStack, it's used by more than 60,000 companies , including brand names like Wayfair, Coinbase, and Walmart. "In a typical enterprise, Looker isn't just a dashboard — it is the central nervous system for data," says Liv Matan, senior research engineer at Tenable. It makes for an ideal target for cyberattacks, he says, not least because "a standard organization might have Looker connected to 20 to 50-plus data sources, ranging from massive warehouses like BigQuery to sensitive operational databases like PostgreSQL and MySQL." On Feb. 4, Matan described a remote code execution (RCE) chain in Looker that could allow an attacker to reach the infrastructure it's running on and even, in cloud deployments, gain access to other tenants. He also described a separate SQL injection vulnerability useful for accessing all that data the program manages. Exfiltration of Database Secrets The first, less severe of the two findings concerns Looker's internal database, which stores user lists, secrets, and configurations. It's supposed to be concealed from the user. The researchers found the name of the internal database's connection in logs, though, and took advantage. They created a new project, intercepted the HTTP request in transit, and modified the parameter that pointed to their own allowed database to instead point to the sensitive hidden one. Now they had a connection to it, but not yet a way to view what was inside. For that they performed error-based SQL injection , running queries that they knew would trigger error messages, yet within the error messages were the real, secret data they sought. By doing this over and over again, theoretically, they could have slowly dumped the entire contents of the internal database. A malicious actor could use this vulnerability to steal secrets and configurations and perform follow-on attacks inside of Looker. It's now being tracked as CVE-2025-12743, and it earned a mid-grade Common Vulnerability Scoring System (CVSS) rating of 6.0 out of 10. Cross-Tenant RCE in Google Looker More significantly, Matan and his colleagues developed an exploit chain allowing them to run arbitrary code on a Looker server. They began with a path traversal. Every Looker project is a Git repository at heart, and by crafting their own remote dependency, they were able to manipulate where the Git system looks for "hooks" — powerful scripts that run automatically when certain events occur. The researchers pointed the system to a directory they controlled, tricking Looker into downloading their own custom hooks that, when run, would execute a remote shell for their enjoyment. This actually didn't work at first. It turned out that Looker uses a specific version of Git called "JGit," by default, which doesn't support Git hooks. They looked harder, though, and found a way to make Looker use Git instead of JGit, by using specific POST parameters when creating their repository. That wasn't the only problem. Before running any Git commands, Looker overwrites the Git config file, resetting the hooks path the researchers had manipulated back to a safe state. To overcome this they triggered a race condition, spamming the program to sneak their malicious overwrite in between the time when Looker reset the config file to a safe state, and when it was time to run hooks. This worked after a few tries. As a result, the researchers were able to run whatever code they wanted on the Looker server. They could have accessed highly sensitive data or performed lateral movement in the compromised target's environment, for starters. Worst of all, though, they found that on the Google Cloud Platform (GCP) , because multiple customers might run Looker on the same infrastructure — with shared folders housing service account credentials — an attacker with RCE on the server could also access other organizations' cloud environments and data, too. The Challenge in Patching Looker Google fixed the two issues in Looker shortly after Tenable first reported them. Organizations that deploy it on-premises will need to update manually to one of the versions deemed secure in Google's security bulletin GCP-2025-052 . Doing so won't be trivial. "It requires significant time and technical effort. Because Looker acts as a central nervous system for a company's most sensitive data, some organizations may delay updating because they fear accidental system downtime or technical glitches that could disrupt their business," Matan says. There are other reasons to delay. "Organizations often face logistical roadblocks like rigid change management windows that forbid system updates during peak business hours. They may also need extended time for compatibility testing to ensure the patch doesn’t break custom connections to other databases or third-party tools," adds Matan. "Furthermore, a lack of a clear asset inventory can lead to shadow IT, where hidden or forgotten instances of the software remain unpatched simply because the central IT team isn't aware they exist." Patching isn't a be-all and end-all , either. Organizations would be well advised to always practice the principle of least privilege and isolate their Looker instances as they would any other high-risk assets. "Put it in a dedicated network segment so that even if it's compromised, an attacker can't easily reach your core domain controllers or other servers," Matan says. About the Author Nate Nelson, Contributing Writer Nate Nelson is a journalist and scriptwriter. He writes for "Darknet Diaries" — the most popular podcast in cybersecurity — and co-created the former Top 20 tech podcast "Malicious Life." Before joining Dark Reading, he was a reporter at Threatpost. See more from Nate Nelson, Contributing Writer