"The vulnerability allowed an unprivileged external attacker to force their own malicious content to load as Gemini configuration," Novee Security said.
What the Gemini CLI flaw was and who it affected
Google patched a maximum-severity vulnerability in Gemini CLI — the @google/gemini-cli npm package and the google-github-actions/run-gemini-cli GitHub Actions workflow — that Novee Security reported could allow attackers to execute arbitrary commands on host systems. The flaw carries a CVSS score of 10.0 and, according to the advisory, does not have a CVE identifier.
Google identified the affected versions as:
- @google/gemini-cli < 0.39.1
- @google/gemini-cli < 0.40.0-preview.3
- google-github-actions/run-gemini-cli < 0.1.22
The company said the impact is limited to workflows that run Gemini CLI in headless mode and that the problematic behavior involved automatically trusting the current workspace folder when running in CI environments.
How the automatic trust led to remote code execution
In prior versions, Gemini CLI running in headless mode "automatically trusted workspace folders for the purpose of loading configuration and environment variables," Google said. That automatic trust meant the CLI could load any agent configuration it found in the workspace — including files in a local .gemini/ directory — without review, sandboxing, or explicit user consent.
Novee Security described how an attacker could weaponize that behavior by placing specially crafted configuration and environment variables in an untrusted workspace. When Gemini CLI loaded that configuration, the tool could trigger command execution on the host system before the agent’s sandbox initialized, Novee said, effectively turning CI/CD pipelines into a supply-chain attack path.
Google's mitigation steps and configuration guidance
Google changed Gemini CLI to require explicit trust of workspace folders before configuration files can be accessed. The advisory gives two configuration paths for workflows:
- If the workflow runs on trusted inputs (for example, 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 accordingly.
Google also warned about --yolo mode, which previously could auto-approve tool calls and ignore the allowlist in ~/.gemini/settings.json. To address that, version 0.39.1 updates the Gemini CLI policy engine so it evaluates tool allowlisting under --yolo mode; Google noted that some workflows that had depended on the old behavior "may fail silently unless tool allowlists are modified to fit the task."
Cursor discoveries: CVE-2026-26268 and CursorJacking
The Gemini finding arrived alongside disclosure of two high-severity issues in the AI development IDE Cursor. The first — CVE-2026-26268, with a CVSS score of 8.1 — affected Cursor prior to version 2.5 and enabled arbitrary code execution via a prompt-injection-style sandbox escape through .git configurations.
Cursor’s advisory described a chain where a user cloning a public GitHub repository that embedded a bare .git repository with a malicious post-checkout hook could trigger execution: the user opens the repository in CursorIDE, asks an innocuous prompt (for example, to "explain the codebase"), the Cursor agent parses AGENTS.md and navigates to the bare repository, runs git checkout of the master branch, and the post-checkout hook fires automatically, producing auto-approved code execution.
Security researcher Assaf Levkovich framed the root cause as a feature interaction in Git that becomes exploitable when an AI agent autonomously executes Git operations inside a repository it doesn't control.
Separately, LayerX reported a high-severity access control vulnerability (CVSS score: 8.2) dubbed CursorJacking that could let any installed extension access sensitive API keys and credentials stored locally in an SQLite database. LayerX researcher Roy Paz said, "Cursor does not enforce access control boundaries between extensions and this database." LayerX noted exploitation could lead to exposure of session tokens and API keys and unauthorized access to Cursor backend services; the issue remains unpatched.
Cursor responded by saying the access is limited to the local machine where a user has installed and granted permissions to an extension and emphasized that users should stick to trusted extensions.
What this means for CI teams, Cursor users, and open-source maintainers
CI and security teams using Gemini CLI in headless mode will need to review workflows that process untrusted inputs and either explicitly set GEMINI_TRUST_WORKSPACE: 'true' for trusted contexts or apply Google's hardening guidance and environment variables for untrusted contexts. Teams that relied on --yolo mode should check tool allowlists after upgrading to or installing version 0.39.1.
Developers and users of Cursor should ensure they are on patched releases where applicable (Cursor’s sandbox-escape issue affected versions prior to 2.5) and be cautious about installing extensions, since LayerX's CursorJacking finding demonstrates how local extensions with file-system access can exfiltrate stored credentials.
The two disclosures underscore a recurring pattern: agent-enabled tools that automate repository or workspace operations can abet remote code execution when implicit trust assumptions meet untrusted inputs. For organizations that run agents in CI or rely on IDE automation, the immediate tasks are concrete — review workflow trust settings, apply the GEMINI_TRUST_WORKSPACE guidance or hardening steps, and validate tool allowlists under --yolo; for Cursor users, verify version and extension provenance.
Original reporting: https://thehackernews.com/2026/04/google-fixes-cvss-10-gemini-cli-ci-rce.html
