Google has addressed a maximum severity security flaw in the Gemini CLI (the “@google/gemini-cli” npm package and the “google-github-actions/run-gemini-cli” GitHub Actions workflow). This flaw could allow an attacker to execute arbitrary commands on the host system.
“This vulnerability could allow an unauthorized external attacker to force load their own malicious content as a Gemini configuration,” Novee Security said in a report Wednesday. “This allowed commands to be executed directly on the host system, bypassing security before the agent sandbox was initialized.”
This drawback has no CVE identifier and has a CVSS score of 10.0. 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
Google said in an advisory published last week that the impact is limited to workflows that use the Gemini CLI in headless mode, adding that using the tool in headless mode without folder trust will require a manual review to configure this trust mechanism.
“In previous versions, the Gemini CLI running in a CI environment (headless mode) automatically trusted the workspace folder to read configuration and environment variables,” he said.
“This is potentially dangerous in situations where the Gemini CLI runs in headless mode on an untrusted folder (such as a CI workflow that reviews user-submitted pull requests). If used with the contents of an untrusted directory, it may lead to remote code execution via malicious environment variables in the local .gemini/ directory.”
This automatic trust of the current workspace folder means that the tool can load any agent configuration it finds without review, sandboxing, or explicit user consent. Attackers can weaponize this behavior by implanting specially crafted configurations that pave the way for code execution on the host running the agent, effectively turning the CI/CD pipeline into a supply chain attack path.
This update resolves this issue by requiring folders to be explicitly trusted before accessing configuration files. This requires users to rethink their workflows and adopt one of two approaches:
If your workflow runs with trusted input (such as reviewing pull requests from trusted collaborators), set GEMINI_TRUST_WORKSPACE: ‘true’ in your workflow. If your workflow runs with untrusted input, review Google’s guidance at google-github-actions/run-gemini-cli to harden your workflow against malicious content and set environment variables.
The tech giant also took advantage of the fact that auto-approval mode ignores the allow list in “~/.gemini/settings.json” and all tool calls (including “run_shell_command”) are executed automatically to prevent scenarios where untrusted input (such as a user-submitted GitHub issue) could lead to remote code execution via prompt injection. We also noted that we are taking steps to tighten the allow list of tools when configured to run in this mode. User confirmation required.
“In version 0.39.1, the Gemini CLI policy engine now evaluates tool whitelists in –yolo mode. This is useful for CI workflows that want to whitelist some safe commands to run when processing untrusted input,” Google said. “As a result, some workflows that previously relied on this behavior may fail silently unless the tool whitelist is modified to match the task.”
Cursor bug causes code to execute
The disclosure comes as Novee Security highlights a high-severity vulnerability (CVE-2026-26268, CVSS score: 8.1) in the AI-powered development tool Cursor before version 2.5 that could also allow arbitrary code execution via prompt injection.
In an alert released in February 2026, Cursor described this as a case of sandbox escape via .git configuration. This allows a rogue agent to set up a bare repository (‘.git’) using a malicious Git hook that is automatically invoked whenever a commit operation is performed within the embedded repository context, without requiring user interaction.
The end result is the auto-authorized execution of arbitrary code on the victim’s machine through the following sequence of actions:
A user clones a public GitHub repository that has a bare repository embedded with a malicious post-checkout hook. A user opens a repository in CursorIDE. The user asks for a “codebase description” in an innocuous prompt. The cursor agent parses AGENTS.md, which tells it to go to the bare repository and perform a “git checkout” of the master branch. A post-checkout hook in the bare repository is triggered and executes the code.
“The root cause is not a flaw in Cursor’s core product logic, but rather a result of Git’s functional interactions that become exploitable the moment an AI agent starts performing Git operations autonomously within a repository that it does not control,” said security researcher Assaf Levkovich.
“When an agent executes git checkout as part of executing a routine request, the agent is not doing anything that the user has not implicitly authorized. However, neither the user nor the agent can know what the repository’s cursor rules are driving. Malicious precommit hooks embedded in nested bare repositories run silently outside the agent’s inference chain and outside the user’s field of view.”
This discovery coincides with the discovery of another high-severity access control vulnerability (CVSS score: 8.2) in the IDE. This vulnerability allows installed extensions to access sensitive API keys and credentials stored locally in a SQLite database, potentially resulting in account takeover, data disclosure, and financial loss through API misuse. This issue, codenamed CursorJacking by LayerX, remains unpatched.
“Cursor does not enforce any access control boundaries between the extension and this database,” said Roy Paz, LayerX researcher. “Exploitation of this vulnerability could lead to disclosure of session tokens and API keys, unauthorized access to the Cursor backend service, and data theft through user impersonation.”
Cursor claims that access is limited to local machines where users have already installed the extension and given permission. This means that a rogue extension that accesses the local file system can extract valuable information from various application data stores. To combat this threat, it is important that users continue to download trusted extensions.
Source link
