Google has resolved a critical security issue with a maximum severity rating that impacted its Gemini CLI ecosystem, a flaw that could have enabled attackers to execute unauthorized commands on affected systems.
According to a report published by Novee Security, the vulnerability allowed attackers without privileges to inject malicious configurations into Gemini CLI environments. This manipulation could trigger command execution directly on the host machine, even before any sandbox protections were activated.
Severe Risk in CI/CD Environments
The vulnerability, although not assigned a CVE identifier, was rated with a CVSS score of 10.0, indicating the highest level of severity. It affected the following components:
- @google/gemini-cli versions below 0.39.1
- @google/gemini-cli versions below 0.40.0-preview.3
- google-github-actions/run-gemini-cli versions below 0.1.22
Google clarified that the issue mainly impacts workflows where Gemini CLI is executed in headless mode, commonly used in CI/CD pipelines.
In earlier versions, the tool automatically trusted workspace directories when running in such environments. While convenient, this behavior introduced a serious risk when processing untrusted inputs, such as public pull requests. Malicious actors could exploit this trust mechanism by embedding harmful configurations or environment variables within the .gemini/ directory.
How the Attack Worked
Because the system automatically trusted workspace folders, it would load configuration files without validation, sandboxing, or user approval. Attackers could exploit this by planting specially crafted configuration files, effectively transforming CI/CD workflows into entry points for supply chain attacks.
Security Improvements and Mitigation Steps
To eliminate the risk, Google has introduced stricter controls. Now, workspace folders must be explicitly marked as trusted before any configuration data is loaded.
Users are advised to take the following actions:
- For trusted workflows, such as internal pull requests, enable trust by setting:
GEMINI_TRUST_WORKSPACE: 'true' - For untrusted inputs, follow Google’s official hardening guidelines and carefully configure environment variables to prevent malicious execution.
Additionally, Google strengthened protections in –yolo mode, a setting that previously auto-approved all tool actions. Earlier, this mode ignored allowlists and could execute commands like run_shell_command without user confirmation, increasing the risk of prompt injection attacks.
With version 0.39.1, the policy engine now enforces tool allowlisting even in this mode. However, this change may cause some existing workflows to fail if they rely on older behavior.
Cursor Vulnerability Enables Silent Code Execution
At the same time, researchers from Novee Security identified another serious flaw in the AI-based development tool Cursor IDE.
Tracked as CVE-2026-26268 with a CVSS score of 8.1, this vulnerability impacts versions prior to 2.5 and allows attackers to execute arbitrary code through prompt injection techniques.
Cursor disclosed earlier that the issue stems from a sandbox escape mechanism involving Git configurations. Attackers could create a malicious .git setup containing hidden hooks that execute automatically during repository operations.<image import>
Attack Chain Explained
The exploitation process follows a deceptive but effective sequence:
- A user clones a public repository containing a hidden malicious Git hook
- The repository is opened inside Cursor IDE
- The user submits a simple request, such as explaining the code
- The AI agent reads instructions from an AGENTS.md file and performs a Git operation
- A hidden post-checkout hook executes automatically, triggering malicious code
Security researcher Assaf Levkovich explained that this is not a direct flaw in Cursor’s logic. Instead, it results from how Git features interact with autonomous AI behavior. The agent performs actions it assumes are safe, but hidden configurations execute outside its awareness.
Additional Cursor Security Concerns
Another high-risk issue, with a CVSS score of 8.2 and referred to as “CursorJacking,” was identified by LayerX.
This flaw allows installed extensions to access sensitive data stored locally, including API keys and session tokens. Because Cursor lacks strict access control boundaries between extensions and its internal database, malicious extensions could extract confidential information.
Researcher Roy Paz warned that such exploitation could lead to account compromise, unauthorized API usage, and data theft. The vulnerability remains unpatched at the time of disclosure.
Cursor responded by stating that the risk is limited to the local environment, requiring users to install and grant permissions to extensions. However, the safest approach is to only use trusted extensions from reliable sources.
Found this article interesting? Follow us on X (Twitter) , Facebook, Blue sky and LinkedIn to read more exclusive content we post.
