Skip to main content
本页概述了模型上下文协议项目中安全报告的处理方式。完整政策——包括信任模型以及那些属于有意设计、不作为漏洞的行为的完整清单——位于规范仓库中的 SECURITY.md。

​
报告漏洞

通过受影响仓库上的 GitHub Security Advisories 报告安全问题。规范仓库以及 modelcontextprotocol 组织中每个官方 SDK 仓库都已启用私密漏洞报告。 不要通过公开的 issue、discussion 或 pull request 报告安全问题。

​
SDK 披露与跨 SDK 协调

当针对某个 SDK 提交报告时，该 SDK 的维护者会评估同一问题是否影响其他官方 SDK。许多 MCP 漏洞源于共享模式、传输实现，或多个 SDK 以相同方式实现的规范层行为。接收报告的维护者会与其他可能受影响的 SDK 的维护者协调，以确定哪些受影响、影响程度如何，从而使修复和公告能够一并发布，而不是在部分 SDK 已发布后仍让另一些 SDK 处于暴露状态。 如果根本原因是规范中的缺陷而非实现 bug，协调中的维护者将与规范维护者讨论此事。 CVE 通过 GitHub 的 CNA 作为 GHSA 工作流的一部分进行分配。

​
范围

当以下问题源自规范或官方 SDK 的缺陷时，被视为安全漏洞：协议层漏洞、认证或授权绕过、诸如注入或内存安全问题之类的实现 bug、沙箱逃逸、会话劫持、令牌泄露，以及跨租户访问。 完整的 SECURITY.md 记录了 MCP 信任模型以及一份属于有意设计、并非漏洞的行为清单。其中最常见的一种是 stdio 对端攻击，概述如下。

​
Stdio 传输的信任边界

在使用 stdio 传输时，客户端将服务器作为本地子进程派生，两者可能以同等的环境级权限运行。SDK 不会在 stdio 通道上保护任一对端免受恶意对端的侵害：恶意服务器凭借被运行这一事实已经拥有任意代码执行能力，而恶意客户端对其所派生的服务器已经拥有完全的进程控制权。 如果一份报告的唯一影响是某个 stdio 对端能够使另一方崩溃、挂起、耗尽其资源，或以其他方式对其造成拒绝服务，则该报告在范围之外，应作为常规 issue 提交，而非作为 GHSA。如果受影响的 SDK 代码可经由任何受支持的远程传输触达，或导致沙箱逃逸，则该报告仍在范围内。以较低权限运行 stdio 服务器的部署，有责任在该边界处强制执行隔离。SDK 的 stdio 传输并非沙箱。

​
安全兴趣组

安全兴趣组是讨论 MCP 特有威胁、评审安全相关提案，以及路由那些不适合归入单个仓库的披露问题的场所。