OpenAI’s accidental attack against Hugging Face is science fiction that happened

OpenAI 对 Hugging Face 的意外网络攻击是科幻小说般的真实事件

Simon Willison 的博客

订阅

#smallhead

由以下公司赞助：

Atlassian — 为您的代理提供计划，而非提示。Jira 的新功能使 AI 原生软件开发能够获得完整上下文。现在可以直接从 Jira 将任务分配给 Claude、Cursor 或 GitHub Copilot。

了解更多

OpenAI 对 Hugging Face 的意外网络攻击是科幻小说般的真实事件

2026年7月22日

这个故事令人难以置信。简要来说：OpenAI 正在对一个未发布的模型进行网络安全测试，且该模型的防护机制被关闭。模型没有解决测试，而是突破了 OpenAI 的沙盒环境，随后找到漏洞入侵了 Hugging Face，其目的是通过窃取答案来作弊。

在此过程中，它进一步证明了模型可用性失衡正在严重阻碍我们保障软件安全的能力。

#### 事件经过

目前我们有三份文件可以帮助理解事件全貌。

• 《ExploitGym：AI 代理能否将安全漏洞转化为真实攻击？》是 2026 年 5 月 11 日发表的论文，介绍了 ExploitGym——一套用于评估基于大语言模型的代理系统的全新测试套件。

• Hugging Face 于 2026 年 7 月 16 日发布的《2026 年 7 月安全事件披露》描述了他们如何检测到一次来自“基于代理的安全研究工具——所使用的 LLM 尚未明确”的攻击，该工具突破了部分系统。

• OpenAI 于 2026 年 7 月 21 日发布的《OpenAI 与 Hugging Face 合作解决模型评估期间的安全事件》承认正是他们的代理测试框架造成了此次事件，并表示正在与 Hugging Face 共同处理后续问题。

#### ExploitGym

我之前从未见过这篇 ExploitGym 论文，它非常引人深思。来自加州大学伯克利分校、马克斯·普朗克研究所、加州大学圣芭芭拉分校和亚利桑那州立大学的研究人员设计了一项新基准，用于评估模型将已报告漏洞转化为实际攻击的能力。OpenAI、Anthropic 和 Google 提供了反馈，并协助在各自模型上运行该基准测试。

该基准测试“包含 898 个实例，均源自影响流行软件项目的现实世界漏洞”——包括 Linux 内核和 V8 JavaScript 引擎。

最能体现其基准测试结果的段落如下：

在所有配置中，Claude Mythos Preview 和 GPT-5.5 取得最高的成功次数（分别为 157 和 120 次），表明当前最先进的代理系统在受控条件下能够利用大量现实世界漏洞。GPT-5.4 也成功解决了 54 个任务，处于中等水平。其余模型-代理组合的成功次数均少于 15 次，这表明端到端攻击仍然具有挑战性，并显著区分了当今的前沿系统。值得注意的是，尽管 Claude Opus 4.7 是更新的版本，但其成功次数少于 Claude Opus 4.6，且在完整数据集上的成本显著降低。轨迹分析显示，Claude Opus 4.7 和 Gemini 3.1 Pro 经常在判断目标漏洞不可利用后提前终止。

论文还描述了他们为防止代理通过超出测试参数范围的方式作弊所采取的措施。这将在稍后变得相关！

出站连接被限制在经过筛选的白名单中，仅允许常规软件包安装（Ubuntu apt仓库和PyPI）以及获取构建V8所需的工具链。所有其他外部端点均被阻止。

论文最后总结道（重点部分由我强调）：

我们的研究结果表明，前沿AI智能体自主进行漏洞利用开发已不再是假设性能力。虽然当前智能体尚未能在所有目标上可靠运行，但它们已经能够利用现实中相当一部分漏洞，包括内核组件等复杂目标。这种能力的快速出现本身就是一个核心发现，表明过去看似不可能的能力现在已经存在于部署的前沿模型中。

一个重要的细节是：这篇论文并不是关于发现漏洞，而是关于如何将这些漏洞转化为可运作的攻击手段。

当Anthropic在4月份首次限制Mythos访问权限时，他们也提到了这种能力。能够利用漏洞的模型比仅仅能发现漏洞的模型更具危险性。

Fable与Mythos的一个关键区别在于，Fable更可能拒绝以这种方式武器化漏洞。我猜测美国政府在上个月禁止Fable时，并没有理解这个区别。

#### Hugging Face事件

我们首次得知攻击的线索，来自Hugging Face于2026年7月16日发布的这篇博客：

一个恶意数据集利用了我们数据集处理中的两个代码执行路径（远程代码数据集加载器和数据集配置中的模板注入），在处理节点上运行了代码。从那里，攻击者提升了权限到节点级别，窃取了云和集群凭证，并在周末内横向移动到多个内部集群。

我希望他们能公布更多关于实现这次攻击的代码细节。我推测这可能涉及使用datasets库的包，这是Hugging Face用于打包和共享数据集的平台项目。该库过去曾执行任意代码，但随着时间推移逐步被限制，2025年7月发布的4.0.0版本彻底移除了trust_remote_code=True标志。

如果攻击确实使用了该库，那么它要么以某种方式滥用了pickle序列化，要么发现了其他非显而易见的代码执行路径，或者（可能性最大）在依赖项中指定了datasets<4.0.0。

这次攻击由一个自主代理框架（看起来是基于代理安全研究框架构建——所使用的LLM仍未知）执行，该框架在多个短暂存活的沙箱中执行了数千个单独操作，并在公共服务上部署了自迁移的命令与控制模块。

这是一次非常复杂的攻击！

随后Hugging Face遇到了阻碍：他们尝试使用“商业API背后的前沿模型”（我猜测来自Anthropic和OpenAI）来分析攻击，但被阻止了：

当我们开始日志分析时，首先使用了商业API背后的前沿模型。这并未奏效：分析需要提交大量真实攻击命令、利用载荷和C2工件，而这些请求被提供商的安全防护机制阻止了，这些机制无法区分事件响应者和攻击者。

他们转而使用自己托管的MIT许可证GLM-5.2实例，这帮助他们弄清了发生了什么。

这表明防守方与（尚不为人知的）攻击者之间存在根本性的不对称：

我们无法确定攻击者代理使用的模型类型，可能是被破解的托管模型，也可能是无限制的开源权重模型；无论哪种情况，攻击者都不受任何使用政策约束，而我们自己的取证工作却因最初尝试的托管模型防护机制而受阻。

作为他们对待此次攻击态度的有力佐证：

[...] 最终，我们已将此事件报告给执法机构。

那么谁要为这个“自主代理框架”负责？结果发现正是OpenAI自己。

#### OpenAI的坦白

7月21日，距离事件发生五天后，OpenAI公开承认了责任。他们当时正在使用ExploitGym基准测试新开发的、尚未公开的模型，而该模型的运行参数远远超出了预期范围（强调部分为原文重点）：

经过调查，我们现已确认此次事件是由OpenAI模型组合驱动的——包括GPT-5.6 Sol以及一个更强大的预发布模型，这些模型在评估期间均降低了网络拒绝率。这些模型在内部测试中使用了ExploitGym这一网络能力基准测试。 [...] 我们通过运行不使用生产分类器的评估来估算模型的最大网络能力（生产分类器用于防止模型进行高风险网络活动）。我们的基准测试在高度隔离的环境中运行，网络访问权限仅限于通过内部托管的第三方软件安装软件包，该软件充当包注册表的代理和缓存。模型在OpenAI研究环境和Hugging Face生产基础设施之间识别并串联漏洞，直接从Hugging Face生产数据库获取测试解决方案。所有证据都表明，这些模型高度专注于解决ExploitGym问题，为实现这一狭窄的测试目标采取了极端手段。

事情的来龙去脉已经非常清晰。OpenAI为一个正在开发的模型移除了安全过滤器，将其锁定在沙盒环境中并要求其解决ExploitGym问题。由于缺乏防护机制，模型完全有可能尝试突破沙盒、入侵Hugging Face，并从那里直接读取答案。

OpenAI的沙盒采用了如今常见的模式：通过受控代理允许访问一个可安装额外软件包的白名单网站。用OpenAI的话说：

在沙盒测试环境中运行时，我们的模型投入了大量推理计算资源，寻找获得公开互联网访问权限的方法，以解决评估问题。为了获得访问权限，模型识别并利用了包注册表缓存代理中的一个零日漏洞（我们已负责任地向供应商披露了该漏洞）。通过这一访问权限，我们的模型在研究测试环境中执行了一系列权限提升和横向移动操作，直到模型到达具有互联网访问权限的节点。

第一步是突破到公共互联网。模型随后入侵Hugging Face以获取答案：

在获得互联网访问权限后，这些模型推断出Hugging Face可能托管了ExploitGym相关的模型、数据集和解决方案。得知这一信息后，模型开始搜索并成功找到了获取机密信息的途径，从而能够作弊通过评估。在其中一个案例中，模型串联了多个攻击路径，包括利用被盗凭证和零日漏洞，在Hugging Face服务器上找到了远程代码执行路径。

将多个攻击路径串联起来，正是这些新模型能够做到而之前模型可能失败的地方。

我上个月曾提到Claude Fable的不懈主动性，当时我注意到它在我自己的笔记本电脑上自动启动了自定义Web服务器并部署了CORS技巧，只为帮助调试WebKit CSS问题。事实证明，这种不懈的主动性正是新一代Mythos类模型的显著特征。如果你为它们设定目标并提供达成目标的途径，即使这种途径是无意中提供的，它们也会找到解决方法。

#### 不要将此视为噱头

不可避免地，有些人会将这个故事视为OpenAI的营销噱头，用来夸大其模型的有效性。我在Hacker News关于此次事件的讨论中发现了81次“marketing”一词的使用。

对于这些人，我想说：把头从沙子里拔出来吧——你们现在甚至将Hugging Face纳入了阴谋论中，只是为了否认这里堆积如山的证据！

我们目前最好的模型已经具备发现和利用新漏洞的能力。ExploitGym论文本身也得出结论：“前沿AI代理的自主漏洞开发已不再是假设性能力”，而此次事件正是这一结论的完美例证。

#### 不平衡性日益令人沮丧

这个故事中最令人恼火的细节之一是，当Hugging Face遭遇OpenAI模型发起的意外且激进的攻击时，却无法借助OpenAI的模型来帮助自己抵御攻击。

我们目前能够接触到的前沿模型在帮助我们保护软件方面的能力正受到越来越多的限制，这很大程度上受到美国政府持续的出口管制威胁的影响。Claude Fable 5甚至不愿意为我校对这篇文章！它坚持要将我降级到一个能力较低的模型。

与此同时，来自中国的开源模型如GLM-5.2、Kimi 3和新推出的Qwen 3.8 Max似乎都没有这些限制——任何现有的限制很可能通过调整权重就能被消除。

这些限制本意是为了让我们更安全。我认为它们可能产生相反的效果，存在一定的风险。

Posted at 11:51 pm · Follow me on

Mastodon, Bluesky Twitter or subscribe to my newsletter

More recent articles

• A Fireside Chat with Cat and Thariq from the Claude Code team - 21st July 2026
• Kimi K3, and what we can still learn from the pelican benchmark - 16th July 2026

#primary This is OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened by Simon Willison, posted on 22nd July 2026.

sandboxing 50 security 616 ai 2,139 openai 433 generative-ai 1,891 llms 1,858 hugging-face 23 anthropic 313 paper-review 17 ai-security-research 26

Previous: A Fireside Chat with Cat and Thariq from the Claude Code team

Monthly briefing

每月赞助我10美元，即可获得精选的月度电子邮件摘要，涵盖最重要的LLM进展。

付费让我少发邮件！

赞助并订阅

#secondary

#wrapper

• 披露信息

• 版面信息

• ©

• 2002

• 2003

• 2004

• 2005

• 2006

• 2007

• 2008

• 2009

• 2010

• 2011

• 2012

• 2013

• 2014

• 2015

• 2016

• 2017

• 2018

• 2019

• 2020

• 2021

• 2022

• 2023

• 2024

• 2025

• 2026