@google/gemini-cli (npm)
run-gemini-cli (GitHub Action)
Your AI coding agent will run this exploit for you
See how we found a high-severity CVE in CursorYour AI coding agent will run this exploit for you
See how we found a high-severity CVE in Cursor@google/gemini-cli (npm)
run-gemini-cli (GitHub Action)
The Gemini CLI and its associated GitHub Action were found to have a critical security flaw (CVSS 10.0) related to how they handle workspace trust and tool execution. In automated, non-interactive (headless) environments like CI/CD pipelines, the tool could be coerced into executing arbitrary code or leaking sensitive information if run against untrusted content, such as a malicious Pull Request. The update introduces a breaking change that requires users to explicitly trust workspaces and enforces stricter tool allowlisting even when using the --yolo mode.
The vulnerability stems from two primary architectural behaviors in older versions of the CLI:
Automatic Folder Trust in Headless Mode: Previously, when running in a CI environment, the Gemini CLI automatically trusted the workspace folder. This meant it would automatically load configuration files and environment variables (like those in a .gemini/ or .env directory) without user confirmation. An attacker could submit a Pull Request containing a malicious .gemini/ directory. If the CI pipeline ran the Gemini CLI on that untrusted code, the attacker could achieve Remote Code Execution (RCE) by injecting malicious environment variables.
Bypassing Tool Allowlisting via --yolo: The --yolo flag is designed to allow the model to execute actions more freely. However, in previous versions, this flag completely ignored the fine-grained tool allowlist defined in settings.json. For instance, if a workflow allowed run_shell_command for a specific safe task, a prompt injection attack could trick the model into running any arbitrary shell command because the allowlist was not being enforced under the “yolo” state.