Google Patches CVSS 10.0 Flaw in Gemini CLI That Turned AI Developer Tool Into RCE Vector

Google patched a maximum-severity remote code execution vulnerability in its Gemini CLI tool that enabled attackers to run arbitrary commands through compromised CI/CD workflows, marking the latest failure in the rushed deployment of AI developer tools without secure-by-default protections.

The flaw, tracked as GHSA-wpqr-6v78-jr5g, earned a CVSS 3.1 score of 10.0 — the highest possible rating. It affected both the @Google/gemini-cli npm package and the github-github-actions/run-gemini-cli GitHub Action, exploiting unsafe workspace trust handling in headless execution modes where the tool automatically processed untrusted inputs from pull requests and issue submissions.

The Attack Surface: When AI Agents Meet Infrastructure Trust

The vulnerability exploited two root causes, per Cyberpress: unsafe workspace trust handling in headless CI/CD environments and tool allowlisting bypasses under the CLI’s –yolo mode. In headless execution, workspace folders were automatically trusted, allowing attackers to inject malicious environment variables that the AI agent would execute when processing repository content.

Security researchers Elad Meged from Novee Security and Dan Lisichkin from Pillar Security discovered the flaw through Google’s Vulnerability Rewards Program. Their research revealed that when Gemini CLI ran inside GitHub Actions workflows — environments with access to repository secrets, the ability to modify code, and shell execution privileges — it became a high-value target for Supply Chain attacks.

The exploitation path was straightforward: an attacker could submit a pull request or issue comment containing crafted environment variables. When the CI/CD workflow triggered Gemini CLI to analyze the submission, the tool would trust the workspace by default and execute the embedded commands with the workflow’s privileges — potentially accessing secrets, modifying production code, or pivoting to connected infrastructure.

Google’s Response and Breaking Changes

Google released patches on April 27, 2026, in @google/gemini-cli versions 0.39.1 and 0.40.0-preview.3, along with github-github-actions/run-gemini-cli v0.1.22. The fix introduced a breaking security change: headless mode no longer automatically trusts workspace directories. Organizations must now explicitly set the GEMINI_TRUST_WORKSPACE environment variable to ‘true’ to enable the previous behavior.

The change reflects a fundamental shift from trust-by-default to explicit opt-in for dangerous operations. Google’s Vulnerability Disclosure Program team defended the broader security architecture in a statement to CSO Online, noting that “our security model for the CLI is centered on providing robust, multi-layered sandboxing” with integrations for Docker, Podman, and macOS Seatbelt. However, these protections required manual configuration — precisely the gap that enabled this vulnerability in default deployments.

The Broader Supply Chain Threat

The Gemini CLI flaw sits within a growing pattern of AI development tool compromises. In March 2026, the LiteLLM library — widely used for AI application development — was compromised through a backdoored security scanner, with threat actor TeamPCP injecting credential harvesting code via a compromised Trivy vulnerability scanner. The attack demonstrated how security tools themselves can become attack vectors when integrated into automated pipelines.

The Gemini CLI vulnerability exemplifies OWASP LLM01 risks — prompt injection attacks — but escalates them by meeting infrastructure trust problems. When AI agents operate with the same privileges as human developers (shell access, secret visibility, code modification rights) but process untrusted external inputs automatically, the attack surface expands dramatically. Repository content that was previously inert text becomes executable attack payload.

What to Watch

Organizations using Gemini CLI in CI/CD pipelines should immediately upgrade to patched versions and audit existing workflows for explicit workspace trust settings. The breaking change means automated deployments may require configuration updates to continue functioning.

More broadly, the vulnerability signals that enterprises integrating AI coding agents into production infrastructure need security frameworks that assume untrusted input by default. As Cybersecurity News noted, when automation, prompt handling, and shell access converge with untrusted input, small policy gaps escalate into critical attack paths.

Expect increased scrutiny of AI Developer Tools’ default security postures, particularly around workspace trust models, tool execution allowlists, and the permissions granted to agents processing external code submissions. The rush to deploy AI-powered development acceleration is colliding with the reality that these tools inherit decades-old infrastructure trust assumptions never designed for autonomous agents processing adversarial inputs.