CVSS 10.0: Gemini CLI auto-trust flaw turns fork PRs into CI RCE

TL;DR - In headless CI mode, @google/gemini-cli automatically trusted the checked-out workspace. An attacker submitting a fork PR could drop a .gemini/ directory into the repo and get their configuration loaded by the agent - resulting in command execution on your CI runner.

What happened

@google/gemini-cli is Google's command-line AI agent, wired into automation via google-github-actions/run-gemini-cli. Teams use it to run AI-assisted tasks inside GitHub Actions.

The problem: older versions running in non-interactive (headless) mode automatically trusted the checked-out workspace. That trust decides whether local configuration and environment variables get loaded. In workflows that run on untrusted content - fork pull requests are the obvious case - an attacker can commit a .gemini/ directory to the repo. The agent picks it up, loads attacker-controlled configuration, and executes commands on the CI host.

A second issue in the same disclosure compounds the risk. When --yolo mode is active, the CLI previously ignored fine-grained tool allowlists from ~/.gemini/settings.json. If a workflow allowlisted run_shell_command with tight subcommand restrictions, --yolo silently widened that into arbitrary execution. Prompt injection becomes a direct RCE path.

This is the trust boundary failure that AI-in-CI introduces: repo contents and executable agent configuration share the same workspace. When the agent doesn't distinguish between them, an untrusted PR is a code execution primitive.

Who is impacted

• Workflows using google-github-actions/run-gemini-cli with Gemini CLI running in headless mode.
• Pipelines that execute against untrusted repository contents - particularly those triggered by fork pull requests, where an attacker can add or modify .gemini/ content in the workspace.
• Any automation using --yolo mode on untrusted inputs, especially if you relied on narrow run_shell_command allowlists for safety.

What to do now

• Update immediately. Patch to @google/gemini-cli >= 0.39.1 (or >= 0.40.0-preview.3 on the preview track) and google-github-actions/run-gemini-cli >= 0.1.22.
• Inventory your exposure:
  • search workflow repos for google-github-actions/run-gemini-cli
  • search CI scripts for @google/gemini-cli installation or invocation
  • flag any usage of --yolo
• Set workspace trust explicitly. Follow Google's remediation guidance on the GEMINI_TRUST_WORKSPACE environment variable:
  • if the workflow runs on trusted inputs only, set GEMINI_TRUST_WORKSPACE: 'true'
  • if the workflow runs on untrusted inputs (fork PRs, external contributors), apply the hardening guidance for google-github-actions/run-gemini-cli and set the variable as directed
• Reduce blast radius while you roll out changes:
  • stop running Gemini CLI against PRs from forks unless the workflow is explicitly hardened for that threat model
  • audit repositories for unexpected .gemini/ directories or configuration changes introduced via PRs
  • treat any runner secrets present in affected workflows as potentially exposed if a malicious PR may have executed