Gemini MCP 工具零日漏洞允许远程攻击者执行任意代码
Gemini MCP 工具中存在一个严重的零日漏洞，该漏洞使用户在没有任何身份验证的情况下容易受到远程代码执行 ( RCE ) 攻击。 该漏洞被追踪为 ZDI‑26‑021 / ZDI‑CAN‑27783，并被分配了 CVE‑2026‑0755，其 CVSS v3.1 最高得分为 9.8，这反映了该漏洞易于利用且影响严重。
Gemini MCP 工具中存在一个严重的零日漏洞，该漏洞使用户在没有任何身份验证的情况下容易受到远程代码执行 ( RCE ) 攻击。
该漏洞被追踪为 ZDI‑26‑021 / ZDI‑CAN‑27783，并被分配了 CVE‑2026‑0755，其 CVSS v3.1 最高得分为 9.8，这反映了该漏洞易于利用且影响严重。
根据趋势科技零日漏洞计划 (ZDI) 的一份新公告，该问题会影响开源的 gemini-mcp-tool，这是一个旨在将 Gemini 模型与模型上下文协议 ( MCP ) 服务集成的实用程序。
漏洞概述
该安全公告中将供应商和产品均列为 Gemini MCP Tool / gemini-mcp-tool。漏洞的核心在于 execAsync 方法中对用户输入的处理不当。
该函数直接将输入传递给系统调用，而没有进行充分的验证或清理。
远程攻击者可以利用此命令注入漏洞，以服务帐户的权限在底层系统上执行任意代码。
由于攻击途径是基于网络的，并且不需要事先进行身份验证或用户交互，因此暴露于互联网或共享的环境面临特别高的风险。
该漏洞最初于 2025 年 7 月 25 日通过第三方平台报告给了供应商。
ZDI 在 2025 年 11 月跟进询问最新进展，但在未收到充分回复后，于 2025 年 12 月 14 日通知供应商，其打算将此案例作为零日漏洞公告发布。
协调一致的公开披露和咨询更新于 2026 年 1 月 9 日进行。
截至发稿时，尚未发布任何官方补丁或更新。因此，可采取的缓解措施有限。
ZDI建议严格限制对 Gemini MCP 工具的访问，确保其不直接暴露于互联网，并将交互限制在受信任的网络和用户之间。
管理员还应监控运行 gemini-mcp-tool 的系统，以发现可疑的进程执行和异常的出站连接，这些都可能表明攻击已成功。
关于作者
评论3次
这就是 针对于开发人员的定向投喂了吧，毕竟有的版本的那个contribute小工具已经被整体移除了。
即使是对开发人员的定向攻击，这个漏洞也算不是可以直接远程利用的RCE吧，这个CVSS评分有点看不懂，难道有其它的什么路径，可以远程触发？
这就是 针对于开发人员的定向投喂了吧，毕竟有的版本的那个contribute小工具已经被整体移除了。
好奇去看了下这个项目，感觉这个CVE有点奇怪啊，根据漏洞描述中存在漏洞的execAsync方法，关键字搜索，在1.1.2版本的代码中确实找到了对应的代码，在contribute.js代码中。 而这个contribute.js是提供给开发者对社区进行贡献，创建分支、提交代码时用的的一个交互式小工具，contribute.js内部大多逻辑调用execAsync时入参都是写死的命令行；少部分确实存在拼接，比如createFeatureBranch()中执行execAsync(`git checkout -b "${branchName}"`)，理论上branchName存在注入点。但是可以注入的前提是工具目录下存在一个符合代码上下文逻辑的git仓，正常安装的话不存在这玩意儿，我在本地poc验证的时候还是模拟创建了一个才可以注入成功。 另外，就算本地存在符合要求的git仓，但是这个contribute.js没有被mcp server的主逻辑代码调用（毕竟本来就是提供给开发者的本地交互式小工具），通过MCP看上去并不能直接调用到contribute.js中的方法，那么这个命令注入如何被远程利用呢？CVSS给到9.8，有点不理解。 另外，ZDI说厂商没有理他的漏洞，实际上在Jul 23, 2025的一个commit中，这个contribute小工具已经被整体移除了，而“该漏洞最初于 2025 年 7 月 25 日通过第三方平台报告给了供应商。”，也许这就是工具作者没有再理会这个漏洞的另一个原因（主要原因可能还是觉得这个风险没法真实被利用）。 Jul 23, 2025的commit：https://github.com/jamubc/gemini-mcp-tool/commit/6bfb9bc50f3818f473230323e2cd13f4a41d6b60