Gemini CLI Silent Code Execution via Allowlist Bypass - Tracebit

Tracebit discovered a flaw in Google Gemini CLI just two days after the tool's June 25, 2025 release that let an attacker silently run commands on a developer's machine while the developer asked Gemini to describe untrusted code. No CVE was assigned. Google fixed it in Gemini CLI 0.1.14 on July 25, 2025. This advisory covers what Tracebit disclosed, why a coding-agent allowlist bypass lands on the agentic-endpoint layer, and how to inventory and govern this class of chained-shell-command abuse.

What happened

Tracebit found that Google Gemini CLI in its default configuration could silently execute arbitrary commands when run against a repository carrying attacker-planted instructions. The attack combined two weaknesses. First, prompt injection: Tracebit placed malicious instructions in a context file (GEMINI.md) or in a README.md buried beneath the full text of the GNU Public License. A human recognizes the license and stops reading; Gemini reads the whole document. Asking it something as ordinary as "Tell me about this repo" was enough to act on the hidden instructions.

Second, an allowlist bypass. Gemini CLI compared a proposed shell command against its allowlist by checking only the start of the input. A command beginning with an approved prefix such as grep - the kind of read-only command a developer would mark "always allow" - passed validation even with extra commands appended. The injected prompt told Gemini to format one line opening with grep, padded with whitespace, then chained a semicolon and env and curl to read environment variables and exfiltrate them to an attacker server. Because the prefix matched, no second approval prompt fired, and misleading UX hid the appended commands from the developer, who saw only the benign grep.

Google fixed the issue in Gemini CLI 0.1.14 on July 25, 2025. The patched version displays the injected commands and requires explicit approval before running additional binaries, so a whitelisted prefix no longer launders a chained command. No CVE was assigned, so this exposure will not surface in CVE-keyed scanning - the only reliable way to find vulnerable endpoints is to inventory the Gemini CLI builds actually installed on them.

Why this is an agentic-endpoint risk

The attack surface here is not a server or a network path - it is the coding agent's own decision about whether a proposed shell command is safe to run. The malicious instructions arrive in a GEMINI.md context file or a README.md, exactly the artifacts an AI coding agent reads to understand a repository, and neither reports to a security tool. The exploit fires on the most ordinary developer action there is: cloning a repository and asking the agent what it does. No phishing and no privilege escalation - just untrusted text the agent treated as instructions, and an allowlist that approved a command on its prefix alone.

This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The chained ; env and ; curl ran inside a legitimate Gemini CLI process, so EDR sees a trusted binary doing its job; the network sees ordinary outbound HTTPS; and DLP sees nothing at rest, because the environment variables left through the agent's own approved tool call. AI agents and CLIs are part of the eight AI artifact types Anomity tracks per endpoint, adopted bottom-up the same way AI agents and MCP servers became the new shadow IT. The question is not whether one laptop is patched; it is which endpoints across the fleet run Gemini CLI before 0.1.14, and what shell commands those agents may chain past an approved prefix - and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Upgrading to Gemini CLI 0.1.14 closes this specific bypass, but the durable control is to treat every shell command an agent proposes as untrusted input and govern chained commands before they run, regardless of which prefix they open with. Anomity does that in three steps.

First, inventory. Anomity inventories the AI agents and CLIs on every managed endpoint as part of the eight AI artifact types it tracks, then classifies them. It captures the Gemini CLI version so you can find builds before 0.1.14, and records the context files - GEMINI.md and README content - those agents read, so you can see where untrusted instructions enter. Metadata only: secrets such as the environment variables this attack targeted are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook, Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A shell command that opens with an approved grep prefix but chains a semicolon and env or curl is evaluated on the whole command, not on its prefix - so it can be denied at the boundary even on a build that would have trusted it on prefix alone. That is exactly the control runtime governance provides while a vulnerable build is still being rolled forward. This is the same repository-supplied abuse the sibling Claude Code project-file RCE and token exfiltration advisory covers - untrusted input crossing a trust boundary the agent failed to enforce.

Third, keep the record. Every decision, and every Gemini CLI install, version change, and context file Anomity observes, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a disclosure like the Tracebit Gemini CLI finding lands - with no CVE to key on - you can answer which endpoints ran the affected versions, which repositories carried a GEMINI.md or README that fed the agent instructions, and what those agents were allowed to run, from a record rather than a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running Gemini CLI and record the installed version; flag anything before 0.1.14 and upgrade to 0.1.14 or later, which shows injected commands and requires explicit approval for additional binaries.
• Remember there is no CVE for this issue, so CVE-keyed scanners will miss it - find vulnerable builds by the binary version actually installed, not by an advisory feed.
• Enumerate GEMINI.md context files and README content in cloned repositories and treat them as untrusted instruction input the agent will read in full.
• Review any always-allowed shell commands (for example grep) and confirm approval is decided on the whole command, not on a matching prefix.
• Confirm tool calls from agents are evaluated at the hook with allow/deny/log, so a command that chains ; env or ; curl past an approved prefix is denied before it runs.
• Verify environment variables and other secrets are redacted on the endpoint so a captured context never carries credentials off the machine.
• Confirm every agent and CLI install, version change, and tool-call decision is written to a 90-day audit trail and routed to your SIEM.
• Cross-reference against the sibling Claude Code project-file RCE advisory to find endpoints exposed to more than one repository-supplied abuse path, and see the pillar on securing AI coding agents and CLIs for the full surface.

The Tracebit Gemini CLI finding is a reminder that a coding agent's allowlist is only as good as how it parses a command: a whitelisted grep prefix laundered a chained env and curl that exfiltrated environment variables, hidden from the developer by misleading UX. Upgrade Gemini CLI to 0.1.14 or later, then inventory the agents and CLIs your endpoints run and govern the resulting tool calls at the hook so chained commands cannot escape an approved prefix. For the full attack surface, see the pillar on securing AI coding agents and CLIs. To see Anomity govern the agent and CLI layer across your fleet, request early access.