ChatGPT 静默跨连接器传递数据引发安全隐患
ChatGPT silently passes data between connectors and the bounty wants an ID card
在启用两个连接器的对话中，ChatGPT 会在没有用户通知的情况下，将后续工具调用静默切换到不同的连接器，并携带前一个连接器的小组件生成的确认码。由于两个连接器拥有各自的 OAuth 客户端，服务器拒绝了该调用，但这种未授权的数据传递行为暴露出多步骤工具工作流中缺乏授权上下文保持的问题。
Sign Up Log In
More
Resources
Categories
Tags
Light mode
Security: Follow-up tool call silently routed to a different connector
You have selected 0 posts.
1 / 3
Nov 4
post by AldiPower 1 day ago
In a conversation with two connectors enabled, ChatGPT made a follow-up tool call through a different connector than the one that started the flow. The user was not told about the switch. The call carried a one-time confirmation code from the first connector’s widget.
Setup
One ChatGPT account with two connectors enabled that point to the same MCP server.
Connector A is a custom connector added in developer mode.
Connector B is the published app from the app directory.
Each connector has its own OAuth client, so the server sees two separate clients for the same user.
Steps
In a conversation with both connectors enabled, ask for an action that needs the user’s confirmation.
The model calls a confirmation tool through connector A. Its MCP Apps widget shows the change. The user confirms, and the widget sends a one-time confirmation code to the conversation via ui/message.
The model makes the follow-up call with that code, but silently through connector B instead of connector A.
Result
The server rejects the call, because the code is bound to connector A’s OAuth client. Every attempt in that conversation failed. In the attempt we logged in detail, the code was confirmed through connector A and redeemed through connector B. Nothing told the user that the follow-up call went to another connector.
Why this is a problem?
The user starts the flow with connector A and confirms in connector A’s widget. The follow-up call then goes to connector B without the user knowing, and it carries a value produced in connector A’s widget. Connectors are separate apps with separate OAuth grants, so this silent switch passes data from one app to another without the user’s consent.
Here both connectors came from the same provider, so our server-side binding stopped the call. With a third-party connector enabled in the same conversation, we expect the same silent switch to pass one app’s data to another provider if the server URL is shared.
A shared MCP URL is not enough to treat two connectors as one. Behind the same URL, a server can act for different parties depending on the OAuth client, for example separate tenants, partners or environments. The boundary is the connector with its own OAuth client, not the URL.
Expected behavior
Tool calls are matched to a connector by its OAuth client, not by the MCP server URL. A follow-up call goes through the same connector and OAuth client that started the flow.
1
67 views 1 link
Summarize
post by techsoft.ye 22 hours ago
Hi AldiPower,
Thank you for documenting this so clearly. I think you’ve identified an important distinction between tool selection and authorization continuity that deserves attention.
What makes this case particularly interesting is that the server-side protection appears to have worked: the confirmation code was bound to Connector A’s OAuth client, so the attempt to redeem it through Connector B was rejected.
However, that rejection does not eliminate the underlying concern. The follow-up call was apparently routed through a different connector without informing the user.
I believe this points to a broader architectural requirement:
A multi-step tool workflow should preserve the identity of the connector and its authorization context throughout the operation, rather than relying solely on the MCP endpoint or tool name.
A robust approach could include:
Binding pending operations and confirmations to the originating connector and its verified OAuth grant.
Preventing automatic connector switching during confirmation or execution.
Requiring explicit user approval if changing the connector becomes necessary.
Validating short-lived confirmation codes against the intended operation, client identity, and authorization context on the server.
Recording connector-routing decisions in diagnostic traces, without exposing credentials or sensitive confirmation values.
Your example also highlights an important separation of responsibilities: the MCP server must enforce authorization, but the client-side orchestration layer should preserve the connector selected for the workflow.
One question that could help narrow down the root cause:
Do your traces indicate whether the connector identity changed during confirmation handling or only when the model selected the follow-up tool call?
Since this may involve an authorization boundary, I would also encourage submitting the technical evidence through OpenAI’s coordinated vulnerability disclosure process, rather than relying solely on a public discussion.
review this for more info
Relevant documentation:
Thanks again for sharing a concrete, reproducible case. This is exactly the kind of boundary that deserves careful investigation.
post by AldiPower 15 hours ago
Reply
Related topics
Topic list, column headers with buttons are sortable.
Developer Community
Connect with other developers building with the OpenAI Platform.
Help
Developer Resources
来源：Hacker News-首页 · community.openai.com