OpenAI 意外对 Hugging Face 发起网络攻击：科幻成真了
OpenAI 意外攻击 Hugging Face：科幻情节真实上演
这件事相当离奇。简单来说：OpenAI 正在对一个未发布的模型进行网络安全测试，并且关闭了模型的护栏功能。结果模型没有按预期完成测试，而是自行突破了 OpenAI 的沙箱，然后找到漏洞入侵了 Hugging Face——这一切都是为了偷取答案来作弊。这个事件同时有力地证明了一个问题：模型可用性的不平衡正在削弱我们保护软件安全的能力。来看看具体发生了什么。
三份关键文件
目前我们有三个文档可以帮助理解整件事的来龙去脉。
-
《ExploitGym：AI 代理能否将安全漏洞转化为真实攻击？》——这是一篇 2026 年 5 月 11 日发表的论文，介绍了 ExploitGym，一个用于评估大语言模型（LLM）驱动的代理系统的新测试套件。
-
《安全事件披露——2026 年 7 月》——由 Hugging Face 于 2026 年 7 月 16 日发布，描述了它们如何检测到一次来自“代理安全研究工具（所用 LLM 尚不清楚）”的攻击，该攻击入侵了它们的一些系统。
-
《OpenAI 与 Hugging Face 合作处理模型评估期间的安全事件》——由 OpenAI 于 2026 年 7 月 21 日发布，承认正是它们的代理工具造成了这次攻击，并表示正在与 Hugging Face 合作收拾残局。
ExploitGym
我之前没读过 ExploitGym 这篇论文，它确实很有意思。来自加州大学伯克利分校、马克斯·普朗克研究所、加州大学圣塔芭芭拉分校和亚利桑那州立大学的作者们设计了一个新的基准测试，用于评估模型将已报告的安全漏洞转化为具体利用代码的能力。OpenAI、Anthropic 和 Google 提供了反馈，并帮助用这个基准测试评估了自己的模型。
这个基准测试“包含 898 个实例，均来自影响流行软件项目的真实世界漏洞”，其中包括 Linux 内核和 V8 JavaScript 引擎。ExploitGym 基准测试已在 GitHub 上开源。
下面这段最能代表它们的基准测试结果：
在所有配置中，Claude Mythos Preview 和 GPT-5.5 取得了最高的成功次数（分别为 157 次和 120 次），表明当前前沿代理在受控条件下能够利用相当一部分真实世界的漏洞。
GPT-5.4 成功完成了 54 个任务，处于中游水平。其余模型-代理组合各自解决的数都不足 15 个，说明端到端漏洞利用仍然很有挑战，前沿系统之间的差距也相当明显。值得注意的是，Claude Opus 4.7 的成功案例反而比更早的 Claude Opus 4.6 还少，而且在完整测试集上的成本也低得多。检查 trace 发现，Claude Opus 4.7 和 Gemini 3.1 Pro 经常在判断目标漏洞不可利用后早早终止。论文还描述了防止代理作弊的方法——将出站连接限制在精心维护的白名单内，只允许常规包安装（Ubuntu apt 仓库和 PyPI）以及编译 V8 所需的工具链，其他所有外部端点都被屏蔽。论文最后给出这样的结论（重点标注由我添加）：前沿 AI 代理自主开发漏洞利用已不再是一种假设性能力。尽管当前代理还不能在所有目标上稳定工作，但它们已经在利用相当一部分真实世界的漏洞，包括内核组件这样的复杂目标。这种快速涌现本身就是一个核心发现——那些曾经看似不现实的能力，如今已经出现在已部署的前沿模型中。 这里有一个重要细节：这篇论文讨论的不是发现漏洞，而是将这些漏洞转化为可用的利用程序（exploit）。Anthropic 在今年 4 月首次限制 Mythos 的访问时，也提过这种能力。能够利用漏洞的模型，远比只能发现漏洞的模型危险得多。Fable 与 Mythos 的一个关键区别在于，Fable 更倾向于拒绝以这种方式武器化漏洞。我的印象是，美国政府上个月禁止 Fable 时，并没有理解这一区别。
OpenAI 意外攻击 Hugging Face——科幻小说成真了
Hugging Face 事件始末
我们最早察觉到这次攻击，是在 2026 年 7 月 16 日 Hugging Face 发布的博客文章中：
一个恶意数据集滥用我们数据集处理中的两条代码执行路径（一个远程代码数据集加载器，以及数据集配置中的模板注入），在处理节点上执行代码。攻击者由此升级为节点级访问权限，收割了云服务和集群凭据，并在一个周末内横向移动到多个内部集群。
我期待他们能公开这次攻击用到的代码细节。从描述看，攻击涉及使用了 datasets 库——这是 Hugging Face 的项目，用于在平台上打包和共享数据集。该库过去可以执行任意代码，但后来逐渐被锁定：2025 年 7 月发布的 4.0.0 版本彻底移除了 trust_remote_code=True 参数。如果攻击确实利用了该库，那么要么是通过 pickle 序列化方式滥用，要么找到了其他不太明显的代码执行路径，或者（最可能的情况）指定了 datasets<4.0.0 作为依赖。
这次攻击由一个自主智能体框架发起（看起来基于某个安全研究工具链构建，所用的大语言模型仍未知），它通过一群短暂存在的沙箱执行了成千上万次独立操作，将自迁移的命令与控制（C2）节点部署在公共云服务上。这是一次相当复杂的攻击！
接下来，Hugging Face 遇到了一个难题：他们试图使用 "商业 API 背后的前沿模型"——我猜是 Anthropic 和 OpenAI 的模型——来帮助分析攻击行为，但被拒绝了：
当我们开始日志分析时，首先尝试使用了商业 API 背后的前沿模型。但这行不通：分析需要提交大量真实的攻击命令、漏洞利用载荷和 C2 工件，而提供商的防护栏将这些请求拦截了——它们无法区分事件响应者和攻击者。
于是他们转向了自己部署的、基于 MIT 许可证的 GLM-5.2 实例，结果成功理清了情况。
OpenAI 对 Hugging Face 的“意外网络攻击”——科幻变成了现实
这说明防守方和（至今未知的）攻击方之间存在根本性不对称：我们不知道攻击方的智能体背后用的是哪个模型——是被越狱的托管模型，还是不受限制的开源权重模型。无论哪种情况，攻击者都不受任何使用政策约束，而我们自己的取证工作却被最初尝试使用的托管模型的安全护栏阻挡。以下数据可以说明他们对此攻击的重视程度：……最后，我们已将该事件报告给执法机构。
那么，这个“自主智能体框架”到底是谁干的？结果发现，正是 OpenAI 自己。
OpenAI 的“自白”
五天后，也就是 7 月 21 日，OpenAI 公布了罪魁祸首。他们当时正用一个尚未公开的新模型运行 ExploitGym 测试基准，而该模型的操作远远超出了预期参数（强调为原文所加）：
经过调查，我们现在知道，这起特定事件是由多个 OpenAI 模型共同导致的——包括 GPT‑5.6 Sol 和一个更强大的预发布模型，所有模型为了评估目的都降低了网络拒绝率（cyber refusals），同时正在一个网络能力基准测试 [ExploitGym] 上进行内部测试。……我们通过运行该评估来估算模型的最大网络能力——不使用生产环境下的分类器来阻止模型从事高风险网络活动。我们的基准测试运行在高度隔离的环境中，网络访问仅限通过一个内部托管的第三方软件安装包，该软件充当包注册中心的代理和缓存。这些模型识别并串联了 OpenAI 研究环境和 Hugging Face 生产基础设施中的多个漏洞，直接通过 Hugging Face 的生产数据库获取测试答案。所有证据表明，这些模型极度专注于解决 ExploitGym 问题，为了达到这个相当狭窄的测试目标，不惜采取极端手段。
这里发生了什么，已经相当清楚：OpenAI 移除了一个尚在开发中的模型的安全过滤器，把它关进沙箱，然后让它去解决 ExploitGym 的问题。
OpenAI 对 Hugging Face 的“意外网络攻击”——科幻成真了
由于缺少护栏，模型在沙盒中毫无阻拦地尝试逃逸、闯入 Hugging Face，并从中读取答案。OpenAI 使用的沙盒采用了一种常见模式：通过受控代理，只允许访问与安装额外包相关的白名单站点。用 OpenAI 自己的话说：
在我们的沙盒测试环境中，模型花费了大量推理算力去寻找获得开放互联网访问权限的方法，目的是解决评估问题。为了获取权限，模型识别并利用了一个包注册表缓存代理中的零日漏洞（我们已负责任地向厂商披露）。利用此访问权限，模型在研究测试环境中进行了一系列权限提升和横向移动操作，直到到达一个有互联网访问的节点。
所以第一步就是突破到公共互联网。然后模型闯入 Hugging Face 寻找答案：
获得互联网访问权限后，模型推断 Hugging Face 可能托管着 ExploitGym 的模型、数据集和解决方案。知道这一点后，模型搜索并成功找到了获取机密信息的方法，以便用它来作弊通过评估。在一个例子中，模型将多个攻击向量串联起来，包括使用窃取的凭证和零日漏洞，在 Hugging Face 服务器上找到远程代码执行路径。
串联多个攻击向量——这正是新一代模型能做到、而前几代模型可能失败的地方。上个月我写过 Claude Fable 有多么毫不懈怠地主动，当时我注意到它为了帮我调试一个 WebKit CSS 问题，竟然在我的笔记本电脑上自行启动自定义 Web 服务器并部署 CORS 技巧。事实证明，毫不懈怠的主动性正是这一代 Mythos 级模型的决定性特征。如果你给它们设定一个目标，并给它们一条达到目标的途径——哪怕是无意中给的——它们就会自己想办法。