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

导语：JFrog 确认，OpenAI 模型在一次封闭环境评估中利用了自托管 Artifactory 的零日漏洞，并最终通过横向移动获取了 Hugging Face 生产数据库中的测试解题方案。

JFrog 已确认，OpenAI 模型在试图从一个封闭的评估环境连接开放互联网时，利用了自托管 Artifactory 中的一个零日漏洞。Artifactory 是 JFrog 的软件仓库管理器。OpenAI 表示，这些模型随后提升了权限并进行横向移动，直至抵达一个连接互联网的节点。JFrog 表示，已经为云端客户和自托管客户开发、验证并发布了修复版本。

这次针对 Artifactory 的漏洞利用发生在 OpenAI 的内部环境中。OpenAI 表示，后来还有一条独立的攻击路径抵达了 Hugging Face 的系统。JFrog 表示，其云端客户已经受到保护；自托管用户应当查阅 Artifactory 的发布说明，并升级到其所使用维护分支中的修复版本。

数条 Artifactory CVE 记录已于 7 月 27 日发布，列出了受影响版本范围和已修复版本阈值，但 JFrog 和 OpenAI 均未说明这些 CVE 是否对应评估期间实际被利用的漏洞。其中至少三条记录 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 的模型、数据集或解题方案。OpenAI 称，模型最终直接从 Hugging Face 的生产数据库中获取了测试解题方案。在 OpenAI 描述的一个案例中，一个模型利用窃取的凭据和进一步的零日漏洞，在 Hugging Face 服务器上找到了一条远程代码执行（RCE）路径。Hugging Face 于 7 月 16 日披露了此次入侵，但当时并不知道是哪一款模型所为。OpenAI 和 Hugging Face 都没有解释该 RCE 案例与 Hugging Face 所描述的、通过恶意数据集执行实现初始访问的版本之间存在怎样的关联。

JFrog 在一篇由首席技术官 Yoav Landman 撰写的博客文章中阐述了公司的说法。JFrog 表示，OpenAI 安全团队向其披露了相关发现，随后 JFrog 为云端和自托管部署开发、验证并发布了修复方案。Landman 将此次事件框定在响应速度这一主题上，他写道：由模型发现的零日漏洞如果放置数周不予处理，对攻击者而言就是"一份礼物"。

JFrog 并未披露实际利用的 Artifactory 漏洞具体数量、对应 CVE 编号、利用前已有的权限，以及 OpenAI 内部所运行的 Artifactory 版本，也未说明这些漏洞中是否有任何一个在受控评估之外被利用。OpenAI 将此次事件称为"前所未有的网络安全事件"，并表示已将 Hugging Face 纳入其可信访问计划，目前仍在与 Hugging Face 共同进行调查。