CVSS 10.0 in Gemini CLI: A Pull Request Was Enough to Execute Code on the Host Before the Sandbox Started
Researchers at Novee Security and Pillar Security disclosed a CVSS 10.0 remote code execution vulnerability in Google Gemini CLI and the run-gemini-cli GitHub Action. Google assigned maximum severity and shipped patches in @google/gemini-cli v0.39.1 and v0.40.0-preview.3 on April 29, 2026. The run-gemini-cli GitHub Action was patched in v0.1.22.
The flaw
In headless mode — the configuration used in CI/CD pipelines — Gemini CLI automatically trusted the current workspace folder and loaded any agent configuration files it found there. No review, no sandboxing, no user approval.
An attacker who could place content into a repository’s workspace had a direct path: submit a pull request containing a malicious .gemini/ configuration file, and the agent would load and execute it on the host before its sandbox ever initialized.
“This vulnerability had nothing to do with prompt injection or the model deciding to act maliciously,” Novee researcher Elad Meged wrote. “It was an infrastructure-level issue, where attacker-controlled content was silently accepted as trusted configuration and executed before any sandbox was initialized.”
The impact was consistent across every affected workflow Novee tested: code execution on the host gave an unprivileged outsider access to whatever secrets, credentials, and source code the pipeline could reach — enough for token theft, supply-chain pivots, and lateral movement into downstream systems.
A second independent researcher, Dan Lisichkin from Pillar Security, reported the same flaw separately through Google’s Vulnerability Rewards Program.
The second vector: —yolo mode
The advisory also closed a bypass in --yolo mode, which previously ignored fine-grained tool allowlists entirely. In affected versions, configuring run_shell_command(echo) in an allowlist would permit any shell command — the allowlist was not enforced under --yolo. Version 0.39.1 enforces allowlisting regardless of mode.
The catch
The run-gemini-cli GitHub Action defaults to pulling the latest Gemini CLI version. Workflows without a pinned version received the fix automatically — and may now be broken, because their pipelines relied on automatic workspace trust behavior that no longer exists. Users must now explicitly set GEMINI_TRUST_WORKSPACE: 'true' for trusted inputs, or harden their workflows for untrusted inputs.
Any workflow pinning a Gemini CLI version below 0.39.1 remains vulnerable.
What this exposes
The finding from Novee frames the structural issue precisely: AI coding agents now sit inside CI/CD pipelines with the execution privileges of a trusted contributor. They read from the same workspaces a contributor would touch. They hold the same credentials.
Traditional penetration testing does not cover AI agent behavior. Traditional AI safety reviews do not cover the infrastructure execution surface. The Gemini CLI vulnerability lived in the gap between them — and it was exploitable with nothing more than a pull request from an unprivileged external account.
The advisory covers CWE-20 (improper input validation), CWE-77 (command injection), CWE-78 (OS command injection), and CWE-200 (information exposure). Google has not yet assigned a CVE ID.
The CVSS 10.0 rating reflects the combination: low complexity, no privileges required, no user interaction required, full host access on exploit.