Critical Gemini CLI flaw lets attackers run code remotely
Key Takeaways A critical remote code execution (RCE) vulnerability has been discovered in Google’s Gemini CLI. The flaw primarily impacts automated workflows, such as CI/CD pipelines, that...
Key Takeaways
- A critical remote code execution (RCE) vulnerability has been discovered in Google’s Gemini CLI.
- The flaw primarily impacts automated workflows, such as CI/CD pipelines, that utilize the
@google/gemini-clinpm package or thegoogle-github-actions/run-gemini-cliGitHub Action. - Attackers could exploit this vulnerability by introducing malicious content into untrusted repositories or through prompt injection, leading to arbitrary code execution.
- Google has released patches for the affected components, and users are urged to upgrade immediately.
Critical Flaw in Google Gemini CLI Poses Remote Code Execution Risk to Automated Workflows
Google has addressed a significant security vulnerability within its Gemini Command Line Interface (CLI) that could enable attackers to execute arbitrary code remotely. This critical flaw primarily jeopardizes automated workflows, particularly those operating in headless environments like CI/CD pipelines, by allowing the execution of malicious code under specific conditions.
Table Of Content
The vulnerability impacts the @google/gemini-cli npm package and the google-github-actions/run-gemini-cli GitHub Action. It stems from a combination of two distinct weaknesses: insecure handling of workspace trust and an insufficient enforcement of tool allowlisting when operating in “yolo” mode. Together, these issues create a pathway for attackers to compromise systems that process untrusted external content, such as pull requests or user-submitted issues.
Unsafe Workspace Trust in Headless Mode
One core aspect of the vulnerability involves how the Gemini CLI managed folder trust in headless environments. Previously, when running in a non-interactive mode, the CLI would automatically trust the current workspace. This implicit trust meant that the tool would load local configuration files and environment variables from the .gemini/ directory without requiring explicit approval.
This behavior presented a significant security risk. An attacker could strategically place malicious content within this directory in an untrusted repository. When the Gemini CLI processed this repository in an automated workflow, it would then execute the harmful commands embedded in the malicious content, effectively leading to remote code execution within the CI environment.
Bypass of Tool Allowlisting in “Yolo” Mode
The second contributing factor to the vulnerability concerns the tool allowlisting mechanism when the –yolo mode was activated. In prior versions, the CLI failed to properly enforce the fine-grained tool restrictions defined in the ~/.gemini/settings.json file when –yolo was enabled. This oversight could lead to a broad interpretation of allowed commands.
For instance, if a workflow permitted the run_shell_command, the insufficient enforcement could allow dangerous, unapproved commands to be executed instead of strictly adhering to the pre-defined, safe ones. In environments that interact with untrusted prompts or user-controlled text, this weakness was susceptible to prompt injection attacks, which could then trigger arbitrary command execution.
Google’s advisory clarifies that the impact of this vulnerability is confined to Gemini CLI deployments configured in headless mode. However, this still encompasses a substantial number of GitHub Actions workflows that automate development processes. Google strongly advises all users to meticulously review how the Gemini CLI is configured within their automation pipelines, especially those where external contributors can influence files, prompts, or environmental settings.
Patch Availability and New Security Measures
Patched versions are now available to mitigate these risks. Users of the @google/gemini-cli npm package should upgrade to the latest secure version. Similarly, the run-gemini-cli GitHub Action has been patched in its latest release. Any workflows that specifically pin older versions of the Gemini CLI must be updated without delay.
In a significant security change, Google has altered the default behavior of headless mode. It will no longer automatically trust workspace folders. Organizations utilizing trusted inputs must now explicitly set GEMINI_TRUST_WORKSPACE: 'true' to maintain previous functionality. For workflows that handle untrusted content, Google recommends adhering to its enhanced hardening guidance and diligently reviewing all allowed tools and command execution settings.
The vulnerability was identified and reported by Elad Meged of Novee Security and Dan Lisichkin of Pillar Security through Google’s Vulnerability Rewards Program. This incident underscores the escalating security challenges associated with AI-powered developer tools, particularly when automation, prompt handling, and shell access converge with untrusted inputs, turning seemingly minor policy gaps into critical attack vectors.
What You Should Do
- Upgrade Immediately: Update the
@google/gemini-clinpm package to the latest patched version. - Update GitHub Actions: Ensure that the
google-github-actions/run-gemini-cliGitHub Action is updated to its latest secure release. Review and update any workflows that explicitly pin older, vulnerable Gemini CLI versions. - Review Headless Configurations: For headless Gemini CLI deployments, especially in CI/CD pipelines, meticulously review how workspace trust is managed.
- Explicitly Set Trust for Trusted Workflows: If your workflows process only trusted inputs, explicitly set
GEMINI_TRUST_WORKSPACE: 'true'. - Harden Untrusted Workflows: For workflows that process untrusted content (e.g., external pull requests), follow Google’s hardening guidance. Carefully review and restrict allowed tools and command execution settings to minimize potential attack surfaces.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.