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.
Allowlisting Bypass in Gemini CLI –yolo Mode
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.”
Pillar Security researcher Dan Lisichkin, who is credited with discovering and reporting the allowlisting bypass, said the vulnerability represents an instance of the “lethal trifecta,” where a combination of access to private data, exposure to untrusted content, and the ability to externally communicate creates new pathways for data theft.
Put differently, the vulnerability enables a full supply chain compromise that starts from a GitHub issue, which causes the AI agent to parse hidden instructions via indirect prompt injection, extract workflow internal secrets (e.g., GITHUB_TOKEN) from the build environment, and exfiltrate them to an attacker-controlled server. Armed with these credentials, the threat actor can push arbitrary code to the main branch of the gemini-cli’s repository.
“Allowlists are only as good as their entries,” Lisichkin said. “If a workflow permits run_shell_command(cat) or any tool capable of reading files, the /proc and .git/config primitives still work. Google also recommends this list is kept safe and constrained.”
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.
(The story was updated after publication on May 7, 2026, to include additional insights from Pillar Security.)
