Google Patches CVSS 10 Gemini CLI RCE Flaw Threatening CI/CD Pipelines

Google has patched a maximum-severity (CVSS 10.0) remote code execution vulnerability in its Gemini CLI — the @google/gemini-cli npm package and the google-github-actions/run-gemini-cli GitHub Actions workflow — that allowed an unprivileged external attacker to force malicious content to load as Gemini configuration and execute arbitrary commands on host systems. Tracked as GHSA-wpqr-6v78-jr5g, the flaw is most dangerous in CI/CD and headless environments where pipelines run the CLI without user oversight. No CVE identifier has been assigned.

Gemini CLI RCE: What We Know So Far

The vulnerability has two compounding root causes: unsafe workspace trust in headless mode and a tool allowlist bypass in --yolo mode.

Unsafe workspace trust: Prior to the patch, Gemini CLI automatically trusted the current workspace when running in non-interactive (headless) environments. This meant the tool would unconditionally load local configuration files and environment variables from the .gemini/ directory without requiring explicit user approval. An attacker who could place malicious content in that directory — via a compromised dependency, a poisoned pull request, or any write-access to the workspace — could instruct the CLI to execute arbitrary system commands.

Tool allowlist bypass: When running with the --yolo execution flag — which disables interactive confirmation prompts for automated pipelines — Gemini CLI failed to enforce its strict tool allowlists. This allowed prompt injection attacks to slip past intended restrictions and execute commands outside the approved tool set.

Affected components:
– @google/gemini-cli npm package (all versions before the patch)
– google-github-actions/run-gemini-cli GitHub Actions workflow

Tracking: GHSA-wpqr-6v78-jr5g, CVSS v4 base score 10.0 — no CVE assigned at time of writing.

Fix: Headless mode no longer automatically trusts workspace directories. Organizations that require workspace trust must now explicitly opt in by setting the GEMINI_TRUST_WORKSPACE=true environment variable, making the trust decision visible and auditable rather than implicit.

Why Gemini CLI RCE Matters

The attack surface is most critical inside CI/CD pipelines. Development teams are increasingly deploying AI coding agents like Gemini CLI as automated participants in build and release workflows. In those environments, the CLI runs headless with access to deployment secrets, cloud credentials, artifact registries, and production environment tokens stored in CI runner secrets.

A successful exploit requires no user interaction. Any attacker who controls content that lands in a workspace — a malicious npm transitive dependency, a crafted pull request that modifies .gemini/, or a supply chain compromise upstream — can trigger arbitrary code execution on the CI runner. That runner typically has credentials to push to production.

The --yolo mode bypass compounds the risk: pipelines designed for speed disable interactive prompts by design, and the allowlist was the remaining safety layer. When that layer can be bypassed with a prompt injection, there is no remaining check between a malicious prompt and a shell command.

The broader implication is architectural. AI tool integrations that “just work” in automated environments inherit the full trust context of those environments. Without explicit, auditable trust boundaries, they become reliable pivot points for supply chain attacks.

Gemini CLI RCE: What You Should Do Now

1. Update the npm package immediately. Upgrade @google/gemini-cli to the latest patched version:
   bash
npm update @google/gemini-cli
npm ls @google/gemini-cli # verify installed version

2. Pin the GitHub Actions workflow to a verified SHA. Update any workflow referencing google-github-actions/run-gemini-cli to pin a specific release tag or commit SHA rather than a floating @main or @latest reference:
   “`yaml

3. uses: google-github-actions/run-gemini-cli@v1.2.0 # replace with verified patched version
   “`

4. Audit headless pipeline usage. Search CI/CD configuration for all Gemini CLI invocations in headless or --yolo mode and review what workspace directories they can access and what secrets they inherit.

5. Remove GEMINI_TRUST_WORKSPACE unless explicitly required. After the patch, auto-trust is off by default. Audit any pipeline that sets GEMINI_TRUST_WORKSPACE=true and confirm whether that trust grant is intentional and necessary.

6. Restrict write access to .gemini/ directories. Ensure untrusted pull request code cannot add or modify files in .gemini/ directories before Gemini CLI runs. Treat that directory as a configuration security boundary, not a project file.

Detection and Verification Checklist

• Confirm the patched version is installed: npm ls @google/gemini-cli in each project that uses it
• Search all CI config files for run-gemini-cli references: grep -r "run-gemini-cli" .github/workflows/
• Audit for --yolo flags in pipeline scripts that invoke Gemini CLI
• Check for unexpected .gemini/ directories in repositories that trigger automated pipelines, especially in pull-request-triggered jobs
• Review CI runner logs for unexpected subprocess spawns (shell, python, bash) during Gemini CLI steps
• Search for GEMINI_TRUST_WORKSPACE=true across CI environment variable configurations
• Verify no external contributor pull requests have added or modified .gemini/ config content in the past 90 days

Sources: The Hacker News, Cybersecurity News, GBHackers, Penligent AI Research

Thank you for reading this post, don't forget to subscribe!