Skip to content

Gemini CLI: Remote Code Execution via workspace trust and tool allowlisting bypasses

Critical severity GitHub Reviewed Published Apr 24, 2026 in google-github-actions/run-gemini-cli • Updated Apr 25, 2026

Package

npm @google/gemini-cli (npm)

Affected versions

< 0.39.1
= 0.40.0-preview.2

Patched versions

0.39.1
0.40.0-preview.3
actions google-github-actions/run-gemini-cli (GitHub Actions)
< 0.1.22
0.1.22

Description

Summary

Gemini CLI (@google/gemini-cli) and the run-gemini-cli GitHub Action are being updated to harden workspace trust and tool allowlisting, in particular when used in untrusted environments like GitHub Actions. This update introduces a breaking change to how non-interactive (headless) environments handle folder trust, which may impact existing CI/CD workflows under specific conditions.

Details

Folder Trust in Headless Mode

In previous versions, Gemini CLI running in CI environments (headless mode) automatically trusted workspace folders for the purpose of loading configuration and environment variables. This is potentially risky in situations where Gemini CLI runs on untrusted folders in headless mode (e.g. CI workflows that review user-submitted pull requests). If used with untrusted directory contents, this could lead to remote code execution via malicious environment variables in the local .gemini/ directory.

To ensure consistency and user control, the latest update aligns headless mode behavior with interactive mode, requiring folders to be explicitly trusted before configuration files (such as .env) are processed.

As a result of this change, GitHub Actions and other automated pipelines that rely on the previous automatic trust behavior will fail to load workspace-specific settings until they are updated to use explicit trust mechanisms.

Tool Allowlisting under --yolo

In previous versions, when Gemini CLI was configured to run in --yolo mode, it would ignore any fine grained tool allowlist in ~/.gemini/settings.json (e.g. run_shell_command(echo) would allow any command). This is potentially risky in situations where Gemini CLI runs on untrusted inputs with --yolo (e.g. CI workflows that triage user-submitted GitHub issues where we recommend a strict allowlist). If used with untrusted content and a tool allowlist that permits run_shell_command, this could lead to remote code execution via prompt injection.

In version 0.39.1, the Gemini CLI policy engine now evaluates tool allowlisting under --yolo mode, which is useful for CI workflows that allowlist a few safe commands to run when processing untrusted inputs. As a result, some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task.

Impact

This impact is limited to workflows using Gemini CLI in headless mode. Any use of Gemini CLI in headless mode without folder trust will require manual review to correctly configure folder trust. This affects all Gemini CLI GitHub Actions. Users must review their workflows, and take one of two approaches:

1. If the workflow runs on trusted inputs (e.g. reviewing PRs from trusted collaborators), set GEMINI_TRUST_WORKSPACE: 'true' in your workflow.

2. If the workflow runs on untrusted inputs, review our guidance in google-github-actions/run-gemini-cli to harden your workflow against malicious content, and set the environment variable.

Patches

The folder trust and tool allowlisting mitigations are available in @google/gemini-cli version 0.39.1 and 0.40.0-preview.3. By default, the run-gemini-cli GitHub Action will receive and run the latest version of gemini-cli. However, if your workflow specifies a version of gemini-cli by setting the gemini_cli_version, you are encouraged to upgrade to one of the patched versions and audit the workflow settings that use Gemini CLI.

Credits

Gemini thanks the following security researchers for reporting this issue through the Vulnerability Rewards Program (g.co/vulnz):

  • Elad Meged, Novee Security
  • Dan Lisichkin, Pillar Security research team

References

Published to the GitHub Advisory Database Apr 24, 2026
Reviewed Apr 24, 2026
Last updated Apr 25, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

EPSS score

Weaknesses

Improper Input Validation

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. Learn more on MITRE.

Improper Neutralization of Special Elements used in a Command ('Command Injection')

The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component. Learn more on MITRE.

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Learn more on MITRE.

CVE ID

No known CVE

GHSA ID

GHSA-wpqr-6v78-jr5g

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.