High priorityDisclosed

Advisory · CVE-2026-12537

Gemini CLI trusts poisoned folders before its sandbox

Gemini CLI in headless CI mode auto-trusted workspace folders, so a malicious .gemini/.env file could execute code on the host before sandboxing applied.

Vendor
Google
Product
Gemini CLI
Identifier / CWE
CVE-2026-12537
CWE-20, CWE-78
Action timing
Immediate
ELI5

Explain it like I’m five

The robot assistant reads any instruction notes left lying in a folder before it puts on its safety gloves. A booby-trapped note can make it do something dangerous while its gloves are still off.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Untrusted folder checked out

    A CI job checks out a repository containing an attacker-crafted .gemini/.env file, for example from a pull request.

  2. 02Headless mode auto-trusts

    Gemini CLI running in headless mode automatically trusted the workspace folder and loaded its configuration and environment variables.

  3. 03Malicious env processed

    The crafted .gemini/.env content is processed before sandbox protections are in place.

  4. 04Host code runs

    The attacker achieves pre-sandbox, host-level code execution on the CI runner.

What happened

Google’s advisory GHSA-wpqr-6v78-jr5g describes a trust-model flaw in Gemini CLI (@google/gemini-cli) and the run-gemini-cli GitHub Action. In headless (CI) mode, Gemini CLI automatically trusted workspace folders for loading configuration and environment variables. On untrusted folders, such as CI workflows reviewing user-submitted pull requests, a maliciously crafted .gemini/.env file could lead to pre-sandbox host-level code execution. The same advisory hardens tool allowlisting under –yolo mode, which previously ignored fine-grained allowlists. The mitigations ship in @google/gemini-cli 0.39.1 (and 0.40.0-preview.3); the run-gemini-cli action picks up the latest CLI by default unless a version is pinned. NVD rates the issue CVSS 4.0 10.0. There is no confirmed public exploitation at the time of writing.

What to do

  1. Upgrade to @google/gemini-cli 0.39.1 or later; if your workflow pins gemini_cli_version, update the pin.
  2. For workflows on trusted inputs only, set GEMINI_TRUST_WORKSPACE to ‘true’ explicitly; for workflows on untrusted inputs, follow Google’s hardening guidance for the action instead of blanket-trusting the workspace.
  3. Review tool allowlists used with –yolo mode, since allowlisting is now enforced and previously permissive workflows may behave differently.
  4. Audit recent CI runs that executed Gemini CLI against untrusted content for signs of unexpected commands or exfiltration.

Management note

AI coding agents in CI are a new privileged actor in the build pipeline, and this flaw shows the trust model had not caught up: untrusted repository content was treated as configuration before the sandbox existed. The patch is easy, but the strategic fix is treating AI agent workflows like any other code that processes untrusted input, with explicit trust decisions instead of convenient defaults.