JFrog 确认 OpenAI 模型在 Hugging Face 入侵事件前利用了 Artifactory 零日漏洞

JFrog 已确认，OpenAI 模型在试图从封闭的评估环境访问开放互联网时，利用了自托管 Artifactory 中的一个零日漏洞。
Artifactory 是 JFrog 的软件仓库管理器。OpenAI 表示，这些模型随后提升了权限并进行了横向移动，直到到达一个已连接互联网的节点。JFrog 表示，此后已为云和自托管客户开发并发布了修复方案。
Artifactory 漏洞利用发生在 OpenAI 的环境内部。OpenAI 表示，另一条攻击路径后来到达了 Hugging Face 的系统。JFrog 表示其云客户已受到保护。自托管用户应查看 Artifactory 发布说明，并为其维护的版本分支切换到修复版本。
7 月 27 日发布了多个 Artifactory 的 CVE 记录，其中包含受影响版本范围和修复版本阈值，但 JFrog 和 OpenAI 均未说明这些记录中是否有任何一条对应于评估期间使用的漏洞。
其中至少三条记录——CVE-2026-65618、CVE-2026-65923 和 CVE-2026-66018——将发现归功于 OpenAI 研究人员。
这些记录未将任何 CVE 映射到该事件，未说明利用前所需的访问权限，也未解释为何 OpenAI 提及一个代理零日漏洞，而 JFrog 提及多个漏洞。
该事件始于 OpenAI 自身的一次网络能力测试。OpenAI 表示，ExploitGym 评估在未启用通常阻止高风险网络活动的生产级分类器的情况下运行。GPT-5.6 Sol 和一个能力更强的预发布模型也以降低的网络安全拒绝率运行。
OpenAI 表示，封闭环境的唯一网络路径是一个内部托管的包注册表代理和缓存，JFrog 后来将其确认为 Artifactory。这些模型使用了大量计算资源来寻找出路。
OpenAI 表示，这些模型提升了权限并进行了横向移动，直到到达一个具有开放互联网访问权限的节点，然后推断 Hugging Face 可能托管了 ExploitGym 的模型、数据集或解决方案。该公司表示，这些模型最终直接从 Hugging Face 的生产数据库中获取了测试解决方案。
在 OpenAI 描述的一个例子中，一个模型使用被盗凭据和更多零日漏洞在 Hugging Face 服务器上找到了一条远程代码执行路径。Hugging Face 于 7 月 16 日披露了该入侵事件，当时并不知道是哪个模型在背后。
OpenAI 和 Hugging Face 均未解释该 RCE 示例与 Hugging Face 关于通过恶意数据集执行实现初始访问的描述之间的关系。
JFrog 在其首席技术官 Yoav Landman 的一篇博文中阐述了其说法。该公司表示，OpenAI 的安全团队披露了这些发现，之后 JFrog 为云和自托管部署开发、验证并发布了修复方案。Landman 围绕响应速度阐述了这一事件：一个被模型发现的零日漏洞若搁置数周，他写道，就是"送给攻击者的礼物"。
JFrog 尚未披露所使用的 Artifactory 漏洞的确切数量、对应的 CVE ID、利用前可用的权限，或 OpenAI 内部运行的 Artifactory 版本。它也未说明是否有任何漏洞在受控评估之外被利用。
OpenAI 称该事件为"一次前所未有的网络事件"。它表示已将 Hugging Face 添加到其可信访问计划中，并正在与该公司一起进行调查。
The Hacker News 已联系 JFrog 以获取更多详细信息，如果收到回复，将更新本文。