MCP工具需要操作级授权

2026年5月17日，NVD发布了针对AI Engine 3.4.9的CVE-2026-8719。AI Engine是一款WordPress插件，用于向WordPress站点暴露AI和MCP功能。¹³

这种失效模式应当让每一位MCP构建者警醒。Wordfence指出，MCP OAuth Bearer令牌授权路径缺少WordPress权限检查：任何有效的OAuth令牌都可以访问管理员级MCP工具，而无需验证管理员权限。² Wordfence将该问题评为8.8 High，并将3.5.0标记为修复版本。²该插件的更新日志称，3.5.0通过要求管理员权限，修复了MCP OAuth授权和令牌验证问题。³

当服务器把持有Bearer令牌等同于可以使用所有工具时，MCP授权就会失效。OAuth可以证明令牌来自授权流程。MCP服务器仍然必须判断：该主体是否可以运行这个工具、访问这个资源，并承担相应的影响范围。

简要结论

MCP的HTTP授权规范为构建者提供了必要基础：受保护资源元数据、OAuth 2.1流程、Bearer令牌处理、令牌验证、受众检查，以及在范围或权限不足时明确返回403 Forbidden。⁴MCP安全教程将授权定位为保护层，用于保护MCP服务器暴露的敏感资源和操作。⁵但这些机制并不会取代应用层授权判断。服务器仍然必须把令牌映射到用户、角色、租户、工具、资源、操作和策略。

CVE-2026-8719把这一区别变成了具体故障。AI Engine在5月12日发布的3.4.9版本中，为其MCP服务器加入OAuth 2.1和Dynamic Client Registration；随后在5月16日发布的3.5.0版本中，通过要求管理员权限，修复了MCP OAuth授权和令牌验证。³这个教训不止适用于WordPress：凡是能够修改数据、发布内容、更改设置、读取私密记录、花钱或调用特权API的MCP服务器，都需要在模型之下、客户端之下落实操作级授权。

工具分发会放大风险。2026年5月的一篇工具克隆论文测量了8,861个MCP和Skills仓库，共100,011个工具条目，并发现高相似度区间中的人工确认克隆率很高。⁶复用模板可以传播良好模式，也可能传播缺失的检查。

关键要点

面向MCP服务器构建者： - 先验证令牌，再授权具体操作。二者应作为相互独立的关口。 - 对无效或缺失的令牌返回401；对有效但缺少范围或权限的令牌返回403。 - 用低权限令牌测试每一个管理、写入、发布、删除、导出和配置工具。

面向安全团队： - 像审查应用端点一样审查MCP服务器，而不是把它们当作聊天插件。 - 追问每次工具调用映射到哪个用户、角色、租户、资源和操作。 - 要求日志记录令牌主体、工具名称、资源、授权结论和拒绝原因。

面向代理平台团队： - 市场中的工具数量并不能证明实现彼此独立。 - 相似度和来源检查很重要，因为克隆工具可能复制存在漏洞的授权逻辑。 - 应将服务器模板视为安全敏感基础设施。

面向运营者： - 如果正在运行受影响的WordPress插件，请将AI Engine升级到3.5.0或更高版本。²³ - 在确认哪些WordPress角色可以访问哪些工具之前，先禁用MCP暴露。 - 每个新的MCP连接都应从只读模式开始。只有在测试证明拒绝路径有效之后，才逐步扩大权限。

AI Engine的问题出在哪里

AI Engine将MCP宣传为一种连接方式：通过URL、登录流程和批准步骤，把Claude Code、Claude、ChatGPT、OpenClaw及其他客户端连接到WordPress站点。³3.4.9版本为MCP服务器加入了带Dynamic Client Registration的OAuth 2.1，使浏览器驱动的客户端无需共享Bearer令牌即可连接。³

这个产品方向是合理的。共享静态令牌不适合面向用户的MCP集成。相比复制粘贴密钥，OAuth流程能更清晰地绑定客户端、用户和服务器。

漏洞位于更低一层。根据NVD和Wordfence的描述，存在漏洞的路径会接受任何有效OAuth令牌来访问MCP，在授予管理员级MCP工具访问权之前，并没有验证管理员权限。¹²这一区别至关重要：

WordPress插件页面上的补丁说明使用了正确表述：MCP OAuth授权和令牌验证现在要求管理员权限，以防止非管理员用户权限提升。³这句话点出了缺失的一层。令牌不能替代权限检查。

OAuth必要但不充分

MCP授权规范覆盖了基于HTTP传输的传输层流程。规范称，MCP客户端代表资源所有者向受限MCP服务器发起请求，并以OAuth 2.1、受保护资源元数据、授权服务器元数据、Dynamic Client Registration和Bearer令牌使用为基础。⁴

这些机制解决了真实问题：

MCP规范还警告了混淆代理和令牌透传风险。MCP服务器必须验证提交的令牌确实面向该MCP服务器，也不得把从MCP客户端收到的令牌透传给上游API。⁴这项指导保护的是服务之间的边界。

操作级授权保护的是MCP服务器内部的边界。

一个MCP服务器可能暴露10个工具，也可能暴露100个。有些工具读取公开元数据，有些读取私密记录。有些起草变更，有些修改生产状态。有些管理用户、插件、付款、任务、消息或基础设施。服务器接受了会话，并不意味着有效令牌应当自动访问每一个工具。

正确的链路应当如下：

1. 验证令牌签发方、签名、有效期、受众和传输规则。
2. 将令牌解析为本地主体：用户、服务账号、组织、租户或自动化任务。
3. 加载该主体的角色、范围、授权、预算和策略。
4. 按操作类型和风险对请求的MCP工具分类。
5. 检查目标资源，而不只是工具名称。
6. 当令牌有效但操作越权时，返回403。
7. 记录决策，并包含足够细节以供审查。

OAuth把请求送到决策点。授权决定该操作是否应当发生。

工具调用需要权限矩阵

代理工具让旧有端点习惯变得更加危险。普通Web路由通常有狭窄的UI路径包裹。面向模型的工具位于规划器内部。代理可以重试、串联调用、检查工具说明、把读取结果和写入操作组合起来，还可能把不可信内容中的指令带入后续步骤。

这种行为改变了最低权限模型。服务器不应只问“此用户能否访问MCP？”服务器应当问：“此用户现在能否通过这个工具，对这个资源执行这个操作？”

使用矩阵：

这个矩阵契合代理密钥需要风险预算中的模式。凭据不应像通用Bearer字符串一样行事。它们应当像受约束的权限对象，具备服务器端限制、活动日志、撤销能力和保守默认值。

它也契合AI代理所有权是信任原语中的所有权框架。每一次特权工具调用，都应映射到一个负责账号、会话、权限包、审核路径和停止路径。

克隆工具可能复制同一个缺失检查

即使每个MCP服务器都来自谨慎的独立实现，AI Engine漏洞也依然重要。现实中的工具生态并没有这么干净。

Kim、Jiang、Hu、Jia和Gong在2026年5月10日发表了一篇论文，测量代理式AI生态中的工具克隆。他们的数据集覆盖7,508个MCP仓库，提取出87,564个工具；还覆盖1,353个Skills仓库，包含12,447个工具。合计为8,861个仓库和100,011个工具条目。⁶作者使用了令牌级Jaccard相似度和ssdeep模糊结构相似度，并对不同相似度区间中的抽样配对进行了人工验证。⁶

论文摘要报告称，在MCP生态中，高Jaccard候选项有60%被人工确认为克隆，高ssdeep候选项有85%被人工确认为克隆。⁶论文认为，隐藏重复会污染基准测试切分，传播存在漏洞的实现，扭曲对工具使用泛化能力的测量，并引发来源、归属和许可方面的问题。⁶

这一发现会改变团队解读MCP市场增长的方式。工具更多，并不自动意味着独立安全审查更多。重复的服务器脚手架可以为生态带来一致性。同样的重复也可能把同一种薄弱授权模式复制到许多包中。

因此，安全审查应当包括来源：

代理Skills需要包管理器曾主张围绕Skills建立类似包管理的分发、来源和策略机制。MCP服务器需要同样的纪律，并且还要加上执行环境中的授权测试。

MCP授权的最低测试套件

每个触及私密或可变数据的MCP服务器，都应随附授权测试套件。只确认成功路径的单元测试并不够。危险行为常藏在拒绝路径中。

从这些用例开始：

具体状态码可以遵循产品策略，但区别应当保留：无效凭据在主体解析前失败；有效凭据若权限不足，则在授权关口失败。MCP规范将缺失或无效授权对应为401，将无效范围或权限不足对应为403。⁴

对WordPress来说，同一规则更清楚：执行管理员操作的MCP工具，应检查与仪表盘、REST API或内部PHP路径相同的WordPress权限。较低权限角色不应因为调用来自面向模型的协议，就获得一条通往管理员行为的新路径。

市场审查应要求什么

MCP市场和插件目录应把授权元数据视为一等包数据。用户决定是否启用某个服务器时，需要的不只是工具数量。

最低公开元数据如下：

这些字段不会消除有漏洞的工具。但它们会让审查面变得真实。运营者可以对照声明权限和实际代码，市场也可以在缺陷出现时把相似实现归为一组。

这正是MCP授权规范和工具克隆论文之间缺失的桥梁。规范告诉实现者如何完成协议级流程。生态还需要包级来源和操作级授权证据，避免重复实现一再重复同样缺失的检查。

应该改成怎样构建

把MCP授权构建为一条流水线：

1. 协议关口：验证受保护资源元数据、OAuth流程、令牌位置、令牌有效性、有效期、签发方和受众。
2. 主体关口：将令牌映射到用户、服务账号、角色、租户和工作区。
3. 工具关口：按读取、起草、写入、删除、发布、导出、管理、执行或花费，对每个工具分类。
4. 资源关口：授权精确的目标对象或租户边界。
5. 预算关口：在执行前应用频率、大小、支出、受众和时间限制。
6. 批准关口：对高风险操作要求人工批准或策略批准。
7. 审计关口：在运营者可检查的位置记录允许、拒绝和需要审核的结论。

这些关口应位于模型之外。工具说明可以告诉代理避免管理员操作。提示词可以要求谨慎。但边界不应由它们承担。即使代理以礼貌、自信或反复的方式提出请求，服务器也应拒绝未授权操作。

您的代理沙箱只是一种建议从另一个角度说明了同一点：有效权限仍然可以组合成不安全行为。MCP工具需要在操作边界上授权，因为代理组合操作的速度，会超过人类在脑中模拟后果的速度。

FAQ

MCP是否要求OAuth？

不要求。MCP授权是可选的；HTTP授权规范适用于实现通过HTTP传输支持授权的情况。同一规范还说明，STDIO传输应从环境中获取凭据，而不是遵循HTTP OAuth流程。⁴

OAuth能解决MCP授权吗？

OAuth只解决问题的一部分。OAuth可以建立授权流程、签发令牌，并让受保护的MCP服务器验证Bearer令牌。MCP服务器仍然必须判断令牌主体是否可以对目标资源执行具体工具操作。

CVE-2026-8719证明了什么？

CVE-2026-8719证明，有效令牌路径仍然可能缺少本地权限执行。NVD和Wordfence描述的AI Engine 3.4.9，会接受任何有效OAuth令牌来访问MCP，在管理员级MCP工具变得可访问之前，并没有验证管理员权限。¹²

MCP构建者应该先测试什么？

先测试拒绝路径：低权限令牌访问管理员工具、只读令牌访问写入工具、有效令牌访问其他租户资源、过期令牌、受众错误令牌，以及无批准状态下的破坏性工具。OAuth成功路径通过，并不能证明操作级授权正确。

为什么工具克隆会影响MCP安全？

工具克隆很重要，因为重复实现可能重复同样有漏洞的中间件、认证捷径和缺失检查。2026年5月的工具克隆论文发现，高相似度MCP候选项中存在很高的人工确认克隆率，并警告隐藏重复可能传播存在漏洞的实现。⁶

参考资料