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
- Product
- Gemini CLI
- Identifier / CWE
- CVE-2026-12537
CWE-20, CWE-78 - Action timing
- Immediate
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.
- 01Untrusted folder checked out
A CI job checks out a repository containing an attacker-crafted .gemini/.env file, for example from a pull request.
- 02Headless mode auto-trusts
Gemini CLI running in headless mode automatically trusted the workspace folder and loaded its configuration and environment variables.
- 03Malicious env processed
The crafted .gemini/.env content is processed before sandbox protections are in place.
- 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
- Upgrade to @google/gemini-cli 0.39.1 or later; if your workflow pins gemini_cli_version, update the pin.
- 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.
- Review tool allowlists used with –yolo mode, since allowlisting is now enforced and previously permissive workflows may behave differently.
- 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.