Critical Gemini CLI Flaw Lets Attackers Target CI Workflows With Remote Code Execution

Google has patched a critical Gemini CLI vulnerability that could allow remote code execution in automated development workflows.

The issue affects the npm package @google/gemini-cli and the official google-github-actions/run-gemini-cli GitHub Action. The highest risk applies to headless environments, especially CI/CD pipelines that process pull requests, issues, comments, or files from outside contributors.

The flaw is tracked as GHSA-wpqr-6v78-jr5g. GitHub rates it as critical with a CVSS score of 10.0. There is no known CVE ID listed for the advisory at the time of publication.

What went wrong in Gemini CLI

The vulnerability comes from two security gaps in how Gemini CLI handled trust and tool permissions.

The first issue involved workspace trust in headless mode. Older versions automatically trusted the current folder when Gemini CLI ran in non-interactive environments such as GitHub Actions.

That behavior could let the CLI load local configuration files, environment variables, or settings from a .gemini/ directory without explicit approval. If an attacker could place malicious content in that workspace, the workflow could process it as trusted input.

Why the bug can lead to remote code execution

The second issue involved tool allowlisting under --yolo mode. In older versions, Gemini CLI did not properly enforce fine-grained tool restrictions from ~/.gemini/settings.json when this mode was enabled.

For example, a workflow might intend to allow only a narrow shell command. Under the vulnerable behavior, a broader run_shell_command permission could allow more dangerous commands than expected.

That gap becomes dangerous when Gemini CLI processes untrusted prompts, pull requests, issues, or repository content. A prompt injection attack could push the tool toward command execution inside a CI runner.

Affected and patched versions

Component	Affected versions	Patched versions
@google/gemini-cli	Earlier than 0.39.1	0.39.1
@google/gemini-cli preview channel	0.40.0-preview.2	0.40.0-preview.3
google-github-actions/run-gemini-cli	Earlier than 0.1.22	0.1.22

Google’s update also introduces a breaking security change. Headless mode no longer automatically trusts workspace folders.

This means some existing CI/CD workflows may stop loading workspace-specific configuration until teams explicitly update their trust settings.

Who faces the highest risk

The issue matters most for teams that use Gemini CLI in GitHub Actions or other automated pipelines.

Risk increases when the workflow reviews pull requests from forks, triages public issues, processes user-controlled comments, or runs with broad repository permissions.

The vulnerability also matters for teams that give Gemini CLI shell access. AI coding agents become more sensitive when they combine prompt handling, project context, secrets, and command execution in the same automated job.

What developers should do now

Teams should update @google/gemini-cli to version 0.39.1 or 0.40.0-preview.3. GitHub Actions users should update google-github-actions/run-gemini-cli to version 0.1.22 or later.

Workflows that pin a specific gemini_cli_version need extra attention. Those workflows may not receive the patched CLI automatically.

For trusted internal workflows, teams can set GEMINI_TRUST_WORKSPACE: 'true'. This should only be used when the workflow handles trusted code and trusted inputs.

For workflows that process outside contributors, teams should harden the workflow instead of blindly trusting the workspace.

Recommended actions:

• Update @google/gemini-cli to 0.39.1 or 0.40.0-preview.3.
• Update google-github-actions/run-gemini-cli to 0.1.22 or later.
• Audit workflows that pin gemini_cli_version.
• Avoid using GEMINI_TRUST_WORKSPACE: 'true' on untrusted forked code.
• Review all tool allowlists in ~/.gemini/settings.json.
• Limit shell command permissions wherever possible.
• Reduce GitHub token permissions to the minimum required.
• Treat pull request text, issue comments, and repository files as untrusted input.

Why this is bigger than one CLI bug

The Gemini CLI flaw highlights a wider problem in AI developer tools. These systems often read code, parse natural language, access repository context, and call tools that can change files or run commands.

That power makes them useful. It also means small trust mistakes can create serious attack paths.

CI/CD pipelines already handle secrets, tokens, release jobs, test environments, and deployment logic. When an AI agent runs inside that environment, teams need clear boundaries around what it can read, trust, and execute.

FAQ