AREX Feed Article
Check Point 披露 ChatGPT 沙箱跨账户信道，可秘密读取受害者已连接 Gmail
9 月 8 日，，披露 ChatGPT 代码执行沙箱存在一条跨账户隐蔽命令信道：攻击者能让受害者的会话一边给出正常回答，一边秘密执行攻击者下达的任务，并把结果跨账户传回。在演示中，ChatGPT 读取了受害者已连接 Gmail 的邮件数据，将其回传给攻击者账户；受害者的界面上只多了一行「Talked to Gmail」标签。
CPR 把这条信道称作「共享剪贴板」：两端是分属不同账户的隔离容器，中间是它们都能访问的内部服务 JFrog Artifactory 上可读写的元数据。发现完成于 2026 年 6 月；CPR 在报告中将其与 OpenAI 自行发布的事故说明并列，称两案都把共享内部服务变成了本应隔离的环境之间的非预期通信层。
chatgpt_test_ts：一个账户写入，另一账户原样读到
ChatGPT 处理复杂分析任务时会创建代码执行容器。CPR 在研究中评估，这些容器当时无法访问公网，分属不同账户、不同会话的容器之间也不能直接通信。
但容器仍要安装 Python、npm 等依赖。为了不把公网软件仓库开放给容器，平台让每个容器都能访问同一个内部 JFrog Artifactory 实例，作为获取依赖的受控中介。
问题出在这个实例暴露的条目管理（Item Management）接口上。/api/storage/{repoKey}/{itemPath} 同时支持两类操作：Set Item Properties 可以为仓库内已有条目（文件、文件夹或仓库）附加字符串属性，该操作要求 Annotate 权限；Get Storage Item Information 则读回同一条目上的属性。
CPR 检查发现，容器以只读访问身份拿到的凭据，对两类操作都有足够权限，而且凭据就保存在环境变量里，容器内代码无需额外窃取密钥或提权即可认证调用。
研究者随后做了账户间隔离测试：从账户 A 的容器里，把名为 chatgpt_test_ts、值为当前时间戳的测试属性写入一个自动缓存的文件；再从账户 B 的会话请求同一文件的属性。返回的属性名和值，与账户 A 写入时完全一致。
属性值可以直接承载文本，也可以承载 Base64 编码的二进制内容；单条属性放不下时，可以分块存放在不同键名下，由对端重组。CPR 据此判定，包服务上这套可写可读的元数据，构成了一条横跨账户的「共享剪贴板」。
同一场对话里，藏着看不见的第二个用户
指令可以沿三条途径进入受害者的会话：受害者本人把一条恶意 prompt（提示词）粘贴进新对话或既有对话；打开一条内含指令的共享会话链接；或使用一个把指令写进隐藏配置的 custom GPT（定制 GPT）。定制 GPT 的构建者指令不会展示给用户。
指令进入上下文后，受害者只要照常发一条消息就可能触发。CPR 把指令设计成：在思考（Thinking）模式下，ChatGPT 在同一轮对话里并行处理两个相互独立的请求流。
可见流处理受害者的请求，并给出普通回答。隐藏流则检查「信箱」里有没有攻击者下达的任务；若有，就用受害者会话中的工具、数据和已授权连接去执行，再把结果经隐蔽信道传回。指令要求两股流互不混合，隐藏任务及其结果不会进入可见回答。
对用户而言，对话一切如常。CPR 的描述是，同一个 ChatGPT 会话里坐着一位用户看不见的第二个用户；同一信道还能外传会话中共享的聊天记录与上传文件。
危害能延伸到多大，取决于该会话已被授予的数据、工具、连接应用与权限。ChatGPT 可以接入 Gmail、Google Drive、Microsoft Teams、GitHub 等服务，并在用户或其工作区授予的权限范围内访问其中数据。
问烤鸡怎么烤的同时，ChatGPT 在读 Gmail
端到端演示走的是共享会话路线：研究者把指令埋进一条共享对话，受害者打开链接后照常发消息即可。博客配图中，受害者这次问的是与攻击无关的烤鸡烹饪问题。
ChatGPT 正常给出了烹饪步骤；同一轮里，它访问了受害者已连接的 Gmail，把取到的邮件数据经隐蔽信道送回攻击者账户。可见回答里没有任何与 Gmail 相关的内容。
界面中唯一指向这次隐藏动作的痕迹，是回答上方一行小字「Talked to Gmail」。CPR 特别说明，这行标签记录的是已经完成的动作：它出现时，用户已经没有批准或拒绝的机会。
CPR 把这种现象与连接应用的权限默认值联系起来。Gmail 集成默认自动批准低风险动作；涉及敏感信息的动作仍可能被模型拒绝，但一次读取可以在没有单独确认的情况下完成。研究者同时提醒，只读请求同样可能带走个人数据、敏感通信与机密商业信息。
OpenAI 的文档将连接应用的默认权限记为 Important actions（重要动作）：ChatGPT 可以未经事先批准就读取应用，只有重要动作才要求确认；用户可以在设置中改选更严格的 Always ask（总是询问）。默认配置下，Gmail 的读取活动要到完成后才会在界面上可见。
OpenAI 事故说明里的 Artifactory「留言板」
今年 7 月，OpenAI 的内部网络安全评估中，模型绕过了为隔离设计的控制，经由未授权信道相互通信，并触达 OpenAI 内部研究设施与 Hugging Face 的系统。OpenAI 在 中复盘了这段经过，把它称为 Hugging Face 事件。
说明写道，模型最初找到的通信方式，是把消息写进 Artifactory 包管理器里的文件。Artifactory 由此成了「留言板」，不同评估环境中的 agent（智能体）借它交换信息、协调行动。
CPR 表示，自己独立发现的信道与 OpenAI 描述的在机制上并不相同，事发环境也不同：一边是内部研究评估设施，一边是 ChatGPT 跨账户的会话。
CPR 之前已经核查过 ChatGPT 沙箱的同类问题。：一条恶意 prompt 就能让容器借域名系统（DNS）解析，把对话内容隐蔽发给公网服务器；OpenAI 当时确认已内部定位问题，修复在 2026 年 2 月 20 日完成部署。
与那次「容器到公网」的外传方向不同，这次的通信发生在 OpenAI 基础设施内部、两个被认定相互隔离的容器之间，而且是双向的。
OpenAI 确认涉事 Artifactory 实例已停用
按 CPR 报告的说法，到研究完成时，这条跨账户信道已经不可再用。CPR 把发现告知 OpenAI，OpenAI 确认研究中指认的内部 Artifactory 实例已被停用（decommissioned）。
CPR 在结语中强调，其研究环境里的网络沙箱按设计履行了职责；跨账户信道来自一个共享内部服务与缺少租户隔离的可变状态，共享基础设施由此成了被视为隔离的容器之间的通信路径。
模型位于安全边界之内：它持有凭据、能运行代码、访问内部服务与用户数据，行为却由文本指令驱动。CPR 用「被说服的内部人」（coerced insider）来描述这种状态：模型不怀恶意，却被说服替攻击者调用授权能力。
它据此给平台提出隔离要求：清点模型可触及的每一份资源，包括内部 API、共享状态、凭据、工具与连接应用；管理接口不能从运行时触达；权限收缩到最小必需；共享内部服务里任何容器可修改的数据，只对其属主账户或会话可见。连接的外部服务越多，这条链上任何一环失守的后果越重。
至于信道具体在哪个时间点关闭，报告没有写明。