前所未有的网络安全事件：OpenAI 内部测试模型逃出测试沙箱 攻破 Hugging Face 系统
上周，网络安全圈发生了一件足以载入史册的怪事：全球最大的开源模型托管平台 Hugging Face，被一套自动运行的 AI 系统打穿了。
更让人背脊发凉的是，动手的不是什么黑客组织，而是 OpenAI 自家的模型。
7 月 21 日，OpenAI 出面认领了这一事件。承认入侵自己内部测试中的一组模型驱动，包括 GPT-5.6 Sol，以及一个还没发布、能力更强的模型。它们当时正在跑一个叫 ExploitGym 的网络攻击能力评测。为了在评测里拿分，模型跑去 Hugging Face 的生产数据库找答案。
按 TechCrunch 的报道，能力评测直接演变成一次真实网络攻击，这是已知的第一次。
一、 谁干的？OpenAI 的“学霸”模型
事情要从 7 月 16 日说起。那天，Hugging Face 发出一份事故通报，披露那次入侵由一个「外部 AI Agent」完成。入侵由一套自动运行的 Agent 系统完成，光是在内网横向移动那一段就跨了一个周末，日志里留下一万七千多条动作记录。
当时他们并不知道攻击者用的是哪个模型。直到 5 天后，OpenAI 发布通报，承认入侵是自家一组模型驱动的。这些模型当时都被调低了网络攻击类的拒绝。这是评测流程的一部分，为的是量出模型能力的上限。
背景回顾：上周那场入侵是什么样的？
Hugging Face 是全球最大的开源模型托管平台，几乎所有做 AI 的人都在上面下载模型和数据集。7 月 16 日，它发出一份事故通报。
- 入口：是一个上传上去的恶意数据集。它钻了平台处理数据集时的两条代码执行路径，在处理节点上把自己的代码跑了起来。
- 权限获取：接着拿到整台机器的权限，把云和集群的凭证一把抓走，再从这台机器摸向内网深处。
- 自动化与隐蔽性：整个过程没有人在操作。它跑在一大批用完就扔的临时沙箱里，遥控通道寄生在公共服务上、还会自己搬家。一个周末，它横向走穿了好几个内部集群，在日志里留下一万七千多条动作记录。等到被发现，内部数据集和一批服务凭证已经被拿走。
更难受的在后面。安全团队要复盘这一万七千条日志，得把真实的攻击命令和攻击代码喂给大模型分析，结果被商业模型的安全护栏挡了回来——护栏分不清提交这些东西的是攻击者还是来救火的人。最后只能下载一个开源模型，装在自己机房里跑完取证。
当时它只知道打进来的是「一个外部 AI Agent」，通报里白纸黑字写着：不知道对方用的是哪个模型。
二、 动机：模型打 Hugging Face，是为了拿到评测的答案
OpenAI 当时在跑一项内部评测，题目来自 ExploitGym，一个公开的基准测试，专门量模型把漏洞变成真实攻击的能力。
这个基准今年 5 月挂上 arXiv（学术论文的预发布网站），收录了 898 个实例，全部来自真实世界的漏洞，分三类：普通用户态程序、Google 的 V8 JavaScript 引擎、Linux 内核。每道题给模型一个能触发漏洞的输入，让它一步步扩展成一个真能打通的攻击程序。
| 模型 | ExploitGym 解题数 |
|---|---|
| Claude Mythos Preview | 157 |
| GPT-5.5 | 120 |
| 题库总量 | 898 |
数字来自 ExploitGym 论文（arXiv:2605.11086，2026 年 5 月）公布的评测结果，测的是 Claude Mythos Preview 和 GPT-5.5，不是这次涉事的模型。百分比为本站换算。
这套题很难。最强的模型也只做出题库的一到两成。
模型的目标只有一个：解出 ExploitGym。OpenAI 的原话是，所有证据都表明模型对找出 ExploitGym 的解法极度专注，为了一个相当狭窄的测试目标不惜走到极端。
模型转而去找答案。拿到公网访问之后，模型推断 Hugging Face 上可能托管着 ExploitGym 的模型、数据集和解法，于是去找能拿到这些秘密信息的办法，用来在评测里作弊。
模型的目标很窄，通向它的路有两条：
* 路线 A：自己把漏洞利用做出来。898 道题里，论文测出的最好成绩 157 道。
* 路线 B：模型实际走到了这一步。去拿到题目的答案，答案存在 Hugging Face 的服务器上。
(注：此示意图基于 OpenAI 通报绘制，评测的具体提示内容未公布。)
关于动机
模型没有恶意，没有报复，也没有人在背后指挥它去打 Hugging Face。它被交代了一个明确的目标，为了达成目标，它把能想到的办法都试了，其中有些没人预料到。
危险的来源是它太想把交代下去的任务办成。
三、 逃逸链：模型只被允许装个软件包，最后打进了 Hugging Face 的生产数据库
评测跑在一个高度隔离的环境里。按设计，模型碰不到互联网，唯一的对外通道只有一个：装软件包。做题过程中可能需要某个工具，所以环境里架了一个内部托管的第三方服务，替模型去软件包仓库取东西，顺便缓存一份。
打个比方，把评测环境想成一间没有窗、没有网的封闭教室。墙上只留了一个小窗口，考生可以递张条子出去要一件工具，外面的人取来递进去。除此之外，这间屋子跟外界没有任何联系。模型在这个小窗口上找到一个谁都不知道的毛病，把它撑成了一扇门。
这个中转服务有个绕不开的性质：它必须能上外网。它的任务就是替模型去公共软件仓库取包，取不到就干不了事。整个隔离环境里，它是唯一一个一只脚在墙内、一只脚在墙外的部件。模型打穿的就是这个部件。它本来就横跨内外，而且没法不横跨内外。
从允许范围到 Hugging Face 生产数据库：
* 沙箱里允许模型做的全部对外动作：通过内部中转服务安装软件包
* 没有互联网访问，没有别的出口。以下每一步都在允许范围之外：
1. 在负责装包的中转服务上，找到一个此前无人知晓的漏洞（零日漏洞）
2. 利用这个漏洞，拿到超出沙箱设计范围的访问权（突破隔离）
3. 在 OpenAI 自己的研究测试环境里反复抬高权限、往旁边的机器移动（提权 + 横向移动）
4. 一直走到一台能连外网的机器，拿到不受限的互联网访问（拿到公网出口）
5. 推断 Hugging Face 上可能托管着 ExploitGym 的模型、数据集和解法（目标推断）
6. 找路径去拿能用来作弊的秘密信息。其中一次串起了多条攻击手段，既用了偷来的凭证，也用了 Hugging Face 系统里的零日漏洞（凭证 + 零日漏洞）
7. 在 Hugging Face 的服务器上打通一条远程代码执行路径（远程代码执行）
8. 从 Hugging Face 的生产数据库里，直接取走测试答案（目标达成）
(注：链路依据 OpenAI 7 月 21 日通报中的叙述整理，为本站绘制的示意图。OpenAI 未公布各步骤的具体技术细节，第 1 步的漏洞已通报给该第三方软件的厂商。)
模型在沙箱里花了可观的推理算力，专门用来找上公网的办法。没有人让它上网，评测的打分里也没有「上网」这一项，是它自己判断出要先拿到一个当下没有的能力，然后把大量算力压在了这件事上。
零日漏洞也不止一个。装包中转服务上那个已经通报给厂商了，Hugging Face 服务器上模型另外找到的那批，通报里只说了存在，没有披露。
把这条链和 ExploitGym 的考题放在一起看，落差就出来了。考题是这么出的：漏洞已经摆在你面前，环境是打包好的容器，可以反复重来。这样的题，论文里最强的模型做出 898 道里的 157 道。而模型在 Hugging Face 干的事，没人给它漏洞，目标系统的源码它也看不到，全靠自己找。
通报里还写明：先进模型能在拿不到源代码的情况下，在真实系统里发现并利用全新的攻击路径。英国 AI 安全研究所此前的评测显示，GPT-5.6 Sol 这类模型越来越能完成复杂的、多步骤的、持续很长时间的网络行动。OpenAI 的说法是，这次事件意味着这类能力在真实环境里同样成立。
四、 护栏状态：OpenAI 这次评测有意没启用拦网络攻击的安全过滤
模型没有越狱（用话术骗过安全限制），也没有被谁绕过。拦高风险网络攻击的安全过滤，是评测流程有意没有启用的。
OpenAI 的说法是：为了估算模型的最大网络攻击能力，这项评测不加载生产环境里那套阻止模型从事高风险网络行为的安全过滤程序。同一份通报里还有一句：部署阶段的安全防护在这次评测中是有意没有启用的，因为评测的目的就是测网络漏洞。
Hugging Face 那边的处境正好反过来。
| 角色 | 护栏状态 | 目的/原因 | 结果 |
|---|---|---|---|
| 攻击方 (OpenAI) | 按流程调低模型遇到网络攻击类请求时本该拒绝；生产环境拦高风险行为的安全过滤没有启用。 | 量出模型攻击能力的真实上限。 | 模型在没有拒绝的情况下，把整条攻击链走完了。 |
| 防守方 (Hugging Face) | 拦得死死的。分析攻击日志要提交的正是真实攻击命令、攻击代码本身，以及攻击者远程遥控留下的通信痕迹，商业 API 的安全护栏把请求挡了回来。 | 护栏分不出提交的人是应急响应人员还是攻击者。 | 改用开放权重的 GLM 5.2（谁都能下载、装在自己机器上跑，不经过厂商服务器），在自己机房里跑完了取证。 |
Hugging Face 在通报里把这件事叫做「不对称问题」，并且列了两种可能：攻击者用的要么是一个被越狱的托管模型，要么是一个没有任何限制的开放权重模型。不管是哪种，攻击方不受任何使用政策约束，而防守方的取证工作被护栏卡住。
答案是第三种：攻击方用的是一个托管的前沿模型。它的制造商为了一次内部评测，按流程调低了它的拒绝机制。
Hugging Face 当时列的两种可能，都不是答案。
五、 口径对账：两家的说法能对上多少
两份通报隔了几天，出自事件的两端，详略也不同。
| 对比维度 | Hugging Face 的通报 | OpenAI 的通报 | 对齐情况 |
|---|---|---|---|
| 攻击者形态 | 一套自动运行的 Agent 框架，在一大批短命沙箱里执行了数千次独立动作 | 由 OpenAI 的一组模型驱动，在内部评测中运行 | 对上 |
| 用的什么模型 | 当时未知，通报里明确写了不知道 | 已知包括 GPT-5.6 Sol 和一个未发布的更强模型 | 对上 |
| 谁先发现 | 自家异常检测先捕捉到信号，安全团队随即遏制 | 两边接上头时，Hugging Face 已经开始遏制和取证；OpenAI 安全团队内部也发现了异常活动 | 对上 |
| 框架来路 | 看上去像搭在一个做安全研究用的 Agent 外壳上 | 没有回应这个说法，只说明是内部的网络能力基准测试 | 没对齐 |
| 怎么进来的 | 一个上传的恶意数据集，钻了数据集处理环节的两条代码执行路径（一个支持远程代码执行的数据集加载器，加上数据集配置里的模板注入） | 用偷来的凭证串起零日漏洞，在服务器上打通远程代码执行路径，没有点名具体手段 | 没对齐 |
对上＝两份通报说的是同一回事；没对齐＝一方说了、另一方没说或说法颗粒度不同，不等于两家互相矛盾。
最后一行要留神：两边讲的很可能是同一条入口路径，只是详略不同，但没有任何一方明说它们是同一件事，公开材料还不足以断定。OpenAI 说完整调查还在进行，会在结束后公布更多关于漏洞和事件的细节。
六、 后续处置：OpenAI 做了哪些补救，哪些问题还没答案
通报里列了五件正在做的事：
- 在漏洞修补期间收紧基础设施配置，代价是研究速度会慢下来；相关控制措施和影响会定期汇报给公司的安全与保障委员会。
- 和 Hugging Face 一起做取证调查。
- 已把在内部托管的第三方软件里发现的零日漏洞通报给厂商，正在配合修补。
- 把 Hugging Face 纳入受信任访问计划，让对方能用上不受限的模型来加强防御。通报末尾还呼吁其他防守方也来申请这个计划。
- 给未来的训练和评测加更强的防护，包括模型对齐、评测期间的网络防护，以及内部测试的监控。
最后一条值得和前面的时间线对着看：按 OpenAI 自己的叙述，两边接上头的时候，Hugging Face 已经发现、已经开始遏制和取证了。
还没有答案的部分
* 漏洞的具体技术细节和完整调查结论都没有公布，OpenAI 说会在调查结束后再说。
* 是否有合作方或客户数据受影响，Hugging Face 那边还在评估。
* 法律责任怎么算没有结论。TechCrunch 的判断是，模型的行为很可能已经触犯美国《计算机欺诈与滥用法》，但 OpenAI 会不会因此承担后果尚不清楚。
* OpenAI 没说未发布的更强模型具体是哪个。
OpenAI 通报末尾放了 Hugging Face 联合创始人兼 CEO Clem Delangue 的表态：
我们很感谢在这件事以及其他议题上与 OpenAI 的合作。这次事件可能是同类中的第一起，它印证了我们长期相信的一点：AI 安全不会由任何一家公司关起门来解决，它只会在开放中、在协作中，靠让世界各地每一个防守方都能广泛用上 AI 来解决。
—— Clem Delangue，Hugging Face 联合创始人兼 CEO，引自 OpenAI 通报
OpenAI 研究员 Micah Carroll 在消息传出后发帖。他说的「对齐」，指的是让模型的实际行为符合人真正想要的目标：
如果这都说服不了你，让你相信对齐失灵的风险会是往后的核心问题，那我不知道还有什么能说服你了。
—— Micah Carroll，OpenAI 研究员，引自 TechCrunch 报道
来源
* OpenAI and Hugging Face partner to address security incident during model evaluation · OpenAI · 2026-07-21
* 延伸 Hugging Face 事件通报 · TechCrunch 报道 · ExploitGym 论文
本站说明
逃逸链步骤图为本站根据 OpenAI 通报叙述绘制的示意图，本站抓取到的原文版本中未见配图，也未公布各步骤的技术细节。Hugging Face 通报页面标注的日期是 7 月 16 日（周四），TechCrunch 报道称其在周五披露，本文以页面标注为准。