Google has addressed a most severity security flaw in Gemini CLI — the “@google/gemini-cli” npm package deal and the “google-github-actions/run-gemini-cli” GitHub Actions workflow — that might have allowed attackers to execute arbitrary instructions on host techniques.
“The vulnerability allowed an unprivileged exterior attacker to pressure their very own malicious content material to load as Gemini configuration,” Novee Safety stated in a Wednesday report. “This triggered command execution immediately on the host system, bypassing security earlier than the agent’s sandbox even initialized.”
The shortcoming, which doesn’t have a CVE identifier, carries a CVSS rating of 10.0. It impacts the next variations –
- @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 revealed final week, Google stated the affect is restricted to workflows utilizing Gemini CLI in headless mode, including that any use of the software in headless mode with out folder belief would require guide evaluate to configure this belief mechanism.
“In earlier variations, Gemini CLI operating in CI environments (headless mode) mechanically trusted workspace folders for the aim of loading configuration and setting variables,” it stated.
“That is probably dangerous in conditions the place Gemini CLI runs on untrusted folders in headless mode (e.g., CI workflows that evaluate user-submitted pull requests). If used with untrusted listing contents, this might result in distant code execution through malicious setting variables within the native .gemini/ listing.”
This automated belief of the present workspace folder meant that the software may load any agent configuration it discovered with out evaluate, sandboxing, or express person consent. An attacker may weaponize this habits by planting a specifically crafted configuration that might pave the best way for code execution on the host operating the agent, successfully turning CI/CD pipelines into supply-chain assault paths.
The replace addresses the issue by requiring folders to be explicitly trusted earlier than configuration information will be accessed. To that finish, customers are being urged to evaluate their workflows and undertake one among two approaches –
- If the workflow runs on trusted inputs (e.g., reviewing pull requests from trusted collaborators), set GEMINI_TRUST_WORKSPACE: ‘true’ within the workflow.
- If the workflow runs on untrusted inputs, evaluate Google’s steering in google-github-actions/run-gemini-cli to harden the workflow in opposition to malicious content material, and set the setting variable.
The tech large additionally famous that it is taking steps to harden software allowlisting when Gemini CLI is configured to run in –yolo mode to stop situations the place untrusted inputs (e.g., user-submitted GitHub points) may result in distant code execution through immediate injection by making the most of the truth that the auto-approve mode would ignore any allowlist in “~/.gemini/settings.json” and run all software calls mechanically (together with “run_shell_command”) with out requiring person affirmation.
“In model 0.39.1, the Gemini CLI coverage engine now evaluates software allowlisting underneath –yolo mode, which is helpful for CI workflows that allowlist a number of secure instructions to run when processing untrusted inputs,” Google stated. “In consequence, some workflows that beforehand trusted this habits might fail silently except software allowlists are modified to suit the duty.”
Cursor Bug Results in Code Execution
The disclosure comes as Novee Safety additionally highlighted a high-severity vulnerability within the AI-powered improvement software Cursor previous to model 2.5 (CVE-2026-26268, CVSS rating: 8.1) that might additionally result in arbitrary code execution via a immediate injection.
Cursor, in an alert launched in February 2026, described it as a case of sandbox escape by way of .git configurations, permitting a rogue agent to arrange a naked repository (“.git”) with a malicious Git hook that is mechanically fired each time a commit operation runs inside the embedded repository context with out requiring any person interplay.
The tip result’s auto-approved arbitrary code execution on the sufferer’s machine by way of the next sequence of actions –
- Consumer clones a public GitHub repository with the embedded naked repository containing a malicious post-checkout hook
- Consumer opens the repository in CursorIDE
- Customers ask an innocuous immediate to “clarify the codebase”
- Cursor agent parses the AGENTS.md that instructs it to navigate to the naked repository and performs a “git checkout” of the grasp department
- The post-checkout hook contained in the naked repository is triggered, resulting in code execution.
“The foundation trigger just isn’t a flaw in Cursor’s core product logic, however quite a consequence of a function interplay in Git, one which turns into exploitable the second an AI agent begins autonomously executing Git operations inside a repository it would not management,” security researcher Assaf Levkovich stated.
“When the agent runs git checkout as a part of fulfilling a routine request, it isn’t doing something the person did not implicitly authorize. However neither the person nor the agent has visibility into what the repository’s Cursor Guidelines have set in movement. A malicious pre-commit hook embedded in a nested naked repository executes silently, outdoors the agent’s reasoning chain and out of doors the person’s discipline of view.”
The findings additionally coincide with the invention of one other high-severity entry management vulnerability within the IDE (CVSS rating: 8.2) that might enable any put in extension to entry delicate API keys and credentials saved regionally in an SQLite database, enabling account takeover, knowledge publicity, and monetary loss stemming from unauthorized API utilization. The difficulty, codenamed CursorJacking by LayerX, stays unpatched.
“Cursor doesn’t implement entry management boundaries between extensions and this database,” LayerX researcher Roy Paz stated. “Exploitation of this vulnerability can result in publicity of session tokens and API keys, unauthorized entry to Cursor backend companies, and knowledge theft through person impersonation.”
Cursor has maintained that the entry is restricted to the native machine the place the person has already put in and granted permissions to the extension, that means any rogue extension with native file system entry may probably extract invaluable info from numerous utility knowledge shops. To counter the risk, it is important that customers follow downloading trusted extensions.
