Google patches CVSS 10 Gemini CLI RCE; Cursor exploits found

Google released a fix last week for a maximum-severity remote code execution bug in the Gemini CLI npm package (@google/gemini-cli) and the google-github-actions/run-gemini-cli workflow. The flaw, reported by Novee Security, carries a CVSS score of 10.0 and affects @google/gemini-cli versions earlier than 0.39.1 (and < 0.40.0-preview.3) and google-github-actions/run-gemini-cli versions earlier than 0.1.22. Novee Security reported the vulnerability allowed an attacker to force malicious content to load as Gemini configuration, triggering command execution on the host before the agent’s sandbox initialized. Google’s advisory states the impact is limited to workflows that run Gemini CLI in headless mode without explicit folder trust and that no CVE identifier has been assigned to the Gemini issue.

Google traced the defect to automatic trust of the current workspace folder in headless CI runs. In previous versions the CLI could load configuration and environment variables from a local .gemini directory without user review or sandboxing. An attacker able to supply repository contents, for example via a user-submitted pull request, could plant a crafted configuration that sets malicious environment variables or commands and leads to code execution on the machine running the CI job.

To address the issue, Google changed Gemini CLI to require explicit trust for workspace folders before reading configuration files. For workflows that process only trusted inputs, maintainers can set GEMINI_TRUST_WORKSPACE: ‘true’ in the workflow environment. For workflows that handle untrusted inputs, Google directs users to hardening guidance in the run-gemini-cli action documentation and recommends manual review before enabling trust. Google also updated allowlist behavior when Gemini runs with –yolo (auto-approve) so that allowlists are evaluated instead of ignored; the company warned some CI workflows that relied on the prior behavior may fail unless tool allowlists are adjusted.

Separately, security researchers reported two high-severity problems in Cursor, an AI-powered development IDE. One issue, tracked as CVE-2026-26268 with a CVSS score of 8.1, involves a sandbox escape via nested .git repositories and malicious Git hooks. Researchers demonstrated a scenario where a public repository contains an embedded bare repository with a crafted post-checkout hook. When Cursor’s agent parsed AGENTS.md and performed a git checkout while answering a prompt such as “explain the codebase,” the hook executed and ran arbitrary code on the host without further user interaction. Researcher Assaf Levkovich described the problem as a feature interaction in Git that becomes exploitable when an AI agent autonomously runs Git operations inside a repository it does not control.

A second high-severity issue, labeled CursorJacking by LayerX and given a CVSS score of 8.2, remains unpatched. LayerX researcher Roy Paz reported that Cursor does not enforce access controls between installed extensions and a local SQLite database that stores API keys and session tokens, allowing any extension with local file access to read those credentials. LayerX warned that exploitation could expose session tokens and API keys and enable unauthorized access to backend services.

Google and Novee urged CI teams to review workflows that run Gemini CLI in headless mode and apply the patch and configuration changes. Cursor users were advised to avoid opening untrusted repositories and to install only vetted extensions while the vendor addresses the reported flaws. Security researchers recommended that Cursor implement stricter access controls and sandboxing for extensions and agent-driven Git operations.