文章总结： MCP新规范（2026年7月发布）从有状态会话转向无状态协议，引入显式状态句柄、多轮往返请求、MCPApps和Tasks扩展，并强化OAuth授权。这些变化削弱了旧式协议级会话劫持等风险，但放大了应用执行控制面风险，包括跨Agent工作流劫持、客户端可控元数据操控、头部混淆与泄露、MCPApps存储型XSS以及长时后台任务资源耗尽。安全防护需从协议层面转向状态完整性、工具信任、UI隔离、异步配额与OAuth边界等应用层能力。 综合评分： 85 文章分类： 漏洞分析,红队,渗透测试,安全建设,AI安全

MCP新规范所带来的安全漏洞

原创

林之冰寒 林之冰寒

Security for AI

2026年7月6日 14:52 韩国

在小说阅读器读本章

去阅读

前言

MCP将于2026年7月28日发布全新版本，在引入全新规范后，讲会带来一系列新的安全风险，本文将对这些安全风险做简要解析

新版MCP变了什么

新发布版本可以概括为五个关键词：无状态协议核心、扩展机制正式化、Tasks扩展、MCP Apps、授权加固与弃用策略。

协议层从会话模型转向无状态模型

旧版本通过初始化握手与Mcp-Session-Id维持会话。新版本取消initialize与initialized握手，客户端将协议版本、客户端信息与能力声明放入每个请求的_meta中，服务器能力则通过server/discover按需获取。

从变化上来看网关无需深度解析协议体即可做路由，服务端更容易横向扩展，缓存也更容易建立。但是安全风险是协议不再替应用保管状态，状态正确性、归属关系、重放防护和过期控制，必须由应用自行承担。

显式状态句柄成为新常态

原先隐藏在会话中的浏览器会话实例、数据库事务上下文、文件访问句柄、审批流程上下文等有状态业务对象，未来都应通过显式句柄返回给模型，再由模型在后续调用中带回。

由此可见，状态已经从传输元数据转移到业务数据面。这个变化对可扩展性友好，对安全模型提出了更高要求。因为一旦句柄可猜测、可替换、可跨用户复用，原本的会话边界就会变成可被拼装的业务边界。

Server-to-client交互被重构为多轮往返请求

新版将用InputRequiredResult和requestState取代长期SSE悬挂式等待。服务器在处理中途需要用户输入时，返回待补充的输入请求与一个opaque状态值；客户端收集输入后，带着原值重试请求。

如果requestState参与授权、资源访问或业务逻辑，服务器必须把它视为攻击者可控输入，并通过HMAC或AEAD等方式保护完整性，同时校验主体绑定、短期过期和请求关联。

新头部与_meta使网关可见性增强，也让输入面扩大

新模型要求通过Mcp-Method、Mcp-Name等头部向中间件暴露操作信息，从而让负载均衡、限速、缓存和审计体系更容易介入。

同时，规范草案为工具参数引入x-mcp-header扩展，允许将部分参数镜像到Mcp-Param-*头部，以便代理在不解包JSON的情况下进行路由。

此外，_meta被提升为通用元数据容器，每个请求都可能携带协议版本、客户端能力、日志级别以及扩展定义的额外信息。

从部署视角看，这些改动提升了可操作性。但从安全视角看，所有新增可见字段都意味着新增可信边界决策点。只要有人在路由、授权、租户识别或日志收集环节中错误信任这些字段，安全问题就会出现。

MCP Apps把前端安全重新带回AI控制面

MCP Apps在2026年1月转入正式扩展。其核心能力是工具返回一个交互式HTML界面，由宿主在沙箱化iframe中渲染，界面通过postMessage上的JSON-RPC与宿主通信。

其安全模型包含四层设计：沙箱iframe、预声明模板、可审计消息通道、用户同意控制。这些设计有明显帮助，但只说明宿主接入层具备基础防护，并不自动消除存储型XSS、界面钓鱼、恶意内容诱导、跨面板数据窃取或UI驱动的越权调用。

Tasks让异步执行进入协议主舞台

2025年11月版曾将Tasks作为实验性核心特性。到2026年，Tasks被迁移为扩展，并重新设计成适配无状态模型的生命周期：服务器可以在tools/call时返回任务句柄，客户端通过tasks/get、tasks/update、tasks/cancel继续驱动。

这里的安全含义不止资源消耗。异步任务带来的问题至少还有任务归属、结果完整性、取消权限、恢复权限、任务结果缓存污染、任务驱动的旁路执行与审计碎片化。

授权模型从能用，走向更接近OAuth与OIDC真实部署

MCP授权文档要求HTTP传输下采用OAuth2.1思路，MCP服务器作为受保护资源服务器，客户端作为OAuth客户端，服务器必须提供Protected Resource Metadata，并通过授权服务器元数据或OIDC发现向客户端暴露授权端点。

到新版，发布候选进一步要求客户端验证授权响应中的iss参数，以抵御mix-up类攻击。在动态客户端注册中声明application_type； 将注册凭据绑定到授权服务器的issuer以及澄清refresh token申请与scope升级行为。

已缩小的攻击面：哪些风险确实下降了

新规范削弱或移除了三类传统风险：协议级会话劫持、未请求的服务器提示、弱认证方式。这个结论整体成立，但仍需要逐项拆开。

协议级会话劫持风险下降

旧规范里，Mcp-Session-Id一旦被截获，攻击者就可能伪装为会话持有者继续与服务器交互。新模型取消这类协议级会话头后，此类风险的协议载体确实被移除。

但风险并未消失，只是从协议会话标识迁移为应用状态标识。若开发者把browser_id、transaction_id、任务句柄、审批恢复令牌做成可猜、可重放、可跨主体复用，效果与旧式会话劫持并无本质差别。

因此，更准确的说法是：旧式协议会话劫持下降，应用状态劫持上升。

未请求提示风险下降

重构后，服务器仅能在处理某个客户端请求期间发起与该请求相关的补充请求，不能再像早期模型那样在任意时间点对客户端发起打断式请求。

这对降低静默诱导、界面突然弹窗、会话外提示注入非常有帮助，这一判断与规范演进方向一致。

但这类风险同样没有被完全清零。因为工具描述、工具输出、Apps界面、任务恢复提示仍然能够承载诱导信息。协议不再允许无缘无故地打断用户，攻击者仍然可以在合法调用流程中嵌入恶意内容。

认证方式更成熟

授权体系越来越接近现代OAuth部署习惯，PKCE、HTTPS、授权服务器发现、资源服务器元数据、iss校验等要素逐渐补齐。

这一变化确实会显著降低旧式隐式授权、弱客户端注册、回调混淆与授权码被滥用的风险。但要注意两点。

其一，MCP授权在HTTP远程场景下是推荐且高度重要的，在STDIO本地场景下则不按同一规范处理，很多实现仍靠环境变量或本地嵌入凭据。

其二，认证更成熟，不等于授权边界更简单。代理型MCP服务器向第三方API转发请求时，混淆代理、token透传、scope膨胀与下游审计失真仍是高风险问题。

新攻击面：

一、跨Agent工作流劫持

第一类新增风险可以概括为跨Agent工作流劫持，核心对象是跟踪标识、任务状态对象与多轮恢复上下文。

从规范结构看，这类风险主要对应两部分：一是显式状态句柄，二是InputRequiredResult中的requestState。

其典型失败路径包括：

1. 状态值可预测，攻击者通过穷举或采样命中他人工作流。
2. 状态值未做主体绑定，A用户拿到的状态可在B用户上下文中继续消费。
3. 状态值未设置短TTL，过期任务被长时间重放。
4. 状态值未绑定原始请求摘要，攻击者将同一状态移花接木到另一类请求。
5. 状态值仅做编码，未做完整性保护，客户端可修改其中业务字段。

这一项风险往往出现在审批流、长时任务恢复、浏览器自动化、数据库事务接续与多Agent协同场景。因为这些场景天然依赖跨请求状态恢复，且状态往往与真实业务动作关联。

二、客户端可控元数据操控

_meta允许客户端向几乎任何消息附加元数据；一旦服务端把这些字段用于租户识别或授权判断，就可能发生越权与跨租户访问。

很多开发团队看到_meta后，容易把它当成半可信的控制字段。例如：

• 以tenant决定数据库连接池
• 以authenticated=true决定是否跳过下游校验
• 以role=admin切换工具可见性
• 以trace、locale、project等字段拼接到后端查询条件

_meta的定位是通用元数据容器，客户端需要在每个请求中携带若干协议字段。按这一设计，_meta更接近承载上下文的容器，不适合作为权威身份断言源。

在安全设计上，身份、租户、角色、范围、资源所有权这类字段必须来自受保护的身份层、会话层、签名状态层或服务端查表结果，不能直接从_meta继承。

三、头部混淆与头部泄露

这一部分对应两个高风险点：头部与JSON-RPC消息体不一致引发的协议混淆，以及x-mcp-header导致的敏感数据泄露。

第一类问题可以概括为多解析器不一致。网关按Mcp-Method: tools/call做放行，后端按body中另一个方法名执行。或者WAF按头部路由到某条限速规则，应用层却解释出另一份语义。这类问题在HTTP请求走过CDN、API网关、服务网格、框架中间件与应用解析器时尤其危险。

新版规范已经给出关键约束：当头部与消息体不一致时，服务端应拒绝请求。但这只是逻辑要求。企业还需要保证网关、WAF、灰度层、缓存层与应用框架对同一请求对象使用同一规范化结果，否则仍有绕过空间。

第二类问题更偏数据治理。MCP工具文档允许将某些原始类型参数通过

x-mcp-header映射到Mcp-Param-*头部，并且已经提醒开发者不要把密码、API密钥、token或PII放进去。对这一点的担忧完全成立，因为头部天然会经过更多基础设施：负载均衡日志、APM探针、调试镜像、镜像流量、边缘规则引擎和错误回显系统。

换言之，x-mcp-header本身是为运维可见性而生的能力，一旦被用于敏感参数传递，就会把原本只在应用体内出现的数据扩散到整个网络观测面。

四、MCP Apps与存储型XSS

MCP Apps让工具输出从纯文本升级为可执行的交互式HTML界面，哪怕宿主在沙箱iframe中渲染，攻击者仍有大量可用空间。

这里的设计强调三件事：模板要预声明、渲染在沙箱iframe中、UI到宿主的交互经过JSON-RPC与可审计通道。这些设计能降低直接宿主接管风险，但无法自动解决以下问题：

1. 攻击者通过某个工具持久化恶意HTML片段，后续其他用户查看时触发界面层恶意行为。
2. UI内容伪装为可信审批窗、登录补录窗或客服确认窗，引导用户提交敏感信息。
3. 界面读取当前面板内可见数据，再通过外连资源、图片请求、表单提交或被允许的消息接口回传。
4. 通过界面驱动用户点击发起合法但高危的工具调用。

五、长时后台任务带来的异步资源耗尽

Tasks带来的首要问题是单向异步DoS风险：客户端发起低成本请求，服务端创建高成本任务，随后客户端可立即断开，代价全部留在服务端。

在这个场景里面，企业环境里更实际的风险至少还有：

• 任务句柄可被枚举，导致越权查询与取消
• 任务恢复与更新接口缺少主体绑定
• 任务结果长期缓存，敏感结果被错误复用
• 一个用户通过海量轻量触发堆积重任务，造成共享资源池饥饿
• 任务内部可继续触发工具调用，形成隐蔽的二阶执行放大

tasks/list已从新模型中移除，原因是脱离会话后很难安全限定其作用域。这一点本身说明，异步对象天然是高敏状态对象，必须像订单、工单、审批单那样治理，而不能把它当成普通进度轮询接口。

应该怎样理解风险迁移

MCP新规范并未简单地让系统更安全或更危险，它改变的是风险分布位置。

旧模型的危险点，更多集中在连接、会话、长流与授权能力不成熟带来的协议脆弱性。新模型的危险点，则转移到状态对象、业务句柄、消息元数据、可执行界面、异步资源控制与跨组件组合。

这正是整轮规范变更最值得重视的地方。因为未来评估MCP，不应只问协议安不安全，而应问下面五个问题。

1. 应用层状态由谁生成，如何签名，如何绑定主体。
2. 业务决策使用了哪些客户端可控字段。
3. UI模板、工具描述和工具输出进入下游前经过了哪些净化与审计。
4. 异步对象如何做配额、隔离、取消与回收。
5. OAuth、代理层与下游API之间的信任边界是否收紧到最小。

总结

MCP正在成为远程AI工具系统的通用控制平面。

从安全角度看，这轮升级带来的最大变化，是协议不再替实现者保存太多安全假设。会话消失后，状态要自己保护、UI进入后，前端安全要自己承担。Tasks落地后，异步资源和生命周期要自己治理。授权加固后，OAuth复杂性也真正进入了MCP系统设计内部。

在防护上应停止把MCP视为一个单纯的工具接入协议，转而把它视为一个融合身份、状态、界面、执行和下游系统访问的复合控制层。对这一层的保护，决定了AI系统最终能否在企业环境中稳定、可审计、可隔离地运行。

因此MCP新规范削弱了旧式协议会话风险，放大了应用执行控制面风险。未来的成败，取决于谁能更早把状态完整性、工具信任、UI隔离、异步配额与OAuth边界做成默认安全能力。

参考

https://www.akamai.com/blog/security-research/new-mcp-specification-security-teams-must-prepare

https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

如果有需要合作或者AI安全技术交流，请+V，base64解码：XzVzZWFzb25f

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Security for AI 林之冰寒 林之冰寒《MCP新规范所带来的安全漏洞》