安全策略

如何报告 Model Context Protocol 规范与 SDK 中的安全漏洞、哪些内容在范围内与范围外，以及 SDK 维护者如何协调披露。

本页概述了 Model Context Protocol 项目中安全报告的处理方式。完整策略（包括信任模型以及属于有意设计、不可作为漏洞的完整行为清单）位于规范仓库中的 SECURITY.md。

报告漏洞

请通过受影响仓库上的 GitHub Security Advisories 报告安全问题。 规范仓库以及 modelcontextprotocol 组织中的每个官方 SDK 仓库均已启用私密漏洞报告。

请勿通过公开 issue、讨论或 pull request 报告安全问题。

SDK 披露与跨 SDK 协调

当针对某个 SDK 提交报告时，该 SDK 的维护者会评估同一问题是否影响其他官方 SDK。许多 MCP 漏洞源于共享模式、传输实现或规范层面的行为，而多个 SDK 以相同方式实现了这些内容。接收报告的维护者会与其他可能受影响的 SDK 的维护者协调，确定哪些 SDK 受到影响以及影响程度，以便修复与公告能够一同发布，而不是在其他 SDK 已发布后仍让部分 SDK 处于暴露状态。

如果根本原因是规范中的缺陷而非实现缺陷，协调维护者将与规范维护者讨论此事。

CVE 通过 GitHub 的 CNA 作为 GHSA 工作流的一部分进行分配。

范围

当以下问题源于规范或官方 SDK 中的缺陷时，被视为安全漏洞：协议层面的漏洞、认证或授权绕过、注入或内存安全等实现缺陷、沙箱逃逸、会话劫持、Token 泄露以及跨租户访问。

完整的 SECURITY.md 记录了 MCP 信任模型以及一份属于有意设计、不构成漏洞的行为清单。其中最常见的一项是 stdio 对端攻击，概述如下。

Stdio 传输的信任边界

使用 stdio 传输时，客户端将服务端作为本地子进程启动，二者可能以同等的环境级权限运行。SDK 不会在 stdio 通道上防御任一端的恶意对端：恶意服务端因被运行而已拥有任意代码执行能力，恶意客户端也已对其启动的服务端拥有完整的进程控制权。

若报告的唯一影响是某个 stdio 对端可以使另一端崩溃、挂起、耗尽资源或以其他方式拒绝服务，则属于范围外，应作为普通 issue 而非 GHSA 提交。如果受影响的 SDK 代码可通过任何受支持的远程传输触达，或导致沙箱逃逸，则该报告仍在范围内。以降低的权限运行 stdio 服务端的部署方有责任在该边界上实施隔离。SDK 的 stdio 传输不是沙箱。

安全兴趣小组

Security Interest Group 是讨论 MCP 特有威胁、评审与安全相关的提案，以及转交不属于单一仓库的披露问题的场所。