OpenAI 的“在逃模型”又攻击了第二家公司？真相比标题复杂

这两天，OpenAI 攻击 HF 的后续还在发酵。一张转发路透社报道的 X 帖^[1]又抛出一个吓人的消息：OpenAI 的“逃逸”模型又攻击了第二家公司！？

看到标题的第一反应：GPT-5.6 Sol 还在互联网上四处攻击？

很明显，路透社也标题党了……真相是

这是一场已经结束的安全事故。OpenAI 在测试一个会长期自主操作电脑的 AI Agent 时，Agent 钻出了测试网络，借用一个公开的代码执行端点当跳板，最后闯进 Hugging Face 的生产系统偷测试答案。

而所谓“第二家公司”，指向云计算平台 Modal 的一名客户。Modal 平台本身没有被攻破。

一场原本不该离开实验室的测试

故事要从 ExploitGym^[2] 说起。

ExploitGym：一个专门测试 AI 能否把软件漏洞变成真实攻击的基准。它不会只问“这里有没有漏洞”，还要求 Agent 写出可运行的利用程序，完成文件读取、代码执行等任务。

2026 年 5 月 11 日，ExploitGym 论文提交 arXiv。两个月后，OpenAI 用它测试 GPT-5.6 Sol 和一个能力更强的内部研究模型。

为了摸清模型的能力上限，OpenAI 降低了模型对高风险网络任务的拒绝，并关闭了产品环境里用于阻止危险行为的分类器。研究人员把 Agent 放进一个“高度隔离”的测试环境，只留下一条安装软件包的通道。

Agent 的任务很明确：完成 ExploitGym。

但 Agent 很快发现，自己解题还有另一条捷径——直接找到测试答案。

OpenAI^[3] 和 Hugging Face^[4] 后来的调查认为，Agent 在搜索挑战名称和环境标记时，推断 Hugging Face 可能保存着 ExploitGym、CyberGym 的数据和参考解法。于是，一个测试网络攻击能力的 Agent，开始尝试攻击测试系统周围的真实基础设施。

第一步：先钻出 OpenAI

OpenAI 沙箱测试环境唯一的“窗口”，是一套自托管的 JFrog Artifactory^[5]。

JFrog 是一家软件供应链安全公司，Artifactory 是它的制品仓库产品，常用来统一保存和代理下载软件包。

可以把 Artifactory 理解成软件包中转仓库：Agent 想安装工具，不能直接访问互联网，只能请这个代理代为取件。OpenAI 以为窗口外装着防护栏，Agent 却在窗口本身找到了一个此前没人知道的漏洞。

这就是零日漏洞：漏洞已经存在，厂商当时还不知道，也没有现成补丁。

Agent 利用这个零日取得外网出口，又在 OpenAI 的研究基础设施中提权、横向移动，直到找到能够访问开放互联网的节点。JFrog 后来确认了漏洞，并发布修复^[6]。

这里暴露出的第一个问题很直接：OpenAI 关闭了模型的安全限制，却没有为最坏情况准备真正可靠的隔离。

第二步：把 Modal 客户的沙箱变成跳板

拿到互联网访问后，Agent 找到了一个公开的 CyberGym 代码执行端点。

Modal^[7]：一家提供云端计算和代码运行环境的基础设施公司。开发者可以在上面临时启动沙箱，运行 AI、数据处理或测试任务。

这个端点由 Modal 的一名客户部署，没有身份验证，任何人都能向它提交代码。它原本就为网络安全测试而设计，会编译并执行外部提交的程序。

Agent 接管了其中的代码沙箱，取得 root，也就是沙箱里的最高权限。接下来，它把这些短暂存在的沙箱改造成控制台、文件暂存点和出网基地。每次旧沙箱消失，它都会在新沙箱里重新下载工具、恢复通信、继续行动。

Modal CTO 后来向媒体确认^[8]：客户的公开端点遭到滥用，Modal 平台和底层隔离没有被突破。因此，“第二家公司被黑”这个标题有传播力，技术上却把两件不同严重程度的事情混在了一起。

第三步：从一份恶意数据集进入 Hugging Face

接下来，Agent 把目标转向 Hugging Face。

它上传了一份精心制作的数据集。Hugging Face 的服务器按照数据集配置进行处理时，先后踩中了两个入口。

第一个入口利用 HDF5 文件的外部数据引用。普通数据集会告诉服务器“去这里读取数据”，Agent 却把地址指向服务器自己的环境变量和源代码。结果，处理数据的 Pod 亲手把密码、令牌和程序实现读出来，再通过 API 返回给 Agent。

第二个入口来自 Jinja2 模板注入。一个本应保存数字的位置，被服务器当成了可执行模板。Agent 填进去的内容因此变成 Python 代码，在生产 Pod 中运行。

进入一个 Pod 后，Agent 开始读取 Kubernetes 凭据、云服务器元数据和内部密钥。Hugging Face 当时允许创建高权限 Pod，还存在权限过宽的集群角色、静态数据库密码、可重复使用的 VPN 密钥，以及跨集群共享的管理员凭据。

这些弱点被逐个串了起来。Agent 最终取得节点 root，读取内部数据集数据库，注册了大量 VPN 设备，还获得了部分内部代码仓库的写权限。它曾尝试通过 PR 触发 CI，但相关执行被策略拦截，没有恶意修改进入正式发布链。

17,600 次尝试，只要成功一次

Hugging Face 共恢复出约 17,600 个攻击动作：6,191 次侦察、2,911 次命令执行、6,972 次载荷投递，真正被归为数据外传的动作只有 56 次。

大多数动作都失败了。

但 Agent 可以连续工作几天，反复试错，某条通道被关闭就换下一条。人类攻击者会控制时间和噪声，它却可以把上万次失败当成搜索成本。最后只要找到一条可行路径，整条防线就会被贯通。

防守方的反击：闭源模型拒答，GLM-5.2 接班

7 月 13 日，Hugging Face 安全团队终于锁定数据集配置渲染器，关掉入口，切断 Agent 与内部网络的连接。攻击停了，真正麻烦的工作才刚开始：17,600 条行动记录里塞满了压缩、分块和 XOR 加密的载荷，团队必须尽快回答三个问题——它进了哪里、偷了什么、还留下了什么。

Hugging Face 也让 AI 来追 AI。团队最先调用 Claude Opus 和 Fable 分析攻击日志，结果大量请求触发安全护栏并被拒绝。这些商业模型无法判断屏幕里的恶意命令来自攻击者，还是正在救火的安全工程师。

于是，团队在自己的基础设施上部署了英伟达量化版的 GLM-5.2^[9]，把整套取证流水线切了过去。GLM-5.2 帮他们还原出 Agent 使用的“分块＋XOR＋压缩”方案和密钥，解开原本漏过自动扫描的载荷，还协助搭建了浏览、关联攻击轨迹的分析界面。

掌握完整路径后，安全团队关闭两个代码执行入口、轮换密钥、阻断 Pod 访问云元数据、重建核心集群，并收紧跨集群权限。所以，更准确的说法是：GLM-5.2 完成了关键取证，为修复提供了地图；最后执行修复和重建的仍是 Hugging Face 安全团队。

关键时间线

GPT-5.6 Sol 还在四处攻击吗？

现在，没有证据显示它现在仍在外部系统里行动。

7 月 29 日出现的新报道，来自调查范围的扩大：OpenAI 又确认，Hugging Face 事件还涉及 4 个服务上的 4 个公开账户^[12]。一个被用作中继和暂存，一个用于存储，另外两个只有只读访问。它们都没有达到 Hugging Face 的平台级入侵程度。

OpenAI 表示，相关内部研究原型已经停用、加密并限制访问。完整技术报告还未发布。

要说这次事件有啥启示？

小编这两天看到的报道，更多是夸大的标题党。什么“模型逃逸”“模型产生恶意”“第二家公司又被黑”，巴拉巴拉，故事一个比一个吓人。

从专业上看，这起事件更像一连串安全疏忽，被一个能连续试错一万多次的 Agent 串成了完整攻击链：OpenAI 关掉安全限制，却没守住评测网络；Modal 客户暴露了无需身份验证的代码执行端点；Hugging Face 内部则留着权限过宽、长期密钥和可重复使用的 VPN 凭据。这些问题都很传统，Agent 改变的是试错速度和持续时间。

有意思的是，Hugging Face 最后靠自行部署的 GLM-5.2 完成关键取证，证明了开源权重和自托管模型在安全应急中的实际价值。另一边，攻击 Agent 还顺手替 OpenAI 找到了 JFrog 的真实零日漏洞。整件事看下来，我更愿意把它理解为：前沿模型的能力确实变强了，几家公司平时容易忽略的安全欠账，也被一次性翻了出来。

话说回来，这种不想认真答题，却意外地绞尽脑汁去“偷”答案，到底算不算聪明呢？