CVE-2026-0755: command injection and file theft in gemini-mcp-tool

What is this?

On June 18, 2026, the GitLab Advisory Database published CVE-2026-0755, a critical flaw in gemini-mcp-tool — a community npm package (repository jamubc/gemini-mcp-tool) that exposes Google’s Gemini CLI to AI assistants as a Model Context Protocol server. The advisory carries a CVSS 9.8 (CRITICAL) score and is classified as CWE-78, OS command injection. It was also issued as ZDI-26-021 and tracked as GHSA-4h5r-5jm8-jxjm.

The bug is not a model jailbreak. It is a classic injection that happens to live inside an agent toolchain: untrusted text that an assistant feeds to the MCP server is passed through to a shell and to the Gemini CLI’s file parser without adequate neutralization. All versions from 1.1.2 up to (but not including) 1.1.6 are affected, and the fix landed in 1.1.6.

How it works

An MCP server’s job is to take instructions from an AI client and turn them into actions — here, invoking the gemini CLI. The vulnerable releases built that command line in a way that did not safely separate data (the user’s or document’s text) from command structure. Two distinct problems followed.

The first is arbitrary file exfiltration. Gemini CLI supports an @file syntax that inlines a file’s contents into the prompt. Because untrusted prompt input could reach that parser unchecked, an attacker-controlled string could reference files far outside the intended workspace — the advisory cites examples such as reading system or secret files via paths like @/etc/passwd, @~/.ssh/id_rsa, or @../../secret. The file contents are then pulled into the model context and can be sent back out.

The second is OS command injection on Windows. The tool relied on a broken shell:false double-quote wrapping that did not neutralize cmd.exe metacharacters. Unquoted special characters in the input could break out of the intended argument and execute attacker-chosen commands.

# Conceptual data flow — NOT a working payload
AI client ──(untrusted prompt / document text)──▶ gemini-mcp-tool
        builds command line with unsafe quoting
              ├─▶ Gemini CLI @file parser  ──▶ reads [REDACTED arbitrary path]
              └─▶ cmd.exe (Windows)        ──▶ executes [REDACTED injected command]

The combination is what makes this dangerous in an agent setting. An assistant that summarizes a web page, reads a repository, or processes an email is routinely handling content an attacker controls — the classic indirect prompt injection surface. When that content can steer a tool into reading secrets or running commands, the lethal trifecta — private data, untrusted input, and an exfiltration path — is satisfied without the model ever being “jailbroken.”

Why it matters

MCP servers are glue code, and glue code is where trust boundaries blur. The model here behaves correctly; the failure is ordinary input handling in the bridge between the agent and the operating system. This is the same pattern Microsoft flagged when prompts become shells: the moment natural-language input is concatenated into a command, decades of command-injection lessons apply again — except the “user input” now arrives indirectly, through whatever document or site the agent was asked to read.

The blast radius depends on where the server runs. On a developer laptop it can mean leaked SSH keys and cloud credentials; in CI or a shared agent runtime it can mean code execution with whatever privileges the MCP process holds. Because the package sits in the npm dependency graph of agent setups, this is also a supply-chain exposure: many users never audit the third-party MCP servers they wire into their assistant.

Defenses

1. Upgrade now. Move gemini-mcp-tool to 1.1.6 or later. The fix removed the broken shell:false double-quote wrapping, added an assertSafeFileReferences() check to confine @file references to the working directory, and hardened Windows cmd.exe argument quoting.
2. Never build shell command lines from prompt text. Pass arguments as an argv array to a non-shell exec API; avoid string interpolation into cmd.exe//bin/sh. Treat all model- and document-derived strings as untrusted.
3. Confine file access. Any @file-style inlining must be canonicalized and constrained to an explicit allowlisted directory, rejecting traversal (../) and absolute paths to sensitive locations.
4. Least privilege for MCP servers. Run each server as a low-privilege account in a sandbox or container, without ambient cloud credentials or SSH keys in scope. See MCP stdio transport is RCE by design for why the runtime, not the model, is the boundary that matters.
5. Inventory and pin your MCP supply chain. Track which third-party MCP servers are installed, pin versions, and subscribe to advisories (GHSA, NVD, vendor feeds) so a CVSS 9.8 in glue code does not sit unpatched.
6. Add dependency and command-injection scanning. SCA tooling flags vulnerable package versions; static checks for shell construction catch the next instance before it ships.

Status

Item	Reference	Date	Notes
Advisory (GLAD)	CVE-2026-0755	2026-06-18	OS command injection + @file exfiltration, CVSS 9.8
NVD record	CVE-2026-0755	2026-06	CWE-78 OS Command Injection
ZDI advisory	ZDI-26-021	2026	RCE in execAsync, no auth required
Affected versions	>=1.1.2, <1.1.6	—	Fixed in 1.1.6

The lesson is not “MCP is unsafe.” It is narrower and older than that: an agent toolchain that concatenates untrusted text into a shell command or a file parser is an injection waiting to happen. Sanitize at the boundary, confine file access, and run the server with the least privilege it can do its job with.