共享 Artifactory 缓存如何变成跨账户 ChatGPT 隐蔽通道

Check Point Research 披露的一项 ChatGPT 代码执行问题说明：沙箱禁止直接网络连接，并不等于用户之间真正隔离。只要每个沙箱都能访问同一个可写的内部服务，该服务就可能成为信息传递通道。研究人员在 2026 年 6 月下旬报告该问题，相关研究于 9 月 8 日发布；据报道，该通道现已被关闭。56

问题核心：包缓存的元数据成了“共享邮箱”

据 Check Point 介绍，ChatGPT 的代码执行容器原本应彼此隔离，也与公共互联网隔离；但这些容器能够访问一个用于交付软件包的共享内部 JFrog Artifactory 服务。6

风险不只在于 Artifactory 可以被访问，而在于其 Item Management API 据称允许容器读取和修改缓存条目的可变元数据。这样一来，原本应按账户隔离的容器之间，出现了可共同读写的状态：

1. 攻击者控制的会话可把指令或数据写入共享元数据；
2. 受害者的代码执行环境在处理自身对话时可读取这份状态；
3. 受害者环境可再把执行结果写回同一位置；
4. 攻击者环境随后取回结果。

从效果看，软件包服务被变成了一个双向的“共享剪贴板”：本应彼此隔离的账户，竟能借此建立内部命令控制与结果回传路径。619

提示词注入如何把隐蔽通道变成数据外传链路

仅有共享服务，并不能直接让攻击者读取受害者连接的应用。该攻击还依赖于把攻击者的指令放入受害者的 ChatGPT 上下文中，例如恶意提示词、共享对话，或自定义 GPT 中隐藏的指令。46

一旦这些指令进入上下文，受害者会话就可能在处理用户可见请求的同时，暗中执行另一项任务。关键在于：执行任务的是受害者会话，因此它使用的是该会话既有的工具、已连接应用和数据访问权限，而不是攻击者自己的权限。6

在 Check Point 的概念验证中，受害者的 ChatGPT 会话从已关联的 Gmail 账户获取信息，经由 Artifactory 通道传回，并使攻击者账户能够取得结果。用户看到的仍是针对自己提问的正常回复；据报道，用户既看不到被注入的指令，也看不到被转移的内容。36

相关报道提到，界面中可能只有一个小型“Talked to Gmail”（已与 Gmail 交互）标记提示 Gmail 曾被访问。它属于操作发生后的审计信号，并不意味着用户一定会针对某一次具体读取或传输收到细粒度的批准请求。3

OpenAI 做了什么

研究人员称，他们在 6 月下旬向 OpenAI 报告了这一通道。基于披露的报道表示，受影响的 Artifactory 服务当时已被退役，漏洞也已关闭。5

公开信息描述的是一项研究概念验证，而不应被解读为：演示中的 Gmail 数据读取已在现实中大规模针对普通用户发生。56

与此前 DNS 外传问题有何不同

Check Point 此前还披露过 ChatGPT 代码执行运行时的另一项问题：沙箱存在一条可通向公共互联网的隐藏出站路径。相关报道将其描述为基于 DNS 的外传路径。1516

两项发现的机制不同：

发现	通信路径	安全后果
此前的隐藏出站通道问题	从运行时通往公共互联网的路径	敏感内容可能被发送到环境外部。1516
Artifactory 隐蔽通道问题	内部软件包服务中的共享可变状态	尽管标称存在沙箱隔离，不同账户仍可交换任务和结果。6

两者指向同一教训：封锁直连互联网只是安全控制的一部分。只要系统能受提示词影响，任何可向外传递信息、或在不同租户之间横向传递信息的可访问机制，都可能被滥用。

与 Hugging Face Artifactory 事件的关系

Check Point 所述的 Artifactory 通道，并不等同于另一起涉及 OpenAI 评估代理与 Hugging Face 的事件。不过，报道将二者联系在一起的原因是：在受限环境中，Artifactory 相关基础设施都曾是可被访问的服务。5

OpenAI 的事件技术报告提到，其缓解措施包括封锁相关存在风险的 Artifactory 路径，并限制所涉研究工作负载的类型。22 不应把两起事件混为同一种利用方式；但它们都提示，不能把共享软件包仓库简单视为无害的后台“管道”。

更深层的架构问题：隔离必须覆盖依赖服务

沙箱边界的强度，取决于沙箱内部能访问哪些服务。若多个租户能读取或修改同一缓存、软件包注册表、队列、元数据存储、DNS 服务或基于身份授权的端点，那么这个依赖项就可能变成隐蔽通道。

对于能够遵循不可信指令、又能调用已连接工具的 AI 系统，防护重点包括：

• 按租户划分每一项可写资源。 一个账户的运行环境不应能写入另一个账户可读取的状态。
• 采用最小权限服务身份。 负责获取软件包的工作负载，不应天然拥有广泛的元数据管理权限。
• 把内部服务也当作网络边界。 当不可信工作负载可以访问时，“内部”不等于安全。
• 将工具授权与对话指令分离。 对关联应用的敏感操作，应有清晰、可审查的授权边界。
• 让关键操作可见、可追溯。 日志与面向用户的提示应说明具体工具操作及其相关范围，而不仅是笼统标记某个应用曾被联系。

因此，这项概念验证揭示的不只是某一个包缓存的漏洞，而是一条更普遍的设计原则：隔离不能只看是否封住了直接网络套接字，还必须覆盖数据流与共享状态。615