开发者复现 ChatGPT 静默跨连接器传递数据，并称漏洞赏金要求提交身份证件

2026年11月5日，上午9:30 1

在启用了两个连接器的对话中，ChatGPT 通过一个与发起流程的连接器不同的连接器发起了后续工具调用。用户并未被告知这一切换。该调用携带了来自第一个连接器小组件的一次性确认码。

设置

- 一个 ChatGPT 账户，启用了两个指向同一 MCP 服务器的连接器。

- 连接器 A 是在开发者模式下添加的自定义连接器。

- 连接器 B 是来自应用目录的已发布应用。

- 每个连接器都有自己的 OAuth 客户端，因此服务器会为同一用户看到两个独立的客户端。

步骤

1. 在同时启用两个连接器的对话中，请求一个需要用户确认的操作。

2. 模型通过连接器 A 调用确认工具。其 MCP Apps 小组件显示该变更。用户确认后，小组件通过 ui/message 向对话发送一次性确认码。

3. 模型携带该确认码发起后续调用，但静默地通过连接器 B 而非连接器 A 进行。

结果

服务器拒绝了该调用，因为确认码绑定到连接器 A 的 OAuth 客户端。该对话中的每次尝试都失败了。在我们详细记录的尝试中，确认码通过连接器 A 确认，却通过连接器 B 兑换。没有任何信息告知用户后续调用发往了另一个连接器。

为什么这是个问题？

用户以连接器 A 发起流程，并在连接器 A 的小组件中确认。后续调用随后在用户不知情的情况下发往连接器 B，并携带了在连接器 A 的小组件中生成的值。连接器是拥有独立 OAuth 授权的独立应用，因此这种静默切换在未经用户同意的情况下将数据从一个应用传递到另一个应用。

此处两个连接器来自同一提供商，因此我们服务器端的绑定阻止了该调用。如果在同一对话中启用了第三方连接器，我们预计在共享服务器 URL 的情况下，同样的静默切换会将一个应用的数据传递给另一个提供商。
仅凭共享的 MCP URL 不足以将两个连接器视为一个。在同一 URL 背后，服务器可以根据 OAuth 客户端为不同方行事，例如不同的租户、合作伙伴或环境。边界是拥有自己 OAuth 客户端的连接器，而不是 URL。

预期行为

工具调用通过其 OAuth 客户端与连接器匹配，而不是通过 MCP 服务器 URL。后续调用通过发起流程的同一连接器和 OAuth 客户端进行。

嗨 AldiPower，

感谢你如此清晰地记录这一点。我认为你指出了工具选择与授权连续性之间的一个重要区别，值得关注。

这个案例特别有趣的地方在于，服务器端的保护似乎起了作用：确认码绑定到连接器 A 的 OAuth 客户端，因此通过连接器 B 兑换它的尝试被拒绝了。

然而，这种拒绝并没有消除潜在的担忧。后续调用显然是在未告知用户的情况下通过不同的连接器路由的。

我认为这指向了一个更广泛的架构要求：

多步骤工具工作流应在整个操作过程中保留连接器的身份及其授权上下文，而不是仅依赖 MCP 端点或工具名称。

一种稳健的方法可以包括：

将待处理的操作和确认绑定到发起操作的连接器及其已验证的 OAuth 授权。
在确认或执行期间防止自动切换连接器。
如果必须更改连接器，则要求用户明确批准。
在服务器端根据预期操作、客户端身份和授权上下文验证短期确认码。
在诊断跟踪中记录连接器路由决策，但不暴露凭据或敏感确认值。

你的示例还突出了一个重要的职责分离：MCP 服务器必须强制执行授权，但客户端编排层应保留为工作流选择的连接器。

一个有助于缩小根本原因范围的问题：

你的跟踪记录是否表明连接器身份在确认处理期间发生了变化，还是仅在模型选择后续工具调用时发生了变化？

由于这可能涉及授权边界，我还建议通过 OpenAI 的协调漏洞披露流程提交技术证据，而不是仅依赖公开讨论。
查看此内容以获取更多信息
相关文档：

再次感谢分享一个具体、可复现的案例。这正是值得仔细调查的那类边界问题。

你好，

我尝试通过他们的漏洞赏金计划披露此问题。

但他们要求我在提交报告之前提供个人数据，例如生物识别信息和身份证件，甚至要提供给与我无关的另一方。这是我不愿意做的。