Untrusted.env processing enables arbitrary code execution in Google Cloud Gemini CLI and run-gemini-cli GitHub Action

A vulnerability in the Gemini CLI and associated GitHub Action allowed an unprivileged attacker to achieve an arbitrary code execution in Gemini CLI via untrusted local.env files overriding GEMINI_CLI_HOME.

• Google Cloud Gemini CLI: The normalized record identifies versions less than 0.39.1 as affected. The vendor advisory additionally identifies the parallel preview branch less than 0.40.0-preview.3 as affected. The patched versions named by the advisory are 0.39.1 and 0.40.0-preview.3.
• Google Cloud run-gemini-cli GitHub Action: Versions less than 0.1.22 are affected; 0.1.22 is the fixed version identified by the advisory and normalized record.
• The status of other branches or versions not listed in the reviewed evidence remains unverified. Do not infer that every later version is safe solely because a fixed release exists.

Gemini CLI automatically loads environment variables from .env files and uses GEMINI_CLI_HOME to select the root directory for user-level configuration and storage. The record identifies a path in which untrusted local .env content can override that variable, allowing workspace-controlled input to influence the CLI's configuration and trust context. The vendor advisory describes the related headless behavior: earlier versions automatically trusted workspace folders, which allowed configuration and environment variables in untrusted directories to be processed and could lead to remote code execution. The patched behavior requires explicit folder trust before configuration files such as .env are processed and also improves tool allowlisting under --yolo. The normalized record classifies the weakness as improper input validation and improper neutralization of special elements used in an OS command. Exploitation requires the attacker to cause the CLI or GitHub Action to process an untrusted workspace or local data; the precise internal function or command construction responsible is not publicly established.

The attack path can be reached remotely through CI or other automation that processes attacker-controlled workspace data, such as an untrusted pull request, issue or repository. The record describes an attack requiring no special privileges and no user interaction, but the practical precondition remains that untrusted data or files reach the vulnerable run. The vendor advisory focuses on Gemini CLI in headless mode and GitHub Actions that process untrusted data. The supplied evidence does not establish exploitation in the wild, a public exploit or ransomware use; empty status fields are not evidence that those activities do not exist.

• The primary technical outcome is arbitrary code execution in the Gemini CLI process or the GitHub Action execution environment.
• An attacker may be able to read data, alter content or disrupt services within the process's permissions; if the runner has broad access, the effect may extend to related CI/CD or repository resources.
• The concrete scope depends on the execution identity, available credentials, workflow design and whether untrusted workspace data is processed.
• The vulnerability does not establish that every Gemini CLI deployment is affected: an affected version and a matching path for processing untrusted data or files are required.

• Successful code execution could run with the permissions of the Gemini CLI process or GitHub runner, potentially allowing workspace data to be read, source code to be changed, artifacts to be modified or jobs to be disrupted.
• If a workflow exposes credentials, tokens or broad GitHub permissions, the effect could extend to CI/CD resources and repositories accessible to the runner.
• The actual business impact depends on runner permissions, loaded credentials and the data processed by the workflow; the record does not identify a specific breach or data disclosure.

1. Upgrade Google Cloud Gemini CLI to 0.39.1 or 0.40.0-preview.3, according to the branch in use, and upgrade the run-gemini-cli GitHub Action to 0.1.22. If a workflow sets gemini_cli_version, update that value rather than relying on the action's default.
2. Review the trust model for each workflow. For fully trusted data, the current CLI documentation uses GEMINI_CLI_TRUST_WORKSPACE=true to trust the workspace in headless execution. For untrusted data, set this only after hardening the workflow; the original record names GEMINI_TRUST_WORKSPACE, so verify the variable name against current CLI documentation instead of copying older configuration unchanged.
3. For workflows processing untrusted data, apply least privilege to GitHub tokens and credentials, limit automatic triggers from forks or external content, and allowlist only the tools and commands that are required.
4. Review runs that used affected versions. If they could access credentials or sensitive resources, assess possible exposure and follow incident response procedures, including credential rotation where appropriate.

• Inventory all @google/gemini-cli installations and workflows using run-gemini-cli, including any version pinned through gemini_cli_version.
• Identify headless workflows and review their data sources, especially pull requests, issues, forks or workspaces supplied by external parties.
• Inspect repositories and working directories for .env files, .gemini directories and settings that define GEMINI_CLI_HOME. Determine whether untrusted input can modify or introduce those files.
• Review workflow definitions for --yolo, broad tool allowlists or GitHub token permissions beyond the job's requirements.
• Review affected run logs for unexpected shell commands, file operations or credential access. This is precautionary monitoring, not a confirmed IOC, and the absence of unusual log entries does not prove that a system is safe.