Google Patches Critical CVSS 10.0 Vulnerability in Gemini CLI Exposing CI/CD Pipelines

Google fixes CVSS 10.0 vulnerability in Gemini CLI

This CVSS 10.0 RCE vuln has been patched, automatically for some, so better check those workflows If you use Gemini CLI, watch out: Google has patched a CVSS 10.0 vulnerability in its command-line AI tool and is warning anyone running it in headless mode, or through GitHub Actions, to review their workflows. The update to Gemini CLI and the run-gemini-cli GitHub Action, published last week but largely unnoticed until one of the two credited research teams published its writeup on Wednesday, fixes a critical - and apparently easy-to-abuse - flaw tied to over-permissive workspace trust settings. Per Google's advisory published to GitHub, the issue stems from how the headless mode of Gemini CLI (frequently used in CI/CD environments and increasingly by AI agents) handles workspace folder trust: It automatically assumes any of the workspace folders it's active in are trusted for the purpose of loading configuration files and environment variables. We trust you can see the problem here. Novee researcher Elad Meged discovered the vulnerability (independently of Pillar Security's Dan Lisichkin, who Google also credited for the find), he told us, while studying CI/CD supply chain attack vectors. "This vulnerability had nothing to do with prompt injection or the model 'deciding' to act maliciously," Meged told The Register in an email. "It was an infrastructure-level issue, where attacker-controlled content was silently accepted as trusted configuration and executed before any sandbox was initialized." A CVE hasn't been issued for the issue yet, but Meged told us Google has confirmed to him that it is in the process of assigning one. Novee also scored a bug bounty for the find, but declined to disclose how much. "This is potentially risky in situations where Gemini CLI runs on untrusted folders in headless mode," Google explained. "If used with untrusted directory contents, this could lead to remote code execution via malicious environment variables in the local .gemini/ directory." Interactive mode in Gemini CLI does not behave the same way: it requires users to explicitly trust a folder before workspace configuration files are loaded, and the update brings headless mode into line with that behavior. The mitigations shipped in Gemini CLI versions 0.39.1 and 0.40.0-preview.3, but here's the catch: the run-gemini-cli GitHub Action defaults to the newest Gemini CLI release unless users pin a specific version. In other words, anyone using the GitHub Action as part of a workflow without specifying a CLI version may have some cleanup to do. "GitHub Actions and other automated pipelines that rely on the previous automatic trust behavior will fail to load workspace-specific settings until they are updated to use explicit trust mechanisms," Google said. The update may also break workflows that relied on Gemini CLI's --yolo mode, which previously bypassed fine-grained tool allowlists and automatically approved agent actions without prompting. "In previous versions, when Gemini CLI was configured to run in --yolo mode, it would ignore any fine grained tool allowlist," Google explained in the advisory. "In version 0.39.1, the Gemini CLI policy engine now evaluates tool allowlisting under --yolo mode ... As a result, some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task." Those who do specify a version, says Google, ought to make changes to allow the newest, safest version to run and be prepared to fix those workflows anyhow. Damned if you do, damned if you don't, in other words, but the fix is necessary, as explained by the folks at Novee Security, one of the credited finders. Across every workflow Novee tested the vuln on, the company noted, the results were devastatingly the same. "Code execution on the host running the agent gave an unprivileged outsider access to whatever secrets, credentials, and source code the workflow could reach," the Novee team explained. "Enough for token theft, supply-chain pivots, and lateral movement into downstream systems." In short, take action as Google suggests, or avoid putting AI agents in sensitive environments until the risks are fully understood. ®

Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution

Google has addressed a maximum severity security flaw in Gemini CLI -- the "@google/gemini-cli" npm package and the "google-github-actions/run-gemini-cli" GitHub Actions workflow -- that could have allowed attackers to execute arbitrary commands on host systems. "The vulnerability allowed an unprivileged external attacker to force their own malicious content to load as Gemini configuration," Novee Security said in a Wednesday report. "This triggered command execution directly on the host system, bypassing security before the agent's sandbox even initialized." The shortcoming, which does not have a CVE identifier, carries a CVSS score of 10.0. It affects the following versions - * @google/gemini-cli < 0.39.1 * @google/gemini-cli < 0.40.0-preview.3 * google-github-actions/run-gemini-cli < 0.1.22 In its advisory published last week, Google said the impact is limited to workflows using Gemini CLI in headless mode, adding that any use of the tool in headless mode without folder trust will require manual review to configure this trust mechanism. "In previous versions, Gemini CLI running in CI environments (headless mode) automatically trusted workspace folders for the purpose of loading configuration and environment variables," it said. "This is potentially risky in situations where Gemini CLI runs on untrusted folders in headless mode (e.g., CI workflows that review user-submitted pull requests). If used with untrusted directory contents, this could lead to remote code execution via malicious environment variables in the local .gemini/ directory." This automatic trust of the current workspace folder meant that the tool could load any agent configuration it found without review, sandboxing, or explicit user consent. An attacker could weaponize this behavior by planting a specially crafted configuration that could pave the way for code execution on the host running the agent, effectively turning CI/CD pipelines into supply-chain attack paths. The update addresses the problem by requiring folders to be explicitly trusted before configuration files can be accessed. To that end, users are being urged to review their workflows and adopt one of two approaches - * If the workflow runs on trusted inputs (e.g., reviewing pull requests from trusted collaborators), set GEMINI_TRUST_WORKSPACE: 'true' in the workflow. * If the workflow runs on untrusted inputs, review Google's guidance in google-github-actions/run-gemini-cli to harden the workflow against malicious content, and set the environment variable. The tech giant also noted that it's taking steps to harden tool allowlisting when Gemini CLI is configured to run in --yolo mode to prevent scenarios where untrusted inputs (e.g., user-submitted GitHub issues) could lead to remote code execution via prompt injection by taking advantage of the fact that the auto-approve mode would ignore any allowlist in "~/.gemini/settings.json" and run all tool calls automatically (including "run_shell_command") without requiring user confirmation. "In version 0.39.1, the Gemini CLI policy engine now evaluates tool allowlisting under --yolo mode, which is useful for CI workflows that allowlist a few safe commands to run when processing untrusted inputs," Google said. "As a result, some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task." Cursor Bug Leads to Code Execution The disclosure comes as Novee Security also highlighted a high-severity vulnerability in the AI-powered development tool Cursor prior to version 2.5 (CVE-2026-26268, CVSS score: 8.1) that could also lead to arbitrary code execution by means of a prompt injection. Cursor, in an alert released in February 2026, described it as a case of sandbox escape through .git configurations, allowing a rogue agent to set up a bare repository (".git") with a malicious Git hook that's automatically fired every time a commit operation runs within the embedded repository context without requiring any user interaction. The end result is auto-approved arbitrary code execution on the victim's machine through the following sequence of actions - * User clones a public GitHub repository with the embedded bare repository containing a malicious post-checkout hook * User opens the repository in CursorIDE * Users ask an innocuous prompt to "explain the codebase" * Cursor agent parses the AGENTS.md that instructs it to navigate to the bare repository and performs a "git checkout" of the master branch * The post-checkout hook inside the bare repository is triggered, leading to code execution. "The root cause is not a flaw in Cursor's core product logic, but rather a consequence of a feature interaction in Git, one that becomes exploitable the moment an AI agent starts autonomously executing Git operations inside a repository it doesn't control," security researcher Assaf Levkovich said. "When the agent runs git checkout as part of fulfilling a routine request, it is not doing anything the user didn't implicitly authorize. But neither the user nor the agent has visibility into what the repository's Cursor Rules have set in motion. A malicious pre-commit hook embedded in a nested bare repository executes silently, outside the agent's reasoning chain and outside the user's field of view." The findings also coincide with the discovery of another high-severity access control vulnerability in the IDE (CVSS score: 8.2) that could allow any installed extension to access sensitive API keys and credentials stored locally in an SQLite database, enabling account takeover, data exposure, and financial loss stemming from unauthorized API usage. The issue, codenamed CursorJacking by LayerX, remains unpatched. "Cursor does not enforce access control boundaries between extensions and this database," LayerX researcher Roy Paz said. "Exploitation of this vulnerability can lead to exposure of session tokens and API keys, unauthorized access to Cursor backend services, and data theft via user impersonation." Cursor has maintained that the access is limited to the local machine where the user has already installed and granted permissions to the extension, meaning any rogue extension with local file system access could potentially extract valuable information from various application data stores. To counter the threat, it's essential that users stick to downloading trusted extensions.