Gemini CLI Security: CVSS 10 RCE and CISO Hardening Guide

Gemini CLI shipped with a CVSS 10.0 remote code execution vulnerability that allowed any public GitHub issue to trigger arbitrary command execution on your CI/CD runner. That is the highest possible severity score, and it affected the exact deployment pattern most enterprises use: automated GitHub Actions workflows processing contributor pull requests. This guide breaks down what happened, why it matters beyond the patch, and what a CISO-level hardening program looks like for teams running Gemini CLI in production.

The CVSS 10.0 Vulnerability: What Actually Happened

CVE-2026-12537 was discovered independently by Elad Meged (Novee Security) and Dan Lisichkin (Pillar Security), both through Google's Vulnerability Rewards Program. The vulnerability was published April 24, 2026, and registered in the National Vulnerability Database on June 23, 2026.

The root cause is architectural, not incidental. Gemini CLI operates in two modes: interactive and headless. In interactive mode, the CLI always prompts before trusting a new workspace folder. In headless mode, the mode used by CI/CD systems, that confirmation gate was removed. The CLI automatically trusted the current workspace and loaded .gemini/.env configuration files without any sandbox protection.

An attacker who can place a .gemini/.env file in a repository branch (which any contributor can do via a pull request) achieves pre-sandbox host-level command execution. Because this happens before sandbox isolation activates, the attacker has full access to the runner environment, including all secrets injected by the CI system.

A second flaw compounded the first. Running with --yolo mode, common in automated workflows because it reduces interruptions, disabled the fine-grained tool allowlist defined in ~/.gemini/settings.json. Organizations that had carefully configured permitted tool sets found that --yolo nullified those controls entirely. Pillar Security called this the "lethal trifecta":

Workflow secrets in the runner environment: GEMINI_API_KEY, GITHUB_TOKEN, cloud credentials

Every public GitHub issue and PR body is attacker-controlled input the agent reads as trusted context

Tools like gh issue edit and curl provide outbound exfiltration channels

The fix shipped in @google/gemini-cli version 0.39.1 (stable) and 0.40.0-preview.3. Tool allowlists are now enforced even under --yolo mode, and GEMINI_TRUST_WORKSPACE must be explicitly set to false in workflows processing external code. The same vulnerable workflow pattern was found in at least eight other Google-maintained repositories.

The Prompt Injection Attack Chain: PR Comment to Credential Exfiltration

Independent of CVE-2026-12537, researchers at Wyze Labs and Johns Hopkins University disclosed a prompt injection technique they called "Comment and Control" on April 15, 2026. This attack does not require the headless trust vulnerability; it works against any Gemini CLI deployment that processes GitHub issue or PR content.

The attack chain:

Attacker opens or modifies a GitHub issue with a crafted body containing a fake "Trusted Content Section" appended after the legitimate issue content

The injected section overrides Gemini's safety system prompt instructions

When a Gemini CLI workflow processes the issue (during automated triage, for example), it reads the injected instructions as authoritative

Gemini follows the injected command to post GEMINI_API_KEY as a public GitHub issue comment, visible to any repository watcher

The researchers confirmed successful credential exfiltration across three AI coding agents: Claude Code, Gemini CLI, and GitHub Copilot. The Copilot exfiltration was more severe, capturing GITHUB_TOKEN, GITHUB_COPILOT_API_TOKEN, GITHUB_PERSONAL_ACCESS_TOKEN, and COPILOT_JOB_NONCE via a base64-encoded committed file.

Why conventional DLP misses this: The agents used GitHub's own API as the exfiltration channel. Secrets were posted as GitHub issue comments or committed as files, not sent to external endpoints. Security tools that monitor outbound network traffic for sensitive strings do not observe internal GitHub API calls, so the exfiltration produces no alert.

Cyera Research Labs separately identified two additional exploitable command injection and prompt injection vulnerabilities using an LLM-augmented research methodology. Semgrep scanned Gemini CLI's TypeScript codebase and flagged 6,115 potential issues; LLM triage narrowed to 12 leads; manual validation confirmed two exploitable vulnerabilities within 48 hours.

CI/CD Supply Chain Attack Vectors

The vulnerability disclosures led to a broader finding: Gemini CLI workflows had the same structural design problem across many repositories, not just the Gemini CLI repository itself.

Pillar Security demonstrated a full supply chain compromise of the gemini-cli GitHub repository (101,000+ stars) using a single crafted public issue. The exploit chain moved from issue creation to arbitrary code pushed to the main branch. The same vulnerable workflow pattern appeared in at least eight other Google-maintained repositories.

Agent-to-agent privilege escalation, documented by Pillar Security on August 3, 2026, introduced a more sophisticated vector. Google's Agent Development Kit (ADK) ran a low-privilege PR triage agent under an adk-bot Collaborator account that was over-permissioned. An injected payload in a public issue forced that triage agent to post a comment beginning with @gemini-cli /review, triggering the higher-privilege Gemini CLI review workflow. That workflow ran on the CI runner and exposed ADK_TRIAGE_AGENT, GOOGLE_API_KEY, and ADK_GCP_SA_KEY. Google fixed this on July 21, 2026.

This is the first documented real-world agent-to-agent privilege escalation in a production multi-agent CI/CD system. It demonstrates that the attack surface is not just Gemini CLI in isolation: any agent that can trigger another agent, and has weaker input validation, becomes an indirect attack path to the higher-privilege target.

The npm supply chain vector also targets Gemini CLI at the workstation level. In the nx package incident (August 2025), a malicious postinstall script specifically invoked AI CLIs, including Gemini CLI, with jailbroken prompts to scan ~/.ssh, .env files, cryptocurrency wallets, and GitHub tokens. This shows that Gemini CLI is a recognized target in npm supply chain attacks, not just CI/CD pipeline attacks.

MCP Integration: The Expanding Attack Surface

CVE-2026-0755, discovered in gemini-mcp-tool, introduced two distinct attack paths:

Windows: OS command injection. The execAsync method failed to sanitize user-controlled input before incorporating it into system command execution. On Windows, unquoted cmd.exe metacharacters break out of the intended command context. The vulnerability required no authentication and no user interaction, with a network-based attack vector.

macOS/Linux: Arbitrary file exfiltration via @file parser. Untrusted prompt input reaches Gemini CLI's @file parser. An attacker can reference arbitrary local files using path traversal: @/etc/passwd, @~/.ssh/id_rsa, @../../secret. The fix in version 1.1.6 added assertSafeFileReferences() to contain @file references to the working directory and hardened Windows cmd.exe argument quoting.

Beyond the specific CVE, MCP tool descriptions are an unsanitized attack surface. A malicious or compromised MCP server can embed arbitrary instructions in what appears to be help text, and Gemini CLI follows those instructions without user awareness. This is known as "tool poisoning." Gemini CLI, like Claude Code, Cursor, and GitHub Copilot, auto-executes project-defined MCP servers upon folder trust acceptance without separately disclosing that code execution will occur.

The rug pull risk: MCP servers run as separate processes at developer-level OS privileges. A server that was legitimate at installation time can be updated to include malicious instructions. Enterprises have no native mechanism to detect or block such updates absent explicit version pinning and integrity verification.

For teams building on the Claude Code enterprise security model, the MCP attack surface is substantially similar. The control frameworks are comparable: version pinning, allowlisting by server name, and treating MCP servers as untrusted third-party code.

CISO Hardening Checklist

The following controls address the documented attack vectors. Priority ordering reflects exploitability and blast radius.

Immediate (patch + configuration):

Pin @google/gemini-cli to 0.39.1 or later in all package.json and workflow YAML files. Lock with npm ci or equivalent to prevent version drift.

Set GEMINI_TRUST_WORKSPACE=false as an environment variable in every GitHub Actions workflow that runs Gemini CLI. Add this to your organization-level GitHub environment secrets so it applies globally.

Replace pull_request trigger with pull_request_target in workflows that must process external contributor code. This prevents external code from running with access to repository secrets.

Remove --yolo from all production workflows. Define explicit tool allowlists in ~/.gemini/settings.json and enforce them at the system level using the enterprise settings file documented at Gemini CLI for the Enterprise.

Pin gemini-mcp-tool to version 1.1.6 or later. Audit all MCP server dependencies for semantic version ranges that permit unverified updates.

Near-term (process + monitoring):

Treat all issue and PR metadata as untrusted input. Do not pass raw issue bodies or PR descriptions to Gemini CLI without sanitization. Use structured prompt templates that separate instruction context from user-controlled content.

Scope bot account permissions to minimum required. Separate triage agents from review agents. Do not assign Collaborator-level access to automated accounts performing read-only operations.

Audit which workflows can trigger other workflows. Map comment-triggered workflow chains. Remove any case where a lower-privilege agent can activate a higher-privilege agent via a comment or event emission.

Enable GitHub Actions audit logging and alert on unexpected gh CLI invocations within Gemini workflows, particularly any calls to gh issue create, gh issue edit, or curl to external endpoints.

Run workloads in sandboxed containers. Gemini CLI supports --sandbox-image for custom Docker images. Use a minimal image with read-only filesystem, non-root user, and explicit GPU device restrictions.

Ongoing (governance):

Implement MCP server allowlisting by name and version. Treat unapproved MCP servers as untrusted third-party code. Require a security review before adding any new MCP server to a production workflow.

Monitor for GEMINI_API_KEY rotation needs. After any incident where Gemini CLI processed untrusted content, treat the API key as potentially compromised and rotate. Extend this to all secrets present in the runner environment.

Conduct agent-specific red team exercises. Standard penetration tests do not cover prompt injection via issue metadata. Build or commission test cases that confirm your workflows reject injection payloads before they reach production.

You can also use BeyondScale's Securetom scan to surface exposed AI agent endpoints and prompt injection surfaces in your CI/CD environment automatically.

Detection and Incident Response

If you suspect a Gemini CLI compromise via prompt injection or the CVSS 10.0 vulnerability, the following indicators and steps apply.

Indicators of compromise:

• GitHub issue comments from your bot account containing environment variable names or base64-encoded strings
• Commits from bot accounts to branches that did not originate from a human-initiated workflow
• gemini-cli process spawning curl, wget, or gh with outbound destinations not in your allowlist
• Unexpected reads of ~/.ssh, ~/.aws/credentials, or .env files in process audit logs
• GOOGLE_API_KEY or GEMINI_API_KEY usage from IP addresses not associated with your CI infrastructure

Response steps:

Revoke compromised credentials immediately. Rotate GEMINI_API_KEY in Google Cloud Console and disable the compromised key before investigating scope. Rotate GITHUB_TOKEN and any other secrets present in the runner environment.

Review GitHub Actions audit log for the 30-day window prior to detection. Filter for the bot account and look for issue comment creation, commit pushes, and workflow triggers.

Check Google Cloud audit logs for API calls made with the compromised key. Identify which services were accessed and what data was read or modified.

Assess downstream blast radius. If the GITHUB_TOKEN was exfiltrated, review repository write access. If cloud service account keys were exposed, audit IAM activity for the service account.

Preserve artifacts. Export GitHub Actions logs, Google Cloud audit logs, and the specific issue or PR body that triggered the incident before deleting or archiving.

For a complete AI security incident response program, see our guide on AI security assessments for enterprises managing agentic CI/CD workflows.

Why This Matters Beyond the Patch

The Gemini CLI vulnerabilities are symptoms of a structural problem in how AI coding agents are integrated into CI/CD infrastructure. The agents were designed for interactive developer use, where a human confirms workspace trust, reviews proposed tool calls, and interrupts unexpected behavior. In CI/CD, all three of those human safety mechanisms are absent.

OWASP's LLM Application Security Top 10 identifies indirect prompt injection (LLM02) and supply chain vulnerabilities (LLM05) as primary risks for agentic deployments. Both are directly implicated in the Gemini CLI incidents. NIST's AI Risk Management Framework addresses these categories under the Govern, Map, and Measure functions, requiring organizations to inventory AI system components, assess their attack surfaces, and establish monitoring controls.

The enterprises most at risk are those who adopted Gemini CLI quickly for developer productivity and configured it with operational convenience, using --yolo mode, broad bot account permissions, and pull_request triggers, before the security architecture was fully understood.

Conclusion

Gemini CLI is a capable AI coding agent. The CVSS 10.0 RCE and the associated prompt injection vulnerabilities are patched. But patching does not address the underlying design pattern: an agent with access to CI secrets, processing untrusted external input, in a mode that was designed to require no human confirmation. Every control in the hardening checklist above exists because that design pattern, in its default configuration, transfers the trust decision from the developer to the attacker.

Security teams should treat Gemini CLI the same way they treat any third-party code running with production access: with explicit scope limits, monitored execution, and a tested incident response plan. The CVE is fixed. The attack surface remains.

Run a Securetom scan to identify exposed AI agent endpoints and prompt injection surfaces in your organization's CI/CD infrastructure, or contact BeyondScale to discuss a full AI security assessment for your agentic development environment.