文章总结： 文档分析CVE-2025-6514漏洞，指出mcp-remote因信任OAuth动态发现机制导致RCE。核心在于OAuth假设不适用于自治AIAgent。建议转向基于Capability的委托模型，通过密码学验证替代动态发现，从根本上消除攻击面，更适合分布式异步架构。 综合评分： 90 文章分类： 漏洞分析,AI安全,解决方案

当 OAuth 成为武器：CVE-2025-6514 的教训

Amla Labs

securitainment

2025年12月23日 10:24 中国香港

mcp-remote 中的一个严重漏洞影响了 558,846 次下载。缺陷出在客户端，但攻击利用了 OAuth 的动态发现机制——这是一种对自治 Agent 并不成立的信任假设。

2025 年末，安全研究人员披露了 CVE-2025-6514：mcp-remote中的一个严重漏洞，影响 558,846 次下载 (HackerNoon)。当连接不受信任的 MCP 服务器时，该漏洞可能导致任意 OS 命令执行 (JFrog advisory)。mcp-remote被 Claude Desktop、Cursor、Windsurf 等 LLM 宿主使用 (JFrog blog)。

该攻击向量利用了 OAuth 引入的一种模式：动态发现授权端点 (JFrog blog)。

漏洞本身出在客户端——mcp-remote在打开 URL 前未对其做充分的过滤与校验 (JFrog advisory)。但让攻击得以发生的架构性假设来自 OAuth：客户端应该向服务器询问“去哪里认证”。这一假设适用于身份提供方已知且可信的场景；当自治 Agent 需要连接任意 MCP 服务器时，就会变得危险。

发生了什么

Model Context Protocol (MCP) 已成为连接 AI Agent 与外部工具和服务的标准。当 MCP 客户端连接远程服务器时，需要完成认证。在 mcp-remote中，这个流程会向服务器请求 OAuth 元数据(包括 authorization_endpoint)，然后打开服务器返回的 URL，让用户完成认证 (JFrog blog)。流程大致如下：

1. 客户端询问 MCP 服务器：“我应该在哪里进行认证？”
2. 服务器返回 OAuth 元数据，其中包含 authorization_endpoint
3. 客户端打开浏览器访问该端点
4. 用户登录，客户端获取 token

漏洞利用发生在第 2 步：恶意 MCP 服务器可以返回一个精心构造的 authorization_endpointURL。该 URL 不会打开登录页面，而会在 mcp-remote尝试打开时触发 OS 命令执行 (JFrog blog；JFrog advisory)。

更深层的问题

该 CVE 已被修复 (fix commit)。但促成漏洞的那条架构性假设，仍嵌在我们构建 Agent 授权体系的方式里：Agent 必须信任外部服务来告诉它“该如何认证”。

这正是 OAuth 的基本模型。它默认：

• 存在一个可信的 identity provider
• 客户端可以发现并验证该 provider
• token 交换发生在安全且已认证的信道上
• 人类用户会对认证流程做最终确认

这些假设都不适用于大规模运行的自治 Agent。

当 Agent A 需要将权限委托给 Agent B，让 B 去调用第三方 API 时，谁来充当 identity provider？当委托以异步方式发生——可能是几小时后，也可能通过消息队列——OAuth 流程如何完成？当一个 Agent 编排器同时拉起数百个子 Agent，每个都需要对不同资源进行范围受限的访问，又要跑多少次 OAuth 流程？

行业常见的做法是：把凭据存起来，传来传去，然后寄望一切顺利。

CVE-2025-6514 展示了当这一切不顺利时会发生什么。

信任倒置

OAuth 诞生于这样一个世界：

• 人类向服务进行认证
• 服务数量有限且较为知名
• 会话是同步且短生命周期的
• 用户在场，可以对信任决策做确认

AI Agent 把这些前提几乎全部倒置了：

• Agent 代表人类(或其他 Agent)进行认证
• 服务数量庞大、动态变化，且可能不可信
• 操作往往异步且长时间运行
• 没有人类在场去点击 “Allow”

这个 MCP 漏洞正发生在信任倒置的交汇点：协议问的是“服务器，请告诉我去哪里认证”。服务器回的却是攻击 payload。客户端遵循 OAuth 的发现模型照做了。

这意味着一个并不令人愉快的事实：在 Agent 系统里，每一次 OAuth 集成都可能成为潜在攻击面。原因不在于 OAuth 本身 “坏了”，而在于它的信任假设与 Agent 的运行现实不匹配。

另一种模型：基于 Capability 的委托 (Capability-Based Delegation)

如果 Agent 根本不需要向外部服务询问“该如何认证”呢？如果授权不是从可信第三方那里“获取 token”，而是出示一种可被密码学验证的 capability，并且这种 capability 自带有效性证明呢？

这就是 capability-based 安全模型。它正是为分布式、异步、多方参与的系统而设计的——而 AI Agent 架构恰好就是这样。

在 capability 系统中：

凭据留在边界。网关服务持有真实的 API key、OAuth token 等 secret；Agent 永远不会直接接触它们。

Agent 持有 capability，而不是凭据。当用户授权某个 Agent “读取我的日历”时，Agent 获得一个 capability token：它只授予这一项权限——由密码学签名、具备时间边界、且不可伪造。

委托是结构性的，而不是隐含的。当 Agent A 需要 Agent B 执行子任务时，A 会签发一个经 attenuated的 capability——在数学意义上保证其权限不可能超过 A 自己持有的权限。无需 OAuth 流程，也不需要信任 B 来告诉 A “该去哪里认证”。

验证不依赖动态发现。capability token 会在验证方已知的 trust plane 上进行验签；不存在“去问服务器哪里认证”的步骤，也就没有可被投毒的元数据端点。让 CVE-2025-6514 成立的攻击面，在这里根本不存在。

| OAuth 发现的假设 | CVE-2025-6514 的利用点 | 基于 Capability 的回答 | | — | — | — | | “信任服务器告诉我去哪里做 auth” | 恶意服务器可以污染流程 | 不做动态发现——capability token 自带证明 | | “Bearer token 可以证明 authorization” | token 获取流程本身被攻击 | Proof of Continuity 绑定的是执行上下文，而不是交换过程 | | “IdP endpoint 可以安全打开” | endpoint URL 成为注入向量 | 网关持有凭据，Agent 仅持有 capability | | “Discovery metadata 值得信任” | 元数据投毒导致 RCE | 不走基于元数据的认证流程——只依赖密码学链路 |

因此，CVE-2025-6514 这类攻击在这里会变得不可能——不是因为我们补上了输入校验，而是因为攻击面本就不存在：没有 OAuth 流程可供劫持。

这对 Agent 构建者意味着什么

如果你今天在构建 AI Agent，可能正在使用以下三种模式之一：

1. 环境变量 / 硬编码 key

Agent 直接持有真实凭据。实现很快，但难以做最小权限控制，轮换成本高，而且距离一次 prompt injection 导致凭据外泄只差一步。

2. Secret manager (Vault, AWS Secrets Manager)

存储更安全，但问题本质不变：Agent 仍然要取回并持有凭据。你固然加固了 Vault，却把钥匙交给了一个会处理不受信任输入的实体。

3. OAuth / OIDC 流程

看似“正统”的方案——也是促成这次 RCE 漏洞的模式。它适用于需要人类交互的流程，却在异步边界处失效，并制造出 CVE-2025-6514 所利用的信任倒置。

这些都不是为“自治 Agent 跨越信任边界、再把权限委托给其他自治 Agent”而设计的。

Capability-based delegation 才是。它并不新——相关理论可以追溯到 1970 年代，并在 seL4、KeyKOS 等系统中经受过检验。真正新的，是把它用于解决 AI Agent 授权这一特定问题。

前进方向

MCP 社区正在积极改进授权机制。2025 年 6 月规范更新 讨论了 OAuth resource server 等授权指引，而 2025 年 11 月修订 增加了 client registration 的改进。与此同时，RFC 9728 为 OAuth 生态引入了 protected resource metadata (RFC 9728)。这些都是朝正确方向迈出的步子。

但它们仍建立在 OAuth 的发现模型之上：仍假设 Agent 可以安全地发现、连接并信任外部授权基础设施——只是元数据校验更强了，核心信任假设并未改变。

下一次漏洞未必长得像 CVE-2025-6514，但很可能会利用同一条结构性假设：为人类点击浏览器授权流程而设计的“基于身份的授权”，能够在机器速度、跨组织边界的自治 Agent 世界里提供安全保障。

Capability-based delegation 提供了另一种基础：

• 信任来自密码学，而不是“发现”
• 委托是可衰减的，而不是全有全无
• 验证是本地完成的，而不是依赖外部服务
• 攻击面会收缩，而不是膨胀

When OAuth Becomes a Weapon Lessons from CVE-2025-6514

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

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

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

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

本文转载自：securitainment Amla Labs《当 OAuth 成为武器：CVE-2025-6514 的教训》