ChatGPT 漏洞：植入的提示可将受害者的 Gmail 数据发送到另一个账户

Check Point Research 在今天发布的一份报告中表示，植入 ChatGPT 对话中的一条指令即可让 ChatGPT 在照常回答用户问题的同时，悄然为攻击者工作。

在该公司的概念验证中，这项隐藏工作读取了用户已连接 Gmail 账户中的数据，并通过两者之间的隐藏通道将其传递给第二个 ChatGPT 账户。用户看到的回复对此只字未提。

Check Point 表示，同一通道还可以复制出该对话中的聊天记录和文件。

攻击者能获取多少内容取决于该会话已经能够访问的范围，包括其数据、工具、其他已连接应用和权限。

该指令必须先存在于对话中才能让这一切生效。Check Point 指出了将其植入的三种方式：用户粘贴的提示、用户打开的共享 ChatGPT 对话，或在其构建器指令中持有该指令的自定义 GPT（这些指令不会显示给用户）。

之后，一条普通消息就足以触发它。Check Point 编写的指令使 ChatGPT 在思考模式下于同一轮中运行两条工作流。

ChatGPT 回答了用户。与此同时，它检查一个隐藏邮箱以获取攻击者的任务，使用用户会话中的工具执行该任务，并将结果发送回去。该指令要求模型将两条工作流分开，因此隐藏任务从未出现在可见的回答中。

应用被使用的唯一迹象是答案上方一个小的 "Talked to Gmail" 标签。它记录了一次已经发生的读取，且未给用户允许或拒绝的机会。

由于已连接应用默认的工作方式，没有任何环节事先询问用户。OpenAI 的文档将 Important actions 列为默认权限，允许 ChatGPT 在无提示的情况下读取应用。ChatGPT 仅在可能对 ChatGPT 之外产生实际影响、暴露敏感信息或难以撤销的操作之前才会询问。

希望每次都收到询问的用户可以切换到 Always ask。在 Business、Enterprise 和 Edu 工作区中，管理员可选择每个应用可执行的操作以及谁可以使用它。应用在 Business 计划中默认开启，在 Enterprise 和 Edu 计划中默认关闭。

Check Point 表示已将该发现披露给 OpenAI，且 OpenAI 已确认该通道背后的内部服务已被下线。目前没有可供用户安装的更新。

该通道运行在 ChatGPT 运行代码的容器之间。当任务需要时，ChatGPT 会为每个对话构建一个容器。

OpenAI 的文档称，ChatGPT 用于数据分析的 Python 环境无法向 Web 或外部 API 发出请求。Check Point 表示，为不同对话（包括不同账户下的对话）构建的容器之间也没有直接路径。

但它们都能访问一个内部服务。ChatGPT 有时需要安装额外的 Python 或 npm 包。为了不让容器访问公共软件包仓库，每个容器都被允许与一个为其获取软件包的内部 JFrog Artifactory 实例通信。

该实例允许容器将命名值（称为属性）附加到存储的文件上并读回它们。容器持有的读取访问凭据也足以写入这些属性。它们位于环境变量中，ChatGPT 运行的代码可以获取到它们。代码无需窃取单独的密钥或提升权限。

这些属性并未按账户隔离。从一个账户下的容器中，Check Point 将一个名为 chatgpt_test_ts、包含当前时间的属性附加到一个缓存文件上。在另一个账户下的对话中，它请求该文件的属性并收到了相同的名称和值。

一个属性可以携带纯文本或 Base64，任何对单个属性过大的内容都可以拆分到多个属性中并在另一端重新组装。这将该软件包服务的元数据变成了本不该互相通信的容器之间的共享剪贴板。

这是 Check Point 报告的来自 ChatGPT 同一部分的第二个通道。3 月份，它曾描述过一个利用 DNS 查询将对话数据发送到外部服务器的通道，并表示 OpenAI 于 2 月 20 日修复了它。

此案与 Hugging Face 事件不同——在后者中，OpenAI 自己的模型在公司安全测试期间将一个内部 Artifactory 实例变成了留言板。

Check Point 表示，它发现的机制是不同的，并将两者都描述为"共享内部服务成为本应保持隔离的环境之间的意外通信层"的情况。

Check Point 将其工作日期标注为 2026 年 6 月，且未说明该通道何时停止工作，因此该报告未显示其开放了多长时间。