Gemini CLI CVSS 10.0: RCE in AI Developer Tools

Key Takeaways

• Google assigned a CVSS 10.0 score — the maximum possible — to a remote code execution (RCE) vulnerability in Gemini CLI and its companion GitHub Action, tracked as GHSA-wpqr-6v78-jr5g and disclosed April 24, 2026 [1].
• The flaw arose from two compounding design gaps: headless mode automatically trusted any workspace folder it processed (allowing malicious .gemini/ configuration to load without user consent), and --yolo mode ignored fine-grained tool allowlists, enabling prompt injection to invoke arbitrary shell commands [2].
• An unprivileged external attacker — for example, a contributor submitting a pull request — could exploit the flaw to execute commands on the CI runner before Gemini’s sandbox initialized, gaining access to secrets, credentials, and source code present in the workflow environment [3].
• Organizations should immediately upgrade to @google/gemini-cli v0.39.1 or later (or v0.40.0-preview.3 for preview track users) and google-github-actions/run-gemini-cli v0.1.22 or later, and explicitly audit all CI workflows that run Gemini in headless mode against untrusted repository content [1].
• The vulnerability is not isolated: in the same week, Cursor IDE was patched for CVE-2026-26268 (NVD-rated CVSS 9.9; vendor-disputed), a separate RCE vulnerability in its AI coding agent with a different attack mechanism. Researchers have also documented an earlier Gemini CLI prompt-injection path (2025) enabling silent environment-variable exfiltration [5].
• The co-occurrence of these disclosures may indicate a structural gap: agentic coding assistants appear to be integrated into privileged CI/CD workflows faster than their trust models and sandbox boundaries have been designed to handle.

Background

Google Gemini CLI is an open-source, terminal-based AI agent that brings Gemini model capabilities directly to developer workstations and automated pipelines. Available as the npm package @google/gemini-cli, it is accompanied by the google-github-actions/run-gemini-cli GitHub Action, which organizations use to orchestrate AI-assisted code review, issue triage, and automated analysis inside GitHub Actions workflows [6]. As of early 2026, the repository has accumulated over 100,000 stars [6], placing Gemini CLI within a competitive field of agentic coding tools that has grown rapidly over the past eighteen months.

The architectural pattern that distinguishes tools like Gemini CLI from earlier static analysis utilities is their ability to execute actions — running shell commands, reading and writing files, querying APIs — in response to model-generated reasoning. This agency is what makes them powerful, and what makes their trust models security-critical. When an agentic coding tool runs inside a CI/CD pipeline against a pull request, it typically operates with the full credential set of the workflow runner: repository secrets, cloud provider tokens, and deployment keys may all be reachable from within that execution context. Any flaw that allows an adversary to redirect what commands the agent executes is therefore not merely a developer-workstation concern; it is a supply chain risk with potential reach across the entire software delivery pipeline.

Security Analysis

Vulnerability Details

The vulnerability tracked as GHSA-wpqr-6v78-jr5g was published on April 24, 2026, and assigned CVSS 3.1 score 10.0 (Critical) by both GitHub and Google’s security team [1]. No CVE identifier had been assigned at the time of this writing. The advisory covers two distinct security weaknesses that compound in affected deployments.

The first weakness involves workspace folder trust in headless (non-interactive) mode. When Gemini CLI runs interactively on a developer’s workstation, it prompts the user to explicitly trust a folder before loading any configuration files from the .gemini/ subdirectory. This trust gate prevents an untrusted project from silently loading environment variables or custom tool configurations. In headless mode — the mode used in GitHub Actions and other CI environments — earlier versions omitted this check entirely, automatically extending trust to whatever directory the agent was processing. An attacker who controlled the content of a repository being reviewed by a Gemini-enabled CI workflow could plant a malicious .gemini/ directory containing environment variable overrides or configuration directives designed to trigger arbitrary command execution on the runner host [2].

The second weakness concerns tool allowlist enforcement in --yolo mode. Gemini CLI supports a fine-grained tool allowlist configured in ~/.gemini/settings.json, allowing operators to restrict which tools (such as run_shell_command) the agent may invoke. Prior to the patched versions, activating --yolo mode caused the agent to bypass this allowlist entirely. In CI workflows that permitted run_shell_command and processed untrusted input such as user-submitted GitHub issues, an adversary could craft a prompt injection payload that caused the agent to invoke shell commands of their choosing [2]. The combination of unvalidated workspace trust and allowlist bypass meant that the agent’s security posture could be neutralized entirely by an external, unauthenticated contributor.

The vulnerability is classified under CWE-20 (Improper Input Validation), CWE-77 (Command Injection), CWE-78 (OS Command Injection), and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) [2].

Attack Mechanics

The practical attack chain is worth examining because its prerequisites are minimal. An attacker submits a pull request to an organization whose CI pipeline runs Gemini CLI in headless mode to perform automated code review or analysis. The pull request includes a .gemini/ directory containing a crafted configuration file — legitimate-looking YAML that embeds environment variable overrides or tool configuration directives designed to redirect the agent. When the CI runner checks out the pull request content and invokes Gemini CLI against it, the tool automatically trusts the workspace and loads the attacker-controlled configuration before any sandbox boundary is established. From that point, the attacker controls what commands execute on the runner [3].

The impact of this execution is bounded only by what the runner itself can reach. GitHub Actions workflows commonly expose repository secrets, cloud provider API keys, and deployment credentials as environment variables or via the OIDC token service. Code execution on the runner before sandbox initialization means the attacker can access all of these, exfiltrate them to an external endpoint, and use them to pivot into downstream systems — package registries, container registries, cloud environments, or other repositories that trust artifacts produced by the compromised pipeline. The advisory notes that this sequence is sufficient for token theft, supply-chain pivots, and lateral movement into downstream systems [1].

A Pattern of Exposure

The GHSA-wpqr-6v78-jr5g disclosure follows an earlier Gemini CLI vulnerability reported by Tracebit researchers in 2025. That finding demonstrated that a malicious README.md — specifically, a file containing a lengthy, human-unlikely-to-read block of boilerplate such as the full GNU General Public License — could embed a hidden prompt injection payload that caused Gemini CLI to silently execute a command designed to exfiltrate all environment variables to a remote server [5][7]. The attacker payload exploited a semicolon-separated command bypass: because the input began with a whitelisted command, the agent proceeded without requesting permission for the full command string. Tracebit reported the issue on June 27, 2025, two days after Gemini CLI’s public release; Google initially classified it at a lower severity level before escalating it to Priority One, Severity One and issuing a patch on July 25, 2025 [5].

The April 2026 disclosure suggests that while the earlier prompt-injection path was addressed, the underlying trust model for headless deployments contained a structural flaw that persisted into the tool’s CI-integration scenarios. This pattern — an early prompt-injection finding followed by a deeper, higher-severity architectural finding — is consistent with how security research tends to mature around newly released agentic tools.

Gemini CLI’s disclosure was accompanied in the same news cycle by the publication of CVE-2026-26268, a separately reported RCE vulnerability (NVD-rated CVSS 9.9; vendor-disputed) in Cursor IDE affecting versions prior to 2.5 [4]. That flaw exploits a different mechanism: Cursor’s AI coding agent, when processing an untrusted repository, can be led to execute a malicious pre-commit hook embedded in a nested bare repository. Because Git hooks execute outside the agent’s reasoning chain and outside the user’s visible interface, the execution occurs silently. The attack requires only that a developer clone and open a maliciously crafted repository. The convergence of critical-severity AI tool vulnerabilities in the same disclosure window is consistent with an emerging pattern: as agentic coding tools have entered production CI/CD workflows, their security review cadence has struggled to keep pace with their expanding attack surface.

Impact Assessment

Organizations that have integrated Gemini CLI into CI/CD pipelines handling external contributor pull requests or user-submitted issues face the highest immediate risk. For these workflows, the vulnerability was remotely exploitable without authentication, and exploitation success granted code execution with the full privilege set of the runner environment. Organizations that use Gemini CLI exclusively in interactive mode on developer workstations were not affected: the interactive trust-prompt mechanism remained correctly implemented throughout [1].

The supply-chain exposure of this vulnerability extends beyond the directly affected organization. A compromised CI runner can sign and publish artifacts, push container images, or write to package registries. A single successful exploitation against a widely-used open-source project’s Gemini-enabled CI workflow could therefore introduce malicious code into the artifact stream consumed by that project’s downstream dependents — a propagation path that does not require compromising any individual developer’s workstation.

Recommendations

Immediate Actions

The most urgent action for affected organizations is to update the affected packages. The @google/gemini-cli package should be updated to version 0.39.1 or later; organizations using the preview track should move to 0.40.0-preview.3 or later. The google-github-actions/run-gemini-cli GitHub Action should be updated to v0.1.22 or later [1].

Once patched, teams should audit every GitHub Actions workflow that invokes Gemini CLI and determine whether it runs on pull_request events from external contributors, issues events with untrusted body content, or other triggers that introduce external input. Workflows configured with pull_request_target combined with an untrusted repository checkout are particularly high-risk. For workflows confirmed to run only on trusted inputs, setting GEMINI_TRUST_WORKSPACE: 'true' explicitly in the workflow environment provides a clear trust boundary; for workflows that process untrusted input, this variable should not be set and the updated workspace isolation guidance in the official advisory should govern configuration [1].

Any organization that ran Gemini CLI in headless mode against public pull requests or issues prior to patching should conduct a risk-based assessment of potential exposure. In the absence of confirmed exploitation evidence, secret rotation is strongly advised as a precautionary measure — workflows that processed external pull requests or issues during the vulnerable window should be treated as potentially affected, and all secrets accessible from those runner environments should be considered for rotation.

Short-Term Mitigations

Beyond immediate patching, organizations should implement structural controls that reduce the blast radius of future AI tool vulnerabilities in their CI/CD environments. AI-assisted CI workflows should be isolated in dedicated runners that hold narrowly scoped repository permissions and do not carry production deployment credentials; secrets required for code review automation should be distinct from and less privileged than those required for deployment. Where operationally feasible, network egress restrictions on AI tool runners limit an attacker’s ability to exfiltrate secrets to external endpoints even when code execution is achieved.

Within Gemini CLI’s own configuration, --yolo mode should be disabled in all CI deployments. This mode was designed for convenience in local interactive use; its allowlist-bypass behavior makes it unsuitable for any workflow processing untrusted input. Organizations should also ensure that all shell commands executed by Gemini CLI in CI contexts are captured in the runner audit log, enabling detection of anomalous activity in the event a compromise is suspected after the fact.

Strategic Considerations

The GHSA-wpqr-6v78-jr5g disclosure, taken alongside the Cursor CVE-2026-26268 and the earlier Tracebit Gemini CLI finding, is best understood as an early indicator of a security category that requires deliberate organizational attention. AI coding assistants and their associated CI integrations are not merely developer productivity tools; when given agency to execute commands in privileged pipeline environments, they become part of the trusted computing base for software supply chains. This demands the same security scrutiny organizations apply to build tooling, deployment automation, and dependency management.

Security teams should incorporate AI developer tool deployments into their existing software supply chain security programs. This means tracking which AI tools are integrated into which pipelines, maintaining an inventory of the privileges those tools hold, applying the same update and vulnerability tracking processes used for other CI/CD dependencies, and defining explicit policies for which workflow triggers are acceptable for AI-assisted automation. The question of whether a Gemini CLI integration should ever have access to production deployment credentials on a pull_request trigger is a policy question that should be answered before integration, not after an incident.

More broadly, organizations should recognize that the trust model applied to agentic AI tools — what they can see, what they can run, and what they are permitted to trust — is an architectural decision with security consequences that persist across tool versions and vulnerability patches. Establishing least-privilege for AI tool execution environments reduces the blast radius of future vulnerability disclosures in a tool category that is likely to face growing adversarial attention.

CSA Resource Alignment

This vulnerability illustrates risks and control requirements addressed across several CSA frameworks.

MAESTRO (Multi-Agent Environment Security Threat and Risk Overview) directly addresses the attack class demonstrated here. The workspace trust bypass is an example of what MAESTRO classifies as a trust boundary violation in agentic pipelines: the agent extended trust automatically to an environment it had not been explicitly authorized to trust, allowing external input to influence its execution context. MAESTRO’s guidance on tool invocation controls and trust model design is directly applicable to CI/CD integrations of agentic coding tools.

CSA’s AI Controls Matrix (AICM) provides a structured framework for assessing controls across the AI supply chain. AICM control domains covering AI system input validation (aligning with CWE-20), command execution governance (CWE-77, CWE-78), and orchestrated service provider security are relevant to the design gaps exposed by this vulnerability. Organizations deploying AI tools in CI/CD pipelines should evaluate their compliance with AICM controls for Orchestrated Service Providers (OSP), as Gemini CLI in headless mode functions in an orchestrated capacity within the pipeline.

CSA Zero Trust Guidance reinforces the principle that no workspace, runner, or input source should be implicitly trusted based on context alone. The automatic trust extension in headless mode is precisely the kind of implicit trust assumption that Zero Trust architecture is designed to eliminate. Applying Zero Trust principles to AI tool deployment means requiring explicit, per-session trust grants rather than inheriting trust from execution environment.

CSA’s Software Supply Chain Security guidance connects this vulnerability to the broader challenge of securing the CI/CD pipeline. AI tool integrations represent a new category of supply chain dependency: they hold credentials, execute code, and produce artifacts that feed downstream processes. Treating AI tool credentials and permissions with the same rigor applied to build tools and deployment automation is a direct application of CSA’s supply chain security principles.

References

[1] Google GitHub Actions. “Update to Gemini CLI and run-gemini-cli Trust Model · GHSA-wpqr-6v78-jr5g”. GitHub Advisory Database, April 24, 2026.

[2] Novee Security. “Google Gemini CLI CVSS 10.0 RCE Vulnerability: Critical Security Advisory”. Novee Security Blog, April 2026.

[3] The Hacker News. “Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution”. The Hacker News, April 30, 2026.

[4] Novee Security. “CVE-2026-26268: How an AI Coding Agent Can Run Exploits in Cursor IDE”. Novee Security Blog, April 2026.

[5] Tracebit. “Code Execution Through Deception: Gemini AI CLI Hijack”. Tracebit Blog, 2025.

[6] Google Gemini. “gemini-cli: An open-source AI agent that brings the power of Gemini directly into your terminal”. GitHub, 2025–2026.

[7] CyberScoop. “Researchers flag flaw in Google’s AI coding assistant that allowed for ‘silent’ code exfiltration”. CyberScoop, 2025.