系统:运行中
← 返回所有攻击
AGENTS CRITICAL NEW

CVE-2026-0755:gemini-mcp-tool 中的命令注入与文件窃取

2026 年 6 月 18 日的公告详述了流行的 gemini-mcp-tool 如何让不可信输入抵达 shell 与 Gemini CLI 的 @file 解析器——CVSS 9.8 的 RCE 与文件外泄,已在 1.1.6 修复。

2026-06-21 // 5 min affects: gemini-mcp-tool, gemini-cli, model-context-protocol, mcp-servers

这是什么?

2026 年 6 月 18 日GitLab 公告数据库发布了 CVE-2026-0755,这是 gemini-mcp-tool 中的一个严重漏洞——该社区 npm 包(仓库 jamubc/gemini-mcp-tool)以 Model Context Protocol 服务器的形式,将谷歌的 Gemini CLI 暴露给 AI 助手。该公告评分为 CVSS 9.8(严重),归类为 CWE-78 操作系统命令注入。它同时以 ZDI-26-021 发布,并以 GHSA-4h5r-5jm8-jxjm 追踪。

这并不是模型越狱。它是一个恰好寄居在智能体工具链中的经典注入:助手交给 MCP 服务器的不可信文本,在没有充分中和的情况下被转发到 shell 以及 Gemini CLI 的文件解析器。从 1.1.2 到(不含)1.1.6 的所有版本均受影响,修复在 1.1.6 落地。

工作原理

MCP 服务器的职责是接收 AI 客户端的指令并将其转化为动作——在这里就是调用 gemini CLI。存在漏洞的版本以一种无法安全区分数据(用户或文档的文本)与命令结构的方式构建该命令行,由此产生两个不同的问题。

第一个是任意文件外泄。Gemini CLI 支持一种 @file 语法,可将文件内容内联进提示词。由于不可信输入能够不受检查地抵达该解析器,攻击者控制的字符串便可引用远在预期工作区之外的文件——公告举例称,可通过类似 @/etc/passwd@~/.ssh/id_rsa@../../secret 的路径读取系统文件或机密。随后文件内容被吸入模型上下文,并可能被回传到外部。

第二个是 Windows 上的操作系统命令注入。该工具依赖一种有缺陷的 shell:false 双引号包裹方式,无法中和 cmd.exe 的元字符。输入中未转义的特殊字符可以跳出预期参数,执行攻击者选择的命令。

# 概念性数据流——并非可用的攻击载荷
AI 客户端 ──(不可信的提示词/文档文本)──▶ gemini-mcp-tool
        以不安全的转义构建命令行
              ├─▶ Gemini CLI 的 @file 解析器 ──▶ 读取 [REDACTED 任意路径]
              └─▶ cmd.exe(Windows)        ──▶ 执行 [REDACTED 注入的命令]

正是这种组合使其在智能体场景中变得危险。一个会总结网页、读取代码仓库或处理邮件的助手,日常处理的本就是攻击者可控的内容——这正是间接提示词注入的经典攻击面。当这类内容能够引导工具去读取机密或执行命令时,致命三要素——私有数据、不可信输入与外泄通道——便在模型从未被越狱的情况下凑齐。

为何重要

MCP 服务器是黏合代码,而信任边界恰恰在黏合代码中变得模糊。这里模型表现正常,缺陷在于智能体与操作系统之间桥梁里那种普通的输入处理。这与微软指出的当提示词变成 shell 时是同一种模式:只要自然语言输入被拼接进命令,几十年来关于命令注入的教训就再次适用——只不过这份「用户输入」如今是间接到来的,经由你要求智能体读取的那份文档或网站。

影响范围取决于服务器运行在哪里。在开发者笔记本上,它可能意味着 SSH 密钥和云凭据被泄露;在 CI 或共享的智能体运行时中,它可能意味着以 MCP 进程所持有的权限执行代码。由于该包位于智能体配置的 npm 依赖图中,这也是一种供应链暴露:许多用户从不审计自己接入助手的第三方 MCP 服务器。

防御

  1. 立即升级。gemini-mcp-tool 升级到 1.1.6 或更高版本。修复移除了有缺陷的 shell:false 双引号包裹,新增了 assertSafeFileReferences() 检查以将 @file 引用限制在工作目录内,并加固了 Windows 上 cmd.exe 的参数转义。
  2. 切勿用提示词文本拼接 shell 命令行。 将参数以 argv 数组传给非 shell 的执行 API;避免向 cmd.exe/bin/sh 进行字符串插值。把一切来自模型或文档的字符串都视为不可信。
  3. 限制文件访问。 任何 @file 式内联都必须规范化,并限制在显式允许的目录内,拒绝目录穿越(../)以及指向敏感位置的绝对路径。
  4. MCP 服务器最小权限。 以低权限账户在沙箱或容器中运行每个服务器,作用域内不含云凭据或 SSH 密钥。参见 MCP 的 stdio 传输本质上即 RCE,以理解为何真正的边界是运行时而非模型。
  5. 盘点并锁定你的 MCP 供应链。 记录已安装的第三方 MCP 服务器,锁定版本,并订阅公告(GHSA、NVD、厂商源),让黏合代码中的 CVSS 9.8 不至于无人修补。
  6. 加入依赖与命令注入扫描。 SCA 工具会标记存在漏洞的包版本;针对 shell 构建的静态检查能在下一处问题上线前将其拦下。

状态

项目参考日期备注
公告(GLAD)CVE-2026-07552026-06-18操作系统命令注入 + @file 外泄,CVSS 9.8
NVD 记录CVE-2026-07552026-06CWE-78 操作系统命令注入
ZDI 公告ZDI-26-0212026execAsync 中的 RCE,无需认证
受影响版本>=1.1.2, <1.1.6已在 1.1.6 修复

教训不是「MCP 不安全」,而是更窄也更古老的一条:一个把不可信文本拼接进 shell 命令或文件解析器的智能体工具链,就是一次随时会发生的注入。 在边界处做净化,限制文件访问,并以满足任务所需的最小权限运行服务器。

Sources