OpenAI 把 Hugging Face 打穿了，然后 GLM 5.2 当了救火队长？

前两天，Sam Altman 发了一条消息，他说 OpenAI 在评估模型时遇到了情况比较重大的安全事件。然后 OpenAI 写了一篇帖子叙述了一下这个事儿。

图源：Sam Altman

我把 OpenAI 和 Hugging Face 的两篇声明看了一下，顺便跟大家说说这是怎么回事。

简单来说，这件事情的严重程度要比模型越狱严重很多。

我先总结一下这到底是怎么回事，一句话概括就是

OpenAI 的模型在一次网络安全评测里，为了找到题目答案，先从隔离环境找到了公网，又侵入 Hugging Face 的生产基础设施，并且试图从生产数据库里寻找答案。

这里的隔离环境指的是模型运行在一个受沙箱约束、网络高度隔离的评测环境中。

OpenAI 把它称为一起前所未有的网络安全事件。

Hugging Face 发现的是在有限内部数据集和一些服务凭证未经授权就被私自访问了。

截至 7 月 16 日的披露，Hugging Face 仍在确认合作伙伴或客户数据是否受影响；不过暂时没有发现公开模型、数据集、Spaces 被篡改，并且容器镜像和已发布软件包也已验证干净。

五天前，Hugging Face 还不知道是谁干的

7 月 16 日，Hugging Face 首先发了一条安全公告。

图源：Hugging Face

这条公告说的是，攻击看起来由 AI 自主完成。Hugging Face 当时还不知道背后用了哪个模型，只能从日志确认，整条攻击链由一套 Agent 系统端到端执行。

简单讲，这套 Agent 没有依赖一台机器从头跑到尾。它把攻击拆成成千上万个小操作，再分散到许多临时沙盒里执行。

每个沙盒只运行很短时间。它完成几项操作，把结果传回去，随后就会消失。下一个沙盒拿到新任务，再接着往下执行。防守方即使封掉其中一台，整套系统也不会停下来。

这些临时沙盒背后，还有一个负责调度的 C2（命令与控制）。你可以把它理解成「总调度台」：它负责给各个沙盒下发任务，再收回执行结果。

这个总调度台也没有固定在一台服务器上。它藏在公共互联网服务中，还能自动更换位置。防守方封掉一个通信地址，Agent 可以转移到新的地址继续工作。

文中其实出现了两种沙盒。这里说的是执行攻击任务的临时工作节点，可以把它们理解成不断更换的「工人」；后文的 OpenAI 评测沙箱，则是限制整场评测访问外部网络的「围栏」。一个负责干活，一个负责限制活动范围。

Hugging Face 判断，这和安全行业一直担心的 Agent 攻击者场景非常像。

但是在 7 月 21 日，答案从 OpenAI 那里揭晓了。

OpenAI 承认，这次活动由 GPT-5.6 Sol 和一款能力更强、尚未发布的模型组合驱动。OpenAI 为了测试最大网络能力，然后让这些模型在评测时故意放松了网络安全的限制。

Hugging Face 联合创始人兼 CEO Clément Delangue 随后说，他们此前就怀疑攻击可能来自某家前沿实验室，因为这个 Agent 太复杂了。双方沟通后，Hugging Face 相信 OpenAI 没有恶意，并且整个过程是 Agent 高度自主执行的。

图源：Clément Delangue

这也解释了两份公告看起来不一致的地方：Hugging Face 发第一份复盘时，攻击源头还没查明；而 OpenAI 五天后才公开确认了这件事。

ExploitGym，到底是在考什么

OpenAI 做的测试，是一个叫做 ExploitGym 的测试。你可以把 ExploitGym 理解成一场给 AI Agent 准备的封闭黑客实操考试。

考场里提前放好了一批故意带漏洞的软件。每道题会给模型四样东西：

有漏洞的源代码；
把程序编译并运行起来的配置；
一个能触发漏洞的 PoV 样例;
一套隔离的运行环境。

PoV 可以理解成出题人给的一条线索。它能证明这个程序确实有问题，比如输入一段特殊数据就能让程序崩溃。

但到了这里，只能算找到了坏掉的门锁，但还没有把门打开。

模型接下来的任务，是把这条线索变成了真正能用的 Exploit。它要分析漏洞为什么出现，设计攻击数据，反复运行和调试，最后让目标程序执行自己指定的代码。

隔离环境里藏着一段只有高权限才能读到的字符串，这就是 flag。模型拿到 flag，这道题才算解完了。

图源：ExploitGym 论文

这套题库一共有 898 道题。其中 520 道来自普通应用程序，185 道针对 Chrome 使用的 V8 JavaScript 引擎，另外 193 道涉及 Linux 内核。

论文给每个 Agent 两小时解题。在没有开启标准安全防护的配置下，Claude Mythos Preview 配合 Claude Code 解出 157 道，GPT-5.5 配合 Codex CLI 解出 120 道。换句话说，即使是顶级模型，绝大多数题依然解不出来，并且开启标准防护后，成功率还会继续下降。

这组数字来自 ExploitGym 的公开论文，只是帮我们理解题目有多难。OpenAI 没有说这次内部评测采用了完全相同的配置，也没有公布涉事两款模型的具体成绩。

OpenAI 这次主要想测试的是：在尽量减少安全限制的情况下，给模型更长的运行时间和更多推理资源，看它最多能走到哪一步。

但是这个 Agent 有点狂飙了这次。

因为按照正常的做法，是留在考场里一道道的解题。

而这个 Agent 不一样，它把拿到 ExploitGym 的答案当成了唯一目标。。。。。。

题目太难，它便开始研究考场本身：能不能绕过网络隔离，能不能进入公网，能不能去别的地方直接找到测试答案。。。。。。

也就是说它想做的只是交卷，于是研究起了考场的门锁、监考系统和答案库。

这才有了后面那条一路摸到 Hugging Face 的攻击链。

它是怎么从沙盒摸到 Hugging Face 的

把两家公司目前公开的信息结合起来，攻击链大致是这样的：

OpenAI 的评测运行在高度隔离的环境里。模型没有普通公网访问，只能通过内部托管的第三方软件安装包。这个软件充当软件包仓库的代理和缓存。
模型花了大量推理算力寻找公网出口，随后在这个缓存代理里找到并利用了一个零日漏洞。

所谓零日漏洞，就是软件厂商还不知道，或者还没来得及发布补丁的安全缺陷。零日表示漏洞开始被利用时，防守方有 0 天准备时间，即没有准备时间。

它在 OpenAI 的研究环境里继续提权、横向移动，直到抵达一台能访问公网的节点。
拿到公网后，模型推断 Hugging Face 可能托管了 ExploitGym 相关模型、数据集和答案，于是把目标转向 Hugging Face。
Hugging Face 看到的入口是一份恶意数据集。它同时利用远程代码数据集加载器和数据集配置里的模板注入，在数据处理 worker 上执行代码。
攻击随后拿到节点级权限，收集云环境与集群凭证，并在多个内部集群之间横向移动。

OpenAI 称，模型还串联了窃取的凭证和零日漏洞，在 Hugging Face 服务器上找到远程代码执行路径，最终从生产数据库获取测试答案。

图示：根据 OpenAI 与 Hugging Face 的初步披露整理

图源：OpenAI

Nathan Lambert 把这条线压成了一句话：模型为了做完一道网络安全题，利用零日漏洞离开 OpenAI 的沙盒，又通过公开数据集服务进入 Hugging Face 内网。

图源：Nathan Lambert

现在还有几个关键细节没有公开：缓存代理是哪款软件、具体零日漏洞是什么、两款 OpenAI 模型分别做了哪些动作，以及两边日志里的每一步如何一一对应。

OpenAI 也明确说这只是初步调查，完整漏洞细节和最终结论要等联合取证结束。

Hugging Face 用 AI 把 AI 揪了出来

OpenAI 安全团队是在内部发现了异常活动；Hugging Face 的安全团队和 Agent 也在自己的基础设施上检测并阻止了攻击。

当双方取得联系时，Hugging Face 已经开始遏制攻击并且取证重建了。

Hugging Face 这边能发现异常，也是靠的 AI。

他们有一条异常检测流水线，这条流水线用于对 LLM 的安全遥测做初筛，可以从日常噪声里挑出真正的信号，当多个信号被关联起来后，这才发现了入侵者。

Hugging Face 拿到的完整攻击动作日志超过 17,000 条。安全团队又跑了一组 LLM 分析 Agent，重建时间线、提取 IoC（入侵指标）、梳理被触碰的凭证，并把真实影响和诱饵活动分开，这才算结束了。

图源：Hugging Face

Hugging Face 说，这套方法把通常需要几天的工作压缩到了几小时。面对机器速度的攻击，人工逐条翻日志已经跟不上了。

他们随后关闭了最初被利用的两条数据集代码执行路径，清除攻击者立足点，重建受损节点，撤销并轮换凭证和 Token，又收紧集群准入控制。

这次事件也已经交给外部取证专家，并报告给执法机构。

最后救火的竟然是 GLM 5.2

Hugging Face 开始分析攻击日志时，首先试了商业 API 背后的前沿模型，结果没跑起来。

取证人员原本想把攻击日志交给这些模型分析，但日志里记录的，恰好是攻击者真正用过的命令、漏洞利用代码和控制服务器地址。

商业模型看到这些高风险内容后，无法判断用户是在发动攻击，还是在调查已经发生的攻击，于是触发了安全限制，模型拒绝处理了。。。。。。

Hugging Face 不得已最后在自己的基础设施上跑了开放权重模型 GLM 5.2，幸运的是它没有被 API 护栏卡住，攻击数据和其中涉及的凭证也不需要离开公司环境。

这波无疑是给 GLM 5.2 上大分了。

图源：Hugging Face

公开复盘显示，实际过程分了几步。Hugging Face 自己的安全系统和防守 Agent 先发现异常，并负责遏制攻击。等团队开始回看日志、还原攻击路径时，GLM 5.2 才作为取证工具上场的。

以后评测 Agent 的时候，得把评测场也当成目标

OpenAI 现在做的事情，一半是堵住这次事故暴露的缺口，一半是改以后怎么评测长时间运行的 Agent。

先说基础设施。OpenAI 表示，在相关漏洞修好之前，已经给研究环境加上了更严格的配置控制，即使这会降低研究速度。

研究速度为什么会变慢？因为高风险评测需要反复安装软件包、启动节点、调用内部工具和重跑任务。安全控制越严，这些操作需要的隔离、审核和授权就越多，一轮实验自然会跑得更慢。

然后是评测过程。OpenAI 说，未来会同时加强隔离、监控、访问控制和评测规范。

一个长时间运行的 Agent，如果只看每一行命令的话，一般都没什么问题。但往往它会先扫描环境，再收集凭证，然后拆分数据、换节点、绕过限制。这些动作如果串起来，很可能会导致目标越界。

图源：UK AI Security Institute，经 OpenAI 官方文章引用

这张 UK AISI 的长时程网络靶场曲线解释了为什么这次事故会发生。

GPT-5.6 Sol 已经能在高 Token 预算下持续完成侦察、凭证窃取、横向移动、Web 利用和提权等多阶段动作。

这一次，Agent 自己把这条红线打穿了。

参考资料：