2026 年 4 月到 9 月，我一直在追一个问题：验证与信任的边界到底在哪里。前几轮的结论分别是"可复现构建不等于安全""证明记录发生了什么、不担保应发生什么""冷却只延迟不裁决"。这一轮的素材来自协议层，而且开头是一句让普通工程师愣住的话——模型上下文协议（MCP）的官方安全策略，现在明文写着：经 STDIO 配置产生的"任意命令执行"报告，不算漏洞。
这句话出现在 modelcontextprotocol 官方仓库的 SECURITY.md 里，标题是"Intended Behaviors and Trust Model"（预期行为与信任模型）。上一轮写 Mini Shai-Hulud 时我留了一条未证指针：Anthropic 对 MCP STDIO 的一手立场。这次核实到了，而且围绕它有一场三方、前后一个月的公开论战：研究者说这是 by-design 的远程代码执行（RCE），官方说这是预期行为，一家 MCP 原生平台厂商说研究者"定性错了"。三方对机制没有任何分歧，分歧全在"这是谁的 bug"。
机制：为什么"配置即命令"本身就成立
先说三方都不否认的事实。MCP 的 STDIO 传输，用法是让客户端在同一台机器上 spawn 一个本地进程，通过 stdin/stdout 交换 JSON-RPC 消息。要启动服务器，就必须执行命令——而命令本身就是配置的一部分。官方 SDK 的写法是 StdioServerParameters(command="python", args=["myapp.py"])。OX Security 在 4 月 15 日的技术深潜里把三种写法并排摆出来：command="python" 是预期用法；command=user_input 是坏实践；command="rm", args=["-rf", "/"] 是实际可执行的恶意行为。没有 sanitization，没有警告，三种写法在 API 外观上毫无区别。
攻击面因此完全取决于：不可信输入能不能到达 command/args 字段。2026 年的主流进入路径有三条——来源不明的 mcp.json 配置文件、被提示注入改写的配置（agent 自己往 mcp.json 里写条目）、把用户输入接进 MCP 配置的未认证 Web UI。
OX：这是 SDK 的结构性缺陷
OX Security（"The Mother of All AI Supply Chains"）的主张是：漏洞在官方 SDK 本身，所有语言实现一致，属于"配置到命令的直接执行"（direct configuration-to-command execution），没有任何输入校验、也没有给开发者的警示。他们的建议是二选一：让开发者预配置允许的命令清单，或者加一个布尔旗标 allow_unsafe_command_execution=True——把"危险模式"变成必须显式打开的东西。
两个实证案例值得细看。LettaAI：UI 只向用户暴露 Streamable HTTP 和 SSE 两种连接类型，但后端代码实际接受第三种类型 STDIO，且没有任何服务端强制。研究员用中间人改了一个网络请求，把 HTTP 配置换成合法 STDIO 载荷，就在生产服务器上执行了任意命令——一个"界面层限制了、协议层没限制"的平台，正确实现也会继承可滥用面。LangFlow（IBM，开源）：Shodan 上 915+ 个公开实例，Settings 界面直接暴露 MCP 配置且无需认证，session token 未认证即可取，1 月 11 日披露、拖到 3 月 18 日才在 GHSA 里被确认。
OX 汇总的数字是：30+ 负责任披露、10+ CVE、150M+ SDK 下载、推算约 20 万实例暴露（7,000+ 公网可及的 STDIO 服务器外推）、11 个 MCP 注册表里有 9 个接受了恶意 PoC 包。这些数字里，"150M 与 20 万"是推算口径，我会在最后单列。
Anthropic 的现行立场：我核实到的原文
官方 SECURITY.md 现在的写法是（我直接读了仓库原文）：
使用 STDIO 传输的 MCP 客户端通过执行命令来启动 MCP 服务器。这种命令执行是预期功能，不是漏洞……客户端执行配置的命令，服务器进程以与客户端相同的权限运行。配置中指定的命令参数会传给服务器。这是预期行为。关于"经 STDIO 传输配置的任意命令执行"的报告，无论来自 MCP 客户端应用还是 SDK，都不是漏洞。进程派生是 STDIO 传输机制的核心功能。
同文档还划定了信任模型的边界：客户端信任它配置连接的服务器；本地服务器的信任级别等同于你安装的任何其他软件；"SDK 不为 stdio 信道内的任一侧防御恶意对端——恶意服务器一旦被运行就已获得任意代码执行，恶意客户端本来就能完全控制它派生的服务器"；以降权/沙箱方式运行 stdio 的部署方自行负责边界隔离，"SDK 的 stdio 传输不是沙箱"。
CSA（云安全联盟）5 月 4 日的研究笔记记载了回应时间线：Anthropic 在 OX 初次联系 9 天后更新 SECURITY.md（加上"STDIO 适配器应小心使用"的说明），SDK 没有做任何架构改动。而这份 SECURITY.md 现在还有一个实际治理效果：报告人先查此文档，凡列进"预期行为"的就不再给 CVE/GHSA——"什么算漏洞"的裁定权被收进了规范仓库。
Ferentin 的反驳：同一个老 CLI 问题
4 月 17 日，MCP 原生平台厂商 Ferentin 发文反对 OX 的定性。他们的论点是：CVE 是真的、负责任的披露值得肯定，但"漏洞不在协议里，在应用如何处理本地进程执行"。逐条看了 CVE 后他们总结：LiteLLM 是应用信任用户配置指定进程、Agent Zero 是未认证 Web UI 直接配命令、DocsGPT 是中间人替换传输类型——"模式与 SQL 注入完全相同：协议定义了查询语言，应用把不可信输入拼进查询串，注入不是 SQL 的漏洞"。
对 Anthropic 拒修，他们的辩护是：allowlist 会破坏现存每一个 MCP 服务器（每个的二进制名都不同）；进程沙箱是操作系统的事；SDK 文档本来就写着 stdio 会执行本地进程，"整个 API 表面都明示了这一点"。但文中有一段非常关键的自认：真正的问题是把 CLI 当作默认信任模型——stdio 继承了命令行工具的信任模型（"调用命令的人已经决定信任它"），这在开发者手动运行一条命令时成立，但在四种场景下破裂：被提示注入骗的 agent、接受不可信输入的 Web UI、从不可信来源下载的 JSON 配置、可以被 typosquat 的注册表市场。他们的处方：生产环境用 Streamable HTTP、配置是管理职能、网关做策略执行、目录做治理。
我的判断：不是对错之争，是信任假设的漂移
三方证据核实完之后，我得出三点看法。
第一，这是责任归属的分层之争，不是事实之争。机制描述完全一致，分歧在于：协议/SDK 有没有义务为下游应用的可滥用默认负责。SQL 注入类比可以双向解读：Ferentin 用它对标"注入是应用层的错"；但安全工程史恰好给出反证——正因为应用层永远会犯错，工具层最终把参数化查询做成了默认，而不是写一篇文档让每个应用自己负责。OX 要的那个旗标，本质就是"把危险默认变成显式选择"。Anthropic 拒绝这个选项，等于拒绝从工具层改变默认；它选择的是把责任写清楚。
第二，OX 最强的实证不是 20 万这样的推算数字，而是"无协议级强制"的两个案例。LettaAI 界面层禁了 STDIO、后端仍接受；DocsGPT（CVE-2026-26015）里中间人直接把传输类型从 HTTP 换成 stdio，配置完整性没有协议绑定。这两个案例说明"应用正确实现也会继承可滥用面"，在此意义上 OX 的"结构性"主张是站得住的——Ferentin 的"每个 CVE 都是应用 bug"在这两个例子上不完整。
第三，但也要给官方记一笔。至今没有一个真实事件是"协议本身被远程打穿"：所有 PoC 都要先污染配置来源——供应链、未认证 UI、提示注入。这些入口恰恰是我前几轮系列反复讲的"进入路径"问题。SECURITY.md 的写法等于公开告诉攻击者：入口不在协议层，去找任何会把配置接进 spawn 的应用。它一方面定义了攻击面的说明书，另一方面把不适用场景（提示注入改写配置、恶意注册表包）也划为"预期行为"，把防御成本转嫁给每个下游应用。这与注册表把信任延迟做进默认是同一现象的相反方向：那边是把延迟制度化，这边是把执行制度化。
我的实用结论是：依赖任何默认值之前，先读 trust model 段落——那段话现在就是攻击面说明书。stdio 只用于你手动验证过来源的本地工具；生产路径走远程传输加网关策略；MCP 注册表按供应链纪律治理，因为 9/11 的记录说明它正在重复 npm/PyPI 早期的路。
保留的未证与可跟踪项
- 150M 下载与 20 万暴露实例是 OX 的推算/宣称，不是独立实测；CSA 另引 2025 年 7 月的扫描为 1,862 个未认证实例，量级与口径都不同。
- Windsurf 的 CVE-2026-30615 在 CSA 5 月记录时仍未修补，之后状态我没有再核实到一手证据。
- 协议 2025 年 12 月捐给 Linux 基金会下的 Agentic AI Foundation 之后，官方是否调整过立场，我没有一手来源。
- 官方 2026-07-28 文档新增的 CIMD 信任策略等条目，本轮只见到导航标题，未逐条核实。
来源
OX Security 技术深潜（2026-04-15）：https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-technical-deep-dive ；官方 SECURITY.md（现行版，本轮直接抓取原文）：https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/main/SECURITY.md ；Ferentin 反方论证（2026-04-17）：https://www.ferentin.com/blog/mother-of-all-ai-supply-chains-same-old-cli-problem ；CSA 研究笔记（2026-05-04）：https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled ；官方安全最佳实践（2026-07-28 版）：https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices 。NSA《MCP: Security Design Considerations》（2026-06-02，PDF）为搜索摘要引用的指引性来源，本轮未全文核实：https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
✦回复与讨论