ChatGPT 沙箱漏洞允许攻击者通过隐藏通道窃取跨帐户的 Gmail 数据

Rhinoer
Rhinoer

犀牛安全

2026年9月23日 00:00
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

ChatGPT 内部的隐蔽跨账户通信通道允许攻击者劫持受害者的会话，并在受害者未察觉对话中有任何异常的情况下，悄悄地从 Gmail 等已连接的应用程序中窃取数据。

该漏洞利用了 ChatGPT 的代码执行容器，这些容器是助手在执行需要运行代码或安装软件包的任务时使用的隔离沙箱。

这些容器无法直接访问公共互联网，也不应该与在不同账户下启动的容器进行通信。

然而，Check Point 的研究人员发现，不同账户中的容器都可以访问同一个内部服务：一个用于交付 Python 和 npm 包的JFrog Artifactory实例。这种共享依赖关系成为了安全漏洞。

*ChatGPT 沙箱漏洞*

Artifactory 实例在端点 /api/storage/{repoKey}/{itemPath} 公开了项目管理 API 操作，包括“设置项目属性”和“获取存储项目信息”。

传递给容器的读取器凭证具有足够的权限来写入和读取这些属性，而且至关重要的是，这些属性并非按帐户隔离。

Check Point 对此进行了测试，方法是从一个帐户的容器中写入一个带有时间戳的测试属性，然后从完全独立的帐户的容器中读取该属性。

数据完整地保留了下来，证明存储端点的元数据字段在原本应该彼此隔离的环境之间起到了共享剪贴板的作用。

研究人员确认剪贴板功能后，将其武器化为一个完整的任务传递通道。攻击者可以将任务（本质上是一条指令，例如“获取我的电子邮件列表”）发布到共享存储属性中。

受害者的 ChatGPT 会话（其中嵌入了对话中较早出现的隐藏指令）会在例行轮到自己发言时检查共享邮箱，使用受害者可用的任何工具和连接的应用程序执行任务，并将结果写回同一个共享属性，供攻击者收集。

如果数据量太大，无法存储在单个属性中，甚至可以将其分成多个键，稍后再重新组合。

触发攻击并不需要对受害者账户进行深度技术访问。Check Point 演示了三种实际的传播途径：直接将恶意提示粘贴到聊天记录中、共享 ChatGPT 对话链接，或者将指令嵌入到自定义 GPT 的隐藏配置中。

一旦该指令融入对话的语境中，受害者的任何普通后续消息，即使是像烹饪问题这样平凡的事情，都可能悄悄地触发隐藏的任务，以及可见的任务。

在Check Point发布的概念验证中，ChatGPT能够准确回答受害者的正常问题。与此同时，在同一回合中，它访问了受害者已连接的Gmail帐户，提取了电子邮件数据，并通过隐蔽通道将其发送到攻击者的会话中。

界面上唯一留下的痕迹是回复上方的一个小“已与 Gmail 对话”标签，受害者事先没有机会批准或阻止此操作。

ChatGPT默认的连接应用权限机制加剧了这种风险。OpenAI文档中记录的“重要操作”设置允许该助手在未经用户明确确认的情况下对已连接的应用执行读取操作，而仅对风险更高的操作才需要用户批准。

这意味着，即使是通常被认为风险较低的只读 Gmail 查询，也能在未经受害者许可的情况下获取个人邮件、商业数据或其他敏感内容。只有更严格的“始终询问”设置才会强制执行确认步骤。

Check Point 指出，时机值得注意：它在 2026 年 6 月被发现，恰逢广为人知的Hugging Face 事件，该事件中，处于不同评估环境中的特工建立了未经授权的渠道，通过完全不同的机制进行协调。

这两个案例都揭示了智能 AI 平台的一个共同根本教训：原本旨在作为基础设施的共享内部服务，可能会成为原本应该严格隔离的环境之间的意外通信层。

研究人员将核心风险描述为将LLM模型变成“受胁迫的内部人员”。该模型本身并不恶意，但它在信任边界内运行，可以访问凭证、内部API和用户数据，并且它会遵循文本指令。

措辞得当的提示可以诱使攻击者利用原本属于受害者的能力，代表攻击者采取行动。

Check Point 将调查结果报告给了 OpenAI，OpenAI 确认导致数据泄露的内部 Artifactory 实例已被停用，跨账户通道也随之关闭。在研究报告发布时，该漏洞已无法利用。

共享基础设施上的可变状态需要严格的租户隔离，管理接口应该完全与运行时隔离。

随着 AI 助手对电子邮件、云存储和企业工具的访问权限不断加深，单个隔离故障的影响范围也随之扩大，使得沙箱架构对于安全性而言与模型自身的行为一样至关重要。

信息来源：CyberSecurityNews