MCP 进了标准，也进了漏洞清单

MCP 现在的官方规范版本是 2026-07-28（modelcontextprotocol.io 上标的当前版本）。这个日期本身值得注意：一年前这个协议的第一个版本才刚发布。

协议跑得快，问题也跟着来了。同一时间窗口里，MCP 服务器开始出现在漏洞披露列表上。这两件事放在一起看，才能判断现在企业内部接入 MCP 处于什么阶段。

规范这一年改了什么

按官方版本串起来的轨迹：

版本	关键变化
2024-11-05	初版
2025-03-26	引入 OAuth、Streamable HTTP
2025-06-18	结构化的工具输出，移除 batching
2025-11-25	OIDC、图标元数据
2026-07-28	核心转向无状态：去掉会话与 init 握手

最新这一版的改动最容易被低估，但影响最大。无状态意味着「一次连接 = 一个 Agent」这个隐含假设没了，之前靠长连接维持的鉴权上下文、进度推送、会话内权限记忆，都要换方案。对运维来说这也意味着 MCP Server 可以像普通 HTTP 服务一样横向扩，不必维持粘滞会话——这是它能否进生产环境的关键一条。

协议管理层面，2026 年多家媒体报道协议已移交中立组织（报道中提到的时间集中在 2026 年 7 到 8 月，Linux Foundation 旗下的 Agentic AI Foundation 在 9 月推出了 MCP 相关的认证）。这几处的具体日期与细节我没有逐条读到一手公告，建议引用时再核一次，能确定的是：规范不再是单一厂商说了算了。

攻击面：两类老毛病，一个新外壳

2026 年 8 月底到 9 月中，FreeBuf 梳理了 23 个真实 MCP Server 的漏洞（涉及 GitLab、SearXNG、MySQL 等组件），时间窗口是 2026-08-25 到 09-15。查下来主要是两类：

默认不鉴权。 MCP Server 起在一个端口上，本地工具能连，局域网也能连。开发者本机跑通了，容器化时端口一映射，就成了一个对外的、能执行动作的接口。这类问题在 REST 时代见过千百遍，只是换成了 MCP 的外壳。

DNS 重绑定。 面向本地桌面客户端的 MCP Server 常靠 Origin 头校验来挡住外部访问。攻击者把自建域名的 DNS TTL 调到很低，先让浏览器解析到 127.0.0.1，Origin 校验通过后改指到自己的服务器，就绕过去了。这是老的本地服务防护缺陷，MCP 把它重新推到了台面上。

至于工具投毒（tool poisoning）和 rug-pull——工具描述里藏指令，或者安装后偷偷改掉描述——这类是协议层面的固有张力，不是某个实现的 bug。OWASP 的 Agentic AI 安全 Top 10 已经把它单列。现实里对应的动作是：Server 要固定版本、固定来源，别让它自动更新。

接入前的四项检查

给要往公司环境里加 MCP Server 的人，按可执行顺序：

1. 确认它监听在哪。只绑 127.0.0.1 还是 0.0.0.0。这一条能挡掉上面第一类漏洞的大部分。
2. 鉴权不能省，且不能沿用别人的身份。给每个 Server 发独立凭据，权限按工具维度授予，默认只读。
3. Origin / Host 校验开起来，并且不指望它单独够用。DNS 重绑定的防线得靠「不暴露危险接口」本身补：不要在只靠 Origin 头保护的端口上提供能改状态的能力。
4. 工具清单落盘、锁定、比对。把当前可用的工具名与描述导出来存好。Server 更新后重新导一次做 diff。描述被悄悄改掉，这件事就有了发现手段——这是成本最低的投毒检测。

一个容易走偏的判断

规范刚发布、漏洞刚批量出现，很容易得出「再等等，等生态稳定」。

我的看法相反。协议在定型，这反而是可以动手的信号——因为需要改的都是常规工程动作：端口绑定、独立凭据、只读默认、清单比对。这些不是为 MCP 发明的，任何有经验的团队都已经会做。

真正还没答案的是模型侧的行为：工具描述里的内容会不会被当成指令执行，这取决于模型自身的判断。工程能做的只是缩小它能造成的后果。把权限收到只读，再逐步放开——先接进来观察，比等一个不会来的「规范稳定」更实际。