MCP（Model Context Protocol）是 2025 年底以来智能体连接外部工具的事实协议，但 2026 年它连续曝出协议级问题。4 月 OX Security 披露：MCP 官方 SDK 的 STDIO 传输存在一个系统性设计缺陷——本地启动服务器进程时，底层会执行任何传入的操作系统命令，即便伪造服务器启动失败返回错误，命令照样执行。该漏洞波及约 20 万个实例，供应链下载量超 1.5 亿次，覆盖 Anthropic 官方支持的全部 11 种语言 SDK；Anthropic 确认这是有意设计，拒绝修改。
三种投毒攻击面
CSA 七月的研究笔记把攻击归为三类，结构同源——客户端默认信任它连接的服务器，且从不持续校验这种信任：
- 工具描述投毒：恶意指令藏在工具描述、参数 schema 里，智能体注册工具时就被劫持。
- rug-pull：服务器今天行为正常，某次更新后突然变坏，客户端毫无察觉。
- 工具影子化：影子工具冒充合法工具，窃取凭证。
学术侧也在跟进：arXiv 上 ShareLock 研究多工具阈值投毒，VIPER-MCP 用污点分析挖 MCP 服务器里的命令注入、SSRF 与路径穿越。
为什么不是修个 bug 就完事
因为 MCP 把工具元数据直接喂进模型上下文，模型天然把它当可信指令。这不是某家客户端的 bug，而是协议信任模型的结构性缺陷：只要工具描述能影响模型决策，投毒就可能发生。
工程上怎么挡
- 在客户端与 MCP 服务器之间加一层网关，对工具描述、返回内容做注入检测与白名单过滤。
- 工具凭证与模型进程隔离，就算上下文被劫持也拿不到密钥。
- 只信任经过审核的工具源，禁止智能体动态加载来路不明的 MCP 服务器。
特别要警惕供应链一環：很多 MCP 服务器本身依赖第三方 Python 包，一旦依赖被投毒，恶意代码就在服务器进程里执行，能拿到该服务器可见的一切上下文与凭证。安装时锁定依赖版本、定期做漏洞扫描，是这道防线上最容易被忽视却最致命的一环。