一篇 10 月 15 日提交的 arXiv 论文（编号 2610.22301，标题「My Credentials, Please」）给 MCP 这座「AI 的 USB-C 接口」点出了一道暗门：文件系统能力洗白。研究者发现，攻击者可以诱导某个看似无害的 MCP 工具，借由参数越界去读取它声明范围之外的宿主文件——而客户端基于声明参数给出的批准提示，根本框不住底层服务器进程的实际文件系统权限，于是宿主凭据被悄悄顺着普通工具输出泄露出去。
一次扫描，戳破「按工具批准」的安全感
论文对横跨九个注册表的 21097 台 MCP 服务器做了扫描，筛出 787 台（约 16.4%）虽然自报为非文件系统类、却实际带有文件系统能力的服务器；再用动态验证确认了 150 台真正脆弱的实例。协调披露最终产出 13 份安全公告，其中包括 Anthropic 自家 Git MCP Server 的两个 CVE，例如 CVE-2026-27735。攻击手法的名字很形象——「文件系统能力洗白」：攻击者操控工具参数（比如给 git_add 传一个带 ../ 的路径穿越），让本应老实的工具去读声明契约之外的宿主文件；客户端的批准闸门按声明参数放行，但真正跑起来的服务器进程带着宿主环境的文件系统宽权限，越界凭据就混在正常的工具输出里流了出去。
根因：本地 stdio 服务器的环境权限没被收口
脆弱点落在 MCP 的权限模型上：本地 stdio 服务器以宿主环境的文件系统权限运行，而客户端那层按声明参数做的批准，框不住底层进程的环境权限。受影响的清单里，Anthropic 的 Git MCP Server（mcp-server-git 早于 2026.1.14 的版本）是具象的一例。对它的修法是升级到 2026.1.14 或更高。但更具普遍意义的缓解是：把任何接收路径的 MCP 工具都当作攻击者可控，对第三方 MCP 服务器做沙箱加固，而不是轻信它声明的契约。这条攻击类之所以值得整个行业警惕，是因为它利用的是协议最被广泛采纳的形态——本地 stdio 服务器——意味着成千上万台已部署的服务器都站在同一个授权盲区的门口。
给智能体安全的一条旁注
这篇的增量认知，是把「智能体安全」的关注点从「模型会不会说错话」拉到了「工具调用链上的授权边界」：当一个智能体被指向第三方 MCP 服务器时，真正危险的不是它说了什么，而是那个服务器进程能在宿主机器上读到什么。它和近期一批被覆盖的「智能体工具链敞口」构成同一条线索的不同截面——网关型 CVE、凭据外泄、权限越界，本质都是「授权模型没跟着工具生态一起长大」。需要清醒的是，论文的 150 台确认脆弱实例只是抽样验证出的下限，真实暴露面取决于各注册表的扫描覆盖率；且升级 Git MCP 只是堵了具象的一处，凡是接收路径、URL 或命令参数的 MCP 工具，都应默认按不可信输入对待。把这篇和站内此前覆盖的「MCP 工具生态」「智能体权限治理」放在一条线上，MCP 的下一程挑战，不再是「连不连得上」，而是「连上之后，谁能读到什么」。
目前官方及行业暂未披露更多细节，包括九个注册表中各家的脆弱服务器具体分布、其余 11 份公告涉及的厂商清单，以及各主流 MCP 客户端是否已默认启用沙箱隔离，后续将持续跟进迭代动态。这篇把「MCP 文件系统能力洗白」从论文概念，推进成了有 13 份公告与 2 个 CVE 背书的现实攻击类。