Google fixes critical Gemini CLI flaw that could execute commands on host systems

Google has patched a critical security flaw in Gemini CLI and its related GitHub Action that could let attackers execute commands on host systems. The vulnerability received a CVSS score of 10.0, the highest possible severity rating.

The issue affected @google/gemini-cli and google-github-actions/run-gemini-cli in automated workflows. The main risk came from CI/CD environments where Gemini CLI ran in headless mode and processed untrusted repository content.

The flaw did not depend on tricking the AI model through prompt injection. Instead, it came from how the tool handled trusted workspace folders and configuration files before normal safety boundaries applied.

What caused the Gemini CLI vulnerability?

In earlier versions, Gemini CLI automatically trusted the current workspace folder when running in headless mode. This allowed the tool to load configuration files and environment variables from that folder without a manual trust decision.

That behavior became dangerous in workflows that reviewed user-submitted pull requests. An attacker could place malicious content inside a repository workspace and wait for an automated Gemini CLI job to process it.

If the workflow ran against that untrusted content, the malicious configuration could trigger command execution on the host system running the job. That could expose source code, workflow secrets, tokens, and cloud credentials.

At a glance

Item	Details
Affected tools	@google/gemini-cli and google-github-actions/run-gemini-cli
Severity	Critical
CVSS score	10.0
CVE status	No known CVE listed in the advisory
Main risk	Remote code execution in headless CI/CD workflows
Attack condition	Gemini CLI runs on untrusted workspace content
Patched Gemini CLI versions	0.39.1 and 0.40.0-preview.3
Patched GitHub Action version	0.1.22

Which versions are affected?

The official advisory lists @google/gemini-cli versions below 0.39.1 and below 0.40.0-preview.3 as affected. It also lists google-github-actions/run-gemini-cli versions below 0.1.22 as affected.

Google published the advisory on April 24, 2026. Novee Security later detailed how the flaw could turn AI-assisted development workflows into supply-chain attack paths.

The advisory says the impact is limited to workflows using Gemini CLI in headless mode. That means ordinary interactive use does not carry the same risk profile unless similar trust assumptions exist in the workflow.

Why CI/CD pipelines face the highest risk

CI/CD jobs often run with access to source code, repository tokens, deployment keys, cloud credentials, and build artifacts. If an attacker gets command execution inside that environment, the damage can move far beyond one pull request.

This makes the flaw especially dangerous for projects that use Gemini CLI to review, triage, or process external contributions. A malicious pull request could become a path into the runner that handles automation.

The attacker would not need a privileged account. The risky condition appears when the workflow processes untrusted content while giving Gemini CLI enough access to load and act on workspace configuration.

Google also changed tool allowlisting

The patch does more than change folder trust. Google also hardened how Gemini CLI handles tool allowlisting when it runs in –yolo mode.

In previous versions, –yolo mode could ignore fine-grained tool allowlists in certain situations. That created another path where untrusted input could lead to dangerous tool use, including shell command execution.

Starting with version 0.39.1, the Gemini CLI policy engine evaluates tool allowlisting under –yolo mode. Some workflows may need updates if they relied on the previous behavior.

What changed after the patch?

• Gemini CLI no longer automatically trusts workspace folders in headless mode.
• Headless workflows must make an explicit folder trust decision.
• Workspace configuration files are not processed until trust is configured.
• Tool allowlisting now applies more strictly under –yolo mode.
• Some older workflows may fail until administrators update their settings.

Google says workflows that run on trusted inputs can set GEMINI_TRUST_WORKSPACE: ‘true’. Workflows that process untrusted input should follow hardening guidance instead of simply enabling trust.

This distinction matters. Enabling trust blindly can restore old behavior and leave the same class of risk inside the development pipeline.

What administrators should do now

• 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.
• Review all workflows that run Gemini CLI in headless mode.
• Do not enable workspace trust for pull requests from unknown or untrusted contributors.
• Audit workflow logs for unexpected commands or configuration loading.
• Rotate exposed secrets if a risky workflow processed untrusted content.
• Restrict repository tokens and cloud credentials used by AI-assisted automation.
• Use least-privilege permissions for GitHub Actions jobs.

Teams should pay close attention to workflows that use Gemini CLI for pull request reviews, issue triage, automated fixes, or repository analysis. These are exactly the kinds of jobs that may touch untrusted content.

Security teams should also inspect whether any workflow pins an older Gemini CLI version through gemini_cli_version. If it does, the job may not automatically receive the patched version.

Why this matters for AI development tools

The Gemini CLI flaw shows that AI security is not only about prompts and model behavior. Modern AI coding agents also rely on files, shells, repositories, environment variables, workflow permissions, and tool configurations.

When those pieces run inside automation, they inherit the trust of the development pipeline. That gives attackers a powerful target if they can influence what the agent reads or runs.

This is why AI-assisted workflows need the same controls as other sensitive automation. Teams need explicit trust boundaries, limited permissions, secret isolation, and strong review rules for untrusted content.

FAQ