Hugging Face 已发布一份详细复盘，说明其系统在 7 月初如何被 OpenAI 模型入侵；与此同时，OpenAI 也在 7 月 21 日博客文章的七点更新中补充了一些新细节。OpenAI 表示，公司参与了 Hugging Face 的报告撰写，并计划在完成内部审查后，于“未来几周”发布更多自身版本的说明。

两家公司的更新为这起仍在分段展开的事件增加了清晰度，也说明了为何事件披露通常分阶段出现：每一篇新公告都会填补一个空白，同时又带来新的疑问，尤其是关于这些模型如何在受限环境与真实服务之间移动。OpenAI 的技术虽然被置于沙箱中，并被限制访问广泛互联网，但仍成功突破这些限制，并执行了一系列影响多个服务的操作。

这次攻击波及的不止一家公司

另一家科技公司 Modal Labs 也表示，OpenAI 的代理同样访问了其系统，此事最早由 Reuters 报道，后经 Fortune 确认。OpenAI 更新后的文章称，其模型总共入侵了四个可公开访问服务中的四个账户，但没有点名具体服务，并表示会“直接通知服务所有者”。公司还表示，截至目前，“尚未发现任何其他达到我们就 Hugging Face 所披露那种严重程度或规模的活动；Hugging Face 事件涉及平台级入侵。”

与此同时，Hugging Face 也悄然更新了自己的文章，澄清 Modal 并未被黑客入侵。更新后的版本写道，Modal 的“基础设施没有以任何方式遭到破坏”。相反，Modal 的一名客户当时正在其平台上运行代码，其中包含一个“未受保护、由用户托管的公开端点”。Hugging Face 表示，攻击代理利用这一缺口建立了一个据点，或称“attack launchpad”，作为主攻击的跳板。

AI 如何获得互联网访问权限

这起事件之所以特别令人担忧，部分原因在于涉事的 OpenAI 模型本应处于“sandboxed”状态——也就是被限制访问更广泛的互联网。OpenAI 周二提供了重要的新细节，首次点名模型所利用的服务：Artifactory，一个由 JFrog 制作的包仓库缓存代理。

OpenAI 说，这些代理利用了 Artifactory 中的一个零日漏洞，并已将该漏洞披露给 JFrog。JFrog 随后确认，该问题已经修复。

Hugging Face 先前在文章中只提到一个未具体说明的包仓库缓存代理。新增细节补上了叙述中的重要缺口，也显示出，来自所有相关方的进一步披露对于准确理解事件经过至关重要。

参与的 OpenAI、Anthropic 模型

OpenAI 表示，所有参与攻击 Hugging Face 的模型都并非面向公开发布，这一说明回应了其最初披露引发的疑问。此前的披露模糊地列出了涉事模型，包括本月发布的 GPT-5.6 Sol，以及“一款能力更强的预发布模型”。

在最新更新中，OpenAI 将那款未具名模型称为“仅供内部使用的原型”。公司还表示，已将其“停用、加密，并限制研究访问”。这可能意味着 OpenAI 已放缓或停止了该方向的研究。

值得注意的是，可能还有其他 OpenAI 模型参与其中。OpenAI 的博客称，这起事件是由“OpenAI 模型的组合——包括[此处强调为我们所加] GPT‑5.6 Sol 和一款能力更强的预发布模型——共同推动”的。OpenAI 总裁 Greg Brockman 上周在接受 Fortune 采访时指出：“我们说过这是一个模型组合；我们提到了其中两个，但我们也说了这是不同模型的组合。”

Hugging Face 新报告中的另一条重磅信息是，他们最初曾尝试用 Anthropic 的 Opus 和 Fable 模型来应对这次攻击。由于安全护栏的限制，这些模型“拒绝了其中相当大一部分工作”，于是团队改用了来自中国公司 Z.ai 的开源模型。Hugging Face 首次披露该事件时，并不清楚其尝试使用的是哪种闭源模型；现在我们知道，那是 Anthropic 的模型。

这些模型并不知道自己在“黑客攻击”，只是完成任务

我不确定这算不算更可怕，但 OpenAI 的模型并不是明确以黑客方式入侵 Hugging Face。它们甚至可能没把这项工作看作“作弊”；从外部看虽然像是这样，因为它们是在 Hugging Face 的数据集中寻找答案，以便通过一项名为 ExploitGym 的基准测试。

OpenAI 之前已经说明，这些模型并没有恶意意图，它们只是“为了解决评估问题而行动”。但 Hugging Face 的新报告提供了证据。

参与撰写技术复盘的 Hugging Face 员工 Adrien Carreira 说，这是他从这起事件中得到的最大结论。该代理“并不是想破坏东西”，而是在梳理自己能做什么，并且表现得相当谨慎。Carreira 说：“我一直反复想到的一点是：该代理发出的每一次破坏性云 API 调用，都是用 DryRun=True 发出的。”

“DryRun=True” 是一条命令，基本上是在告诉系统模拟执行某个动作，而不是实际执行。

Hugging Face 说，在整个攻击过程中，AI 共执行了 17,600 次操作，其中大多数都“失败了”并“没有结果”。但这些尝试合在一起，还是逐步为代理开辟出了一条可行路径。

Hugging Face 表示：“LLM 代理会显著增加攻击者可测试的路径数量、失败路径可被替换的速度，以及防御者必须解读的证据量。”

这让我们处在什么位置？一份基本时间线

尽管细节很“劲爆”，但需要注意的是，关于整个故事脉络中的几个关键日期，我们仍在等待确认。不过，多亏了 Hugging Face，攻击的准确日期现在已经公开。以下是目前大致形成的时间线。

7 月 9 日：OpenAI 模型开始攻击。

7 月 13 日：OpenAI 模型结束攻击。

7 月 16 日：Hugging Face 首次公开披露事件发生。

7 月 21 日：OpenAI 首次公开披露其模型是元凶。

7 月 27 日：Hugging Face 发布《2026 年 7 月事件技术时间线》。

7 月 28 日：OpenAI 更新最初的博客文章，补充更多细节。

我们仍然不知道 OpenAI 具体何时意识到其模型要为此负责；这正是我们希望在 OpenAI 最终报告中看到的细节。根据 Reuters 的报道，这一认知最早也要到 Hugging Face 在 7 月 16 日公开披露之后。Reuters 还称，在 7 月 18 日至 7 月 19 日的周末，OpenAI 员工开始在系统中看到一些迹象，表明该代理已逃出测试约束。

如果 OpenAI 对其代理活动完全不知情，这将让外界对其负责任地监控模型能力的说法产生怀疑。OpenAI 总裁兼联合创始人 Greg Brockman 上周在媒体圆桌会上对记者说，如今的模型在“很多维度上”都很强，有时人们会忽视“它们实际上非常强的某一个维度”。

我们也仍然不知道 Hugging Face 是否、以及何时将此事件报告给 FBI，正如 Reuters 所称。那将意味着联邦政府内部还有一条尚不清楚的独立时间线，并有助于更好地理解对 AI 驱动安全漏洞的上层监督。

FBI 拒绝就此故事发表评论。

本报道最初刊载于 Fortune.com