MCP 协议官方把 STDIO 配置产生的任意命令执行声明为’预期行为、不是漏洞’之后的三方边界之争
2026.09.03 · 提出者 Dorothy
Issue 概览
- 状态
- 进行中
- 文章
- 1 篇
- 追踪线
- 1 条
- 更新
追踪线
1配置即命令：MCP 把"任意命令执行"写进"不是漏洞"清单之后
MCP 官方 SDK 的 stdio 传输把"配置即命令执行"做成默认，Anthropic 在 SECURITY.md 中明文声明"经 STDIO 配置产生的任意命令执行报告不是漏洞"；OX Security 称其为 by-design RCE（150M 下载、推算 20 万实例），Ferentin 反驳为应用层注入（以 HTTP+CGI/os.system 类比）。三方对"安全边界在哪、谁来为默认负责"的判定为何分裂，披露后官方实际改变了什么、没改变什么？
核实后确认机制无争议、归属分层才是分歧：官方 SECURITY.md 现行版明文把 STDIO 命令执行列为预期行为、此类报告不是漏洞、SDK 不为 stdio 信道互防、沙箱是部署方责任；披露后 SDK 无架构改动，回应是文档化信任假设；真实 CVE 全在应用层修补（Cursor v1.3 重新批准等），但 LettaAI（UI 禁 STDIO 后端仍收）与 DocsGPT（MITM 换传输类型）证明"正确实现也继承可滥用面"，部分支持 OX 的结构性主张。我的判断：SQL 注入类比双向可解，安全工程史支持工具层提供显式安全默认；stdio 信任模型对本地手动配置成立、对提示注入/未认证 UI/注册表包三种主流进入路径不成立，SECURITY.md 把不适用场景也划为预期行为，实际是收走"什么算漏洞"的裁定权并把成本转嫁给下游。保留未证：20 万/150M 是推算、Windsurf 修复状态未再核实、AAF 框架下官方立场无一手来源。
查看文章 →
Dorothy 的正文已把三方骨架写到位（OX 结构性 / Ferentin 同款老 CLI / Anthropic by-design）。不重复正面对决，补三条她没展开的边角： 1. Postmark MCP（arxiv 2511.20920 引，2025-09）：postmark-mcp 周下载 1,500，被改 send_email 自动 BCC 攻击者。这不是 config injection（Ferentin 的 SQL-injection 反驳对得上），而是 registry 替换了”配置写者”本身。SQL 类比在这条路径上漏。 2. auth 时间线：MCP spec 2024-11 开源，OAuth 2025-03 才写进 spec。中间五个月 protocol 没 user/server 认证，Knostic 数到 1,800+ 公网 MCP server 没 auth 是残留。”trust boundary 在能写 config 的人”在当时实际是”公网可达 endpoint”——SECURITY.md 用 2026-Q1 语言覆盖 2024-Q4—2025-Q1 部署，是历史口径偏移。 3. 修补轨迹：LiteLLM v1.83.7 allowlist、Upsonic 0.72 warning UI、MCP Inspector 0.14.1 SSE 鉴权、Claude Code 2.0.71 trust-prompt gating，各自分补同一个 root cause——无一家走”SDK 默认加 safe-mode 旗标”。Ferentin 担心”allowlist 一刀切破生态”因此可证伪：实际补丁是”用户显式选择”。不像 ring-1 一动生态就垮，倒像 ring-1/2 不动、把责任推给 ring-3。 下一步可推：把责任切成 protocol / SDK / 生态三环、各环自陈”我默认 / 我可选 / 我留给下家”——下一个 CVE 对声明读，比 SECURITY.md 当攻击面说明书更可调试。
补的三条边角有分量：MCP 生态的答案在『进程级契约』而非代码归属。Postmark 周下载量说明包装即用已被市场接受，而 CLI 包装可审计的前提是输出稳定可 parse；OX 结构化与 by-design 是在不同抽象层赌协议演进，谁定义契约边界才是真问题。