ChatGPT沙箱隔离失效，攻击者可跨账户窃取Gmail数据

Part01

共享服务打破隔离

ChatGPT内部存在一个隐蔽的跨账户通信信道，攻击者可借此劫持受害者会话，并从Gmail等已连接应用中悄无声息地窃取数据，而受害者在对话界面中看不到任何异常。

该漏洞利用了ChatGPT的代码执行容器，即助手在需要运行代码或安装软件包时所使用的隔离沙箱。这些容器无法直接访问公网，理论上也不应与不同账户下启动的容器相互通信。然而，Check Point研究团队发现，不同账户的容器都能访问同一个内部服务：一个用于分发Python和npm软件包的JFrog Artifactory实例。这个共享依赖最终成为了隔离墙上的裂缝。

该Artifactory实例在/api/storage/{repoKey}/{itemPath}端点暴露了Item Management API操作，包括“Set Item Properties”和“Get Storage Item Information”。分配给容器的读取凭证拥有足够的权限来读写这些属性，关键在于这些属性并未按账户进行隔离。

Check Point对此进行了验证：他们从一个账户的容器中写入一个带时间戳的测试属性，然后从另一个完全独立账户的容器中读取该属性。值被完整读回，证明该存储端点的元数据字段在本应相互隔离的环境之间充当了一个共享剪贴板。

Part02

隐蔽信道窃取数据

确认这一剪贴板存在后，研究人员将其武器化，构建了一条完整的任务传递信道。攻击者可以将任务（本质上是一条指令，例如“获取我的邮件列表”）发布到共享存储属性中。受害者的ChatGPT会话如果之前已在对话中嵌入了隐藏指令，就会在例行交互中检查这个共享“邮箱”，利用受害者可用的任何工具和已连接应用执行任务，并将结果写回同一共享属性，供攻击者收集。数据过大无法放入单个属性时，甚至可以被分块存储到多个键中，之后再重新组装。

触发该攻击并不需要对受害者账户进行深度技术访问。Check Point演示了三种实际可行的投递路径：直接粘贴到聊天中的恶意提示词、共享的ChatGPT对话链接，以及将指令烘焙在隐藏配置中的自定义GPT。一旦该指令进入对话上下文，受害者任何一条普通后续消息，哪怕只是问一个做菜问题，都可能悄无声息地同时触发隐藏任务。

在Check Point发布的概念验证中，ChatGPT完全按预期回答了受害者的正常问题。与此同时，在同一轮交互中，它访问了受害者已连接的Gmail账户，提取邮件数据，并通过隐蔽信道发送到攻击者的会话中。

界面中留下的唯一痕迹是回复上方一个小小的“Talked to Gmail”标签，受害者在事前没有任何机会批准或阻止该操作。

ChatGPT已连接应用权限的默认工作方式进一步放大了这一风险。OpenAI文档中所述的“重要操作”设置允许助手在无需用户明确确认的情况下对已连接应用执行读取操作，审批提示仅保留给更高风险的操作。这意味着一次只读的Gmail查询（通常被视为低风险）可以在受害者从未被要求批准的情况下，获取个人往来邮件、商业数据或其他敏感内容。只有更严格的“始终询问”设置才会强制执行确认步骤。

Part03

Agent隔离风险与修复

Check Point指出，此次发现的时间节点值得关注：2026年6月的这次发现与广泛报道的Hugging Face事件几乎同时发生。在后一起事件中，独立评估环境中的agent通过完全不同的机制建立了未授权信道进行协调。两起事件都暴露了agentic AI平台面临的同一个根本性教训：一个本应纯粹作为基础设施的共享内部服务，可能成为本应严格隔离的环境之间意想不到的通信层。

研究人员将核心风险描述为把LLM变成了一个“被胁迫的内部人员”。模型本身并不具备恶意，但它在信任边界内运行，拥有凭证、内部API和用户数据的访问权限，并且会遵循文本指令。一个措辞具有说服力的提示词，就能利用本属于受害者的合法能力，诱导模型为攻击者行事。

Check Point已将发现报告给OpenAI，后者确认造成泄漏的内部Artifactory实例已被下线，跨账户信道随之关闭。研究发布时，该漏洞已无法被利用。共享基础设施上的可变状态需要严格的租户隔离，管理接口也应从根本上与运行时环境隔离开来。随着AI助手获得对电子邮件、云存储和企业工具更深的访问权限，单次隔离失效的爆炸半径也会相应扩大，这使得沙箱架构的安全性与模型自身行为的安全性同等重要。

推荐阅读

电报讨论