Maximum severity fixed.
Google has finally squashed a CVSS 10.0 vulnerability affecting its Gemini CLI tools—specifically the @google/gemini-cli npm package and the google-github-actions/run-gemini-cli GitHub Actions workflow. This isn’t just a minor bug; we’re talking about a potential avenue for attackers to execute arbitrary commands directly on host systems, bypassing security measures before the agent’s sandbox even initialized. Novee Security flagged the issue, noting that an unprivileged external attacker could force their own malicious content to load as Gemini configuration, triggering command execution. This affects versions of the CLI prior to 0.39.1 and 0.40.0-preview.3, and the GitHub Action prior to 0.1.22.
The core of the problem? In previous versions, Gemini CLI running in CI environments (what they call headless mode) automatically trusted workspace folders. This meant it would load configuration and environment variables without asking nicely. Now, that’s potentially disastrous in scenarios like CI workflows reviewing user-submitted pull requests. If an attacker could plant a specially crafted configuration in an untrusted folder, they could effectively turn your CI/CD pipelines into launching pads for supply-chain attacks. It’s a classic case of over-trusting implicit context.
Google’s fix requires folders to be explicitly trusted before configuration files are read. They’re pushing users toward two paths: if your workflow runs on trusted inputs from collaborators, set GEMINI_TRUST_WORKSPACE: 'true'. If it handles untrusted inputs, you’re advised to follow Google’s guidance for hardening workflows and set the environment variable. They’ve also hardened tool allowlisting in --yolo mode, preventing scenarios where untrusted inputs could lead to code execution via prompt injection by bypassing allowlists. This change means some workflows that relied on the old behavior might break, requiring updates to their tool allowlists.
Cursor’s Code Execution Conundrum
But wait, there’s more. This Gemini CLI disclosure arrives alongside news of a high-severity vulnerability in the AI-powered IDE, Cursor. Prior to version 2.5 (CVE-2026-26268, CVSS 8.1), Cursor suffered from a sandbox escape via .git configurations. The exploit allowed a rogue agent to set up a malicious Git hook within a bare repository. Every commit operation in that context would then trigger this hook, leading to arbitrary code execution without user interaction. Imagine cloning a public repo, opening it in Cursor, asking it to ‘explain the codebase,’ and then – boom – your machine is compromised because an AI agent autonomously navigated to a malicious Git hook. It highlights a deeper issue: AI agents performing Git operations on repositories they don’t fully control.
“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.”
Why Does This Matter for Developers?
This isn’t just about Google or Cursor; it’s a stark reminder for every developer and organization relying on AI-assisted tools in their development pipelines. The ease with which these tools integrate into complex workflows like CI/CD creates new attack surfaces. Automatically trusting repository contents, especially in automated pipelines processing external inputs, is a vulnerability waiting to be exploited. The market for AI development tools is exploding, and as these tools become more powerful and integrated, their potential impact on security — both positive and negative — grows exponentially. The speed of innovation here often outpaces security hardening, and incidents like these are the painful catch-up.
Historically, we’ve seen similar patterns with the rise of package managers like npm and PyPI. Each innovation that simplifies development also introduces potential vectors for widespread compromise if not managed with a security-first mindset. The Gemini CLI and Cursor flaws are just the latest iterations of this ongoing cybersecurity challenge. The move towards greater automation and AI integration in development processes demands a proportional increase in vigilance around how these tools interact with the underlying systems and external data sources. Trust must be earned, not assumed, especially when code execution is on the line.
The fact that a CVSS 10.0 flaw can exist in a widely used tool like Gemini CLI, even if limited to specific modes, is alarming. It underscores the ongoing struggle to secure the software supply chain, especially as AI plays an increasingly active role. Developers need to be hyper-aware of the permissions and trust levels granted to these AI agents within their environments. It’s a new frontier in security, and the lessons learned from past vulnerabilities are more relevant than ever.
🧬 Related Insights
- Read more: UK Cyber Council Launches Associate Cyber Pro Title [Skills Gap Fix?]
- Read more: [2026] Microsoft April Patch Tuesday: 167 Flaws, 2 Zero-Days Fixed
Frequently Asked Questions
What does the Gemini CLI vulnerability allow attackers to do?
It allows attackers to execute arbitrary commands on host systems by tricking the tool into loading malicious configuration files, bypassing sandbox security.
How does the Cursor vulnerability work?
It exploits Git’s feature interaction, specifically malicious Git hooks within a repository, to achieve code execution when an AI agent performs Git operations.
Am I affected if I don’t use Gemini CLI in headless mode?
Google states the Gemini CLI vulnerability is limited to workflows using the tool in headless mode. However, vigilance is always recommended.
