Gemini CLI and run-gemini-cli Maximum-Severity CI Remote Code Execution - GHSA-wpqr-6v78-jr5g

Pillar Security reported a maximum-severity remote code execution affecting Google Gemini CLI and its companion run-gemini-cli GitHub Action. The flaw is tracked as GHSA-wpqr-6v78-jr5g, carries a CVSS score of 10.0, and was disclosed on April 24, 2026. An unprivileged external attacker could force malicious content to load as Gemini configuration and execute commands on a CI runner before the agent sandbox initialized.

What happened

Two compounding gaps produced the vulnerability. First, headless mode automatically trusted any workspace folder, loading attacker-supplied .gemini/ configuration without consent. Second, --yolo mode ignored fine-grained tool allowlists, so prompt injection could invoke arbitrary shell commands. Chained together, an external actor - a contributor opening a pull request, or anyone filing a public GitHub issue - could get malicious content loaded as Gemini configuration and run commands on the CI runner before the sandbox came up. That window exposed workflow secrets, cloud credentials, and source code.

Pillar Security first reported the issue on April 16, 2026 against the Google/draco repository and demonstrated the full attack on gemini-cli on April 20, 2026. Google published advisory GHSA-wpqr-6v78-jr5g and shipped patches by April 24, 2026, fixing Gemini CLI in 0.39.1 and the run-gemini-cli GitHub Action in 0.1.22. The fix removes the automatic workspace-folder trust in headless mode and restores allowlist enforcement so injected content can no longer reach arbitrary tool execution.

Why this is an agentic-endpoint risk

A coding-agent CLI running in CI is an AI artifact like any other, and its configuration is part of the artifact. When the CLI reads .gemini/ from a checkout, that configuration steers which tools the agent calls and what it is permitted to do. Treating it as inert repository data is the mistake: a fork's checkout is untrusted input, and headless auto-trust turned that input into agent policy. The injection was only the trigger - the loadable, attacker-controllable configuration was the surface.

This is the blind spot the agent layer creates. Network controls, EDR, and DLP do not reason about whether a .gemini/ file should be trusted or whether a tool call falls inside an approved allowlist before a sandbox exists. Those decisions live at the agent and CLI boundary. Mapping which endpoints and runners host AI CLIs, and what configuration they load, is the prerequisite for governing them - see fleet visibility. The same loaded-configuration pattern drove the Claude Code project-file issue tracked as CVE-2025-59536; the artifact-trust problem is recurring, not specific to one vendor.

How Anomity surfaces and governs it

Anomity inventories eight AI artifact types on every managed endpoint - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs - and classifies them. Gemini CLI and its configuration are managed artifacts, so a .gemini/ file arriving from a pull-request checkout, or a CLI version below 0.39.1 on a runner, is surfaced rather than silently trusted. You see where the affected agents and CLIs live across the fleet before deciding what to do about them.

On agents that expose a hook - for example a Claude Code PreToolUse hook - Anomity returns allow, deny, or log on each tool call before it runs. The defense that maps directly to this CVE is at runtime governance: deny tool calls that originate before sandbox initialization or that fall outside an approved allowlist. That is precisely the guardrail --yolo mode stripped. Decisions route to your SIEM, Slack, email, or Jira, so the deny is visible to the people who own the pipeline.

Every decision lands in a queryable 90-day audit trail - see outcomes. After an event like this you can answer concrete questions: which runners executed a pre-0.39.1 Gemini CLI, which tool calls were denied, and whether any configuration loaded from an untrusted checkout. Anomity collects metadata only, with on-endpoint secret redaction, and is SOC 2 Type II. It complements your existing Network, EDR, DLP, and GRC stack rather than replacing it; how it works and the compare section lay out where it fits.

What to check across your fleet

• Update Google Gemini CLI to 0.39.1 or later everywhere it runs, including CI runners, container images, and developer laptops.
• Pin the run-gemini-cli GitHub Action to 0.1.22 or later, and repin any floating tags or branch references to the patched commit.
• Confirm headless invocations no longer auto-trust workspace folders, and that no .gemini/ configuration is read from a fork's pull-request checkout.
• Audit any pipeline that ran --yolo mode against untrusted content for command execution between checkout and sandbox initialization.
• Rotate workflow secrets, cloud credentials, and tokens that were exposed to affected runners during the vulnerable window.
• Inventory every endpoint and runner that hosts an AI coding CLI and record which configuration sources it loads.
• Enforce a tool allowlist on agent CLIs and deny tool calls that originate before sandbox initialization.

This advisory is part of the Securing AI Coding Agents and CLIs pillar, which covers the trust and configuration patterns behind issues like GHSA-wpqr-6v78-jr5g. If you want to see how Anomity inventories CLI configuration as a managed artifact and applies allow, deny, or log at the hook, request early access.