Remote Command Execution in Google Cloud with Single Directory Deletion Posted on March 23, 2026 • 9 minutes • 1823 words Table of contents Introduction TL;DR About Looker Technical Details Git Integration in Looker Improper Validation in Directory Deletion Internals of FileUtils.rm_rf Controlling Deletion Order Remote Command Execution Privilege Escalation Against Other Looker Instances Conclusion Shameless Plug Introduction Hello, I’m RyotaK ( @ryotkak ), a security engineer at GMO Flatt Security Inc. A while ago, I participated in the Google Cloud VRP bugSWAT, a live hacking event organized by Google. During this event, I discovered a remote command execution vulnerability in one of Google Cloud’s services. As the vulnerability has now been fixed, I would like to share the technical details in this article. TL;DR Google Cloud has a product called Looker, and this product has a feature to manage Git repositories. When a user deletes a directory, Looker improperly validates the target directory, making it possible to delete the directory containing the repository itself. Since other Git operations can be performed concurrently, it was possible to trigger Git-related operations during the directory deletion process. By exploiting this race condition, an attacker could execute arbitrary commands on the Looker server. While instances were isolated using Kubernetes, misconfigurations in the Looker service account permissions could allow privilege escalation to access other instances within the same Kubernetes cluster. After reporting the vulnerability to Google, they fixed both the remote command execution vulnerability and the privilege escalation vulnerability. About Looker Looker is a business intelligence (BI) and data analytics platform that is part of Google Cloud. It enables organizations to explore, analyze, and visualize their data through interactive dashboards and reports. Looker connects to various data sources, allowing users to create custom data models and perform analytics. Looker has two types of the deployment, cloud-hosted and self-hosted. Since I could obtain the self-hosted Looker instance for the Google Cloud VRP bugSWAT event, I focused on reverse engineering the self-hosted Looker. Technical Details Git Integration in Looker Looker provides a feature to manage model files called LookML in Git repositories (Looker calls them projects). Users can pull or push changes to Git repositories, and Looker applies the changes accordingly. To integrate with external Git services, Looker typically uses the JGit library (a pure Java implementation of Git). However, when the remote Git repository is configured over SSH, Looker uses the native Git command-line tool instead of JGit. It creates the checked-out repository under a specific directory on the Looker server and executes Git commands against that directory. def self . _cli_git_command (working_directory, command_words) [...] command_with_dir = "cd #{ working_directory } && #{ command } " Looker :: Log . log_block_latency( :git , "_cli_git_command: command: #{ command_with_dir } " ) do Open3 . capture3(command_with_dir) end [...] In addition to standard Git operations, Looker has a feature to manage files from the Web UI. Users can create, edit, and delete files or directories from the Looker interface. Improper Validation in Directory Deletion When a user deletes a directory, Looker executes the following code: post( "/api/internal/projects/:project_id/delete_dir" ) do | _project_id | [...] dir_path_array = body [ "dir_path_array" ] @project . delete_dir(dir_path_array) [...] def delete_dir (dir_path_array) dir_name = dir_path_array . reject( & :empty? ) . join( "/" ) dir_name = validate_dir_name(dir_name) dir_path = File . join(path, dir_name) [...] FileUtils . rm_rf(dir_path) The validate_dir_name method ensures that reserved directories cannot be tampered with: def validate_dir_name (dir_name) [...] if path_array . include?(Looker :: Model :: Project :: DOT_GIT) raise (InvalidFileNameError . new( "New path cannot include .git" )) else nil end File . join(path_array . map do | s | Looker :: Utils . sanitize_file_or_dir_name(s) HellToolJava end ) end Since it’s possible to trick Git into using forged Git configurations if the .git directory is corrupted or deleted, the validate_dir_name method checks if the directory to be deleted includes .git and raises an error if it does. For example, consider a repository with the following structure: --- .git directory (Can't be controlled by the user) --- .git/ HEAD config ... --- worktree (Controllable by the user) --- HEAD config objects/ refs/ If the .git directory is deleted, the next Git command executed against this repository will fail to find the .git directory and will look for Git configurations in the worktree directory instead. Therefore, if the worktree contains files that resemble the contents of a .git directory, Git commands will use those configurations. For instance, if the following ...