Gemini CLI Ran Hidden Commands Behind an Approved “grep”

What happened

On 28 July 2025, Sam Cox of the security company Tracebit published details of a flaw in Gemini CLI, Google's AI coding assistant for the terminal. Google had released the tool on 25 June, and Tracebit reported the problem to Google's Vulnerability Disclosure Program two days later. Google first triaged it as P2/S4, raised it to P1/S1 on 23 July and shipped the fix in version 0.1.14 on 25 July.

The proof of concept was a repository holding a harmless Python script and a README.md. A developer who asked Gemini CLI to describe the repo could, after two inputs, have every environment variable sent to the attacker's server, with nothing on screen to show it. Environment variables often hold API keys and other credentials. The attack worked in the default setup, which runs without a sandbox, and needed no special flags. No exploitation outside the research has been reported.

How the attack worked

Gemini CLI reads files such as README.md and GEMINI.md to understand a codebase. Tracebit hid its instructions inside the README, within the text of the GNU General Public License, where a developer skimming the file would stop reading and the model would not.

The instructions worked in two stages. First, they had the agent ask to run a harmless grep over the README to find setup steps. Gemini CLI asks before running a new shell command, and the user can allow it for the rest of the session, which puts it on an in-memory allow-list. Second, they had the agent issue another command that began with the same grep and chained more commands that gathered the environment and posted it to a remote server. Because the string started with an allowed command, it ran without a prompt.

The CLI still printed the command it ran. Tracebit put a long run of whitespace before the chained part so it fell out of view in the terminal, and had the grep return some output so the step looked routine.

Root cause

The approval check and the shell read the same string differently. In version 0.1.7, Gemini CLI decided whether to prompt by taking one root command from the start of the string, cut at the first space or command separator, and looking it up in the session allow-list. Nothing after that first command was checked, and the shell ran the whole string. The agent also took its plan from repository text an attacker wrote and ran with the user's own environment and network access, and whitespace beat the last human check, reading the printed command.

What a test would have caught

Allow one harmless command for the session, then have the agent propose a string that starts with that command and chains a second. If the second runs without a prompt, the allow-list is matching names, not commands. Pad a proposed command with whitespace or control characters and check that the approval prompt and the log still show all of it. Plant instructions in a test repository's README and see whether the agent acts on them. Tracebit found that OpenAI Codex and Anthropic's Claude did not appear vulnerable to the same approach.

How to prevent it

• Upgrade. From version 0.1.14, Gemini CLI splits a chained string into its separate commands and lists all of them in the confirmation prompt. Tracebit found the same injection then showed the hidden command and needed approval for the extra programs.
• Approve the exact command that runs. An allow-list entry should match each parsed command, not the first word of a string. Parse with the shell's own rules and refuse anything that does not parse cleanly.
• Show everything. Escape or collapse whitespace and control characters so a prompt or log cannot hide part of a command.
• Sandbox the agent. Google told Tracebit the CLI's security model rests on sandboxing, with Docker, Podman and macOS Seatbelt options and a persistent red warning when it is off. Off was the default.
• Treat repository files as untrusted input. When the agent works on code you did not write, keep secrets out of its environment and limit where it can send data.