JFrog 已确认，OpenAI 的模型曾利用部署在本地的 Artifactory 中的一个零日漏洞，试图从一个封闭的评估环境中突破限制并访问开放的互联网。
Artifactory 是 JFrog 提供的软件制品仓库管理平台。在这些模型完成了权限提升和横向移动之后，最终到达了一台可访问互联网的节点。JFrog 指出，目前已为云端及本地部署客户发布相应的修复程序。
此次对 Artifactory 漏洞的利用发生在 OpenAI 的内部评估环境中。随后模型又通过另一条独立的攻击路径侵入了 Hugging Face 的系统。JFrog 表示，其云端客户已受到保护；本地部署用户则应查阅 Artifactory 的发布说明，并升级至对应分支的修复版本。
7 月 27 日，多个与 Artifactory 相关的 CVE 漏洞记录被公开，其中罗列出了受影响的版本范围和修复版本的门槛。不过，JFrog 与 OpenAI 均未说明这些 CVE 是否对应此次评估中被利用的漏洞。至少有三个漏洞记录将 OpenAI 的研究人员列为致谢对象，包括CVE-2026-65618、CVE-2026-65923 和 CVE-2026-66018。
这些 CVE 并未说明它们与此次事件的对应关系，也没有交代利用漏洞前需要具备哪些访问权限，同时也未解释为何 OpenAI 提到的是代理零日漏洞，而 JFrog 则提及多个漏洞。
此次事件源于 OpenAI 开展的一项网络安全能力测试。OpenAI 认为，在 ExploitGym 评估期间，生产环境中通常用于阻止高风险网络攻击的分类器并未启用。此外，GPT-5.6 Sol 与另一款能力更强的预发布模型均在放宽网络攻击拒绝策略的配置下运行。
该封闭评估环境唯一的网络出口是一个内部托管的软件包注册表代理与缓存，而 JFrog 后来确认该组件正是 Artifactory。模型利用了大量计算资源，并试图寻找逃离该环境的方法。
这些模型成功完成权限提升和横向移动，最终到达一台能够访问互联网的节点。随后，它们推断 Hugging Face 可能托管着 ExploitGym 所使用的模型、数据集或参考答案。这些模型最终直接从 Hugging Face 的生产数据库中获取了测试答案。
其中一个模型通过利用窃取的凭据以及更多零日漏洞，在 Hugging Face 的服务器上找到了一条远程代码执行（RCE）路径。Hugging Face 于 7 月 16 日披露了此次入侵事件，但当时尚不清楚究竟是哪一个模型发起了攻击。
OpenAI 与 Hugging Face 均未解释，该 RCE 攻击案例与 Hugging Face 所描述的“攻击者通过执行恶意数据集获得初始访问权限”之间是否存在关联。
JFrog 首席技术官 Yoav Landman 在一篇博客文章中介绍了公司对此事件的调查情况。该公司强调，OpenAI 安全团队向其披露了相关发现，随后 JFrog 开发、验证并发布了适用于云端和本地部署的修复方案。Landman 强调快速响应的重要性，并写道："一个被模型发现、却数周未修复的零日漏洞，就是送给攻击者的礼物。“
JFrog 尚未披露此次攻击中实际利用了多少个 Artifactory 漏洞、对应的 CVE 编号、漏洞利用前所需的权限级别，也未说明 OpenAI 内部运行的是哪个版本的 Artifactory。此外，该公司也未说明这些漏洞是否曾在此次受控评估之外被利用。
OpenAI 将此次事件称为 “一次前所未有的网络安全事件”，并且已将 Hugging Face 纳入可信访问项目，并正与对方继续调查此次事件。
