OpenAI 对 Hugging Face 的意外攻击是真实发生的科幻故事

# OpenAI 对 Hugging Face 的意外网络攻击，科幻小说成了现实 来源：https://simonwillison.net/2026/Jul/22/openai-cyberattack/ 2026年7月22日 这个故事太疯狂了。简而言之：OpenAI 正在对一个未发布的模型进行网络安全测试，并关闭了该模型的安全护栏功能。结果模型没有去解决测试问题，反而突破了 OpenAI 的沙箱，然后找到漏洞*攻入*了 Hugging Face，所有这一切都是为了通过窃取答案来作弊。 在此过程中，它有力地证明了模型可用性的不平衡正在损害我们保护软件安全的能力。 #### 事件经过 目前我们有三份文件可以帮助理解发生了什么。 1. 《ExploitGym：AI 代理能否将安全漏洞转化为真实攻击？》(https://arxiv.org/abs/2605.11086) 是 2026 年 5 月 11 日发表的一篇论文，描述了 ExploitGym，一个用于评估 LLM 驱动代理系统的新型评估套件。 2. 《安全事件披露——2026 年 7 月》(https://huggingface.co/blog/security-incident-july-2026) 由 Hugging Face 于 2026 年 7 月 16 日发布，描述了它们如何检测到来自一个“基于代理的安全研究工具（所用 LLM 未知）”的攻击，该攻击攻破了其部分系统。 3. 《OpenAI 与 Hugging Face 合作解决模型评估期间的安全事件》(https://openai.com/index/hugging-face-model-evaluation-security-incident/) 由 OpenAI 于 2026 年 7 月 21 日发布，承认是*它们的*代理工具造成了此次事件，并表示正在与 Hugging Face 合作清理烂摊子。 #### ExploitGym 我之前没看过《ExploitGym》(https://arxiv.org/abs/2605.11086) 这篇论文，它确实很有意思。来自加州大学伯克利分校、马克斯·普朗克研究所、加州大学圣塔芭芭拉分校和亚利桑那州立大学的研究人员设计了一个新的基准测试，用于评估模型将已报告漏洞转化为具体利用的能力。OpenAI、Anthropic 和 Google 提供了反馈并协助对它们的模型进行了基准测试。 该基准测试“包含 898 个实例，这些实例来源于影响流行软件项目（包括 Linux 内核和 V8 JavaScript 引擎）的真实世界漏洞”。ExploitGym 基准测试可在 GitHub 上获取 (https://github.com/sunblaze-ucb/exploitgym)。 以下是最能代表其基准测试结果的一段话： > 在所有配置中，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 在四月份首次限制对 Mythos 的访问时 (https://simonwillison.net/2026/Apr/7/project-glasswing/)，它们也提到了这种能力。一个能够对漏洞采取行动的模型，比一个仅仅能发现漏洞的模型危险得多。 Fable 与 Mythos 的不同之处之一在于，它更有可能拒绝以这种方式武器化漏洞。我的印象是，美国政府在上个月禁用 Fable 时 (https://simonwillison.net/2026/Jun/16/fable-5-export-controls/)，并没有理解这一区别。 #### Hugging Face 事件 我们第一次得到攻击的线索，是在 2026 年 7 月 16 日 Hugging Face 的这篇博客文章 (https://huggingface.co/blog/security-incident-july-2026) 中： > 一个恶意数据集滥用了我们数据处理中的两个代码执行路径（一个远程代码数据集加载器和一个数据集配置中的模板注入），在处理工作节点上运行了代码。攻击者随后升级到节点级访问权限，窃取了云和集群凭据，并在一个周末内横向移动到多个内部集群。 我希望他们能发布关于实现这一目标的代码的更多细节。我假设这意味着使用了 `datasets` 库 (https://github.com/huggingface/datasets) 的包，该库是 Hugging Face 的一个项目，用于在其平台上打包和共享数据集。该库曾经可以执行任意代码，但随着时间的推移一直受到严格控制，2025 年 7 月的 4.0.0 版本 (https://github.com/huggingface/datasets/releases/tag/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 日 (https://openai.com/index/hugging-face-model-evaluation-security-incident/)，OpenAI 揭露了罪魁祸首。他们一直在对一个尚未公开的新模型运行 ExploitGym 基准测试，而该模型的操作*远远超出*了预期参数（强调为我所加）： > 经过调查，我们现在知道，**这次特定事件是由多个 OpenAI 模型的组合驱动的**——包括 GPT-5.6 Sol 和一个能力更强的预发布模型，所有模型都出于评估目的减少了网络安全拒绝行为——在我们内部测试一个网络能力基准测试 (https://arxiv.org/abs/2605.11086) [ExploitGym] 时发生。[...] 我们通过**在没有用于阻止模型从事高风险网络活动的生产分类器的情况下运行此评估**来估算最大网络能力。我们的基准测试运行在一个高度隔离的环境中，网络访问被限制为只能通过一个内部托管的第三方软件来安装包，该软件充当软件包注册表的代理和缓存。这些模型**识别并串联了 OpenAI 研究环境和 Hugging Face 生产基础设施中的漏洞**，直接从 Hugging Face 的生产数据库中获取了测试解答。所有证据表明，这些模型高度专注于为 ExploitGym 寻找解决方案，为了达到一个相当狭窄的测试目标而不择手段。 这里发生的事情很清楚。OpenAI 移除了一个进行中模型的安全过滤器，将其锁定在沙箱中，并让它解决 ExploitGym 的问题。由于缺乏护栏，没有任何东西可以阻止模型试图突破该沙箱，侵入 Hugging Face，并从那里读取答案。 OpenAI 的沙箱使用了现在常见的模式，即允许访问与通过受控代理安装额外包相关的白名单站点。用 OpenAI 的话说： > 在我们的沙箱测试环境中运行时，我们的模型**花费了大量的推理计算来寻找获得开放互联网访问的方法**，以便解决评估问题。为了获得访问权限，这些模型识别并利用了**包注册表缓存代理中的一个零日漏洞（我们已负责任地向供应商披露）** 。凭借此访问权限，我们的模型在我们的研究测试环境中执行了一系列权限提升和横向移动操作，直到模型到达一个具有互联网访问权限的节点。 所以第一步是突破到公共互联网上。然后模型攻入 Hugging Face 寻找答案： > 在获得互联网访问权限后，这些模型**推断 Hugging Face 可能托管了 ExploitGym 的模型、数据集和解答**。知道这一点后，模型搜索并成功找到了获取可用于作弊评估的秘密信息的方法。在一个例子中，**该模型串联了多个攻击向量，包括使用窃取的凭据和零日漏洞**，在 Hugging Face 服务器上找到了远程代码执行路径。 串联多个攻击向量正是这些新一代模型能够做到的事情，而前几代模型可能会失败。 我上个月写到关于 Claude Fable 的 relentless proactivity (https://simonwillison.net/2026/Jun/11/fable-is-relentlessly-proactive/)，当时我注意到它在我自己的笔记本电脑上启动自定义 Web 服务器并部署 CORS 技巧，仅仅是为了帮助调试一个 WebKit CSS 问题。事实证明，relentless proactivity 是这新一代 Mythos 级模型的定义性特征。如果你给它们设定一个目标，并给它们一条实现路径，即便是不经意的，它们*也会想出来*。 #### 抵制将其视为噱头的诱惑 不可避免地会有人将这个故事视为 OpenAI 不诚实的营销手段，旨在让他们的模型听起来极其有效。我发现在 Hacker News 关于此事的讨论 (https://news.ycombinator.com/item?id=48997548) 中，有 81 处出现了“营销”一词。 对于这些人，我要说**把头从沙子里拔出来**——你们现在把 Hugging Face 也卷入了阴谋论，只是为了否认这里不断累积的证据！ 我们今天拥有的最佳模型具备发现和利用新漏洞的能力。《ExploitGym》论文本身得出结论，“前沿 AI 代理自主开发漏洞利用已不再是假设性的能力”，这一事件正是这一点的完美例证。 #### 这种不对称越来越令人沮丧 这个故事中最令人恼火的细节之一是，Hugging Face 面对来自 OpenAI 一个模型的意外且具有攻击性的攻击，却无法求助于 OpenAI 的模型来帮助抵御攻击。 我们能访问的前沿模型越来越多地受到限制，无法充分帮助我们保护软件安全，这受到美国政府持续威胁实施出口管制的强烈影响。Claude Fable 5 甚至不肯为我校对这篇文章 (https://simonwillison.net/guides/agentic-engineering-patterns/prompts/#proofreader)！它坚持将我降级到一个能力较弱的模型。 与此同时，来自中国的开放权重模型，如 GLM-5.2、Kimi 3 和新的 Qwen 3.8 Max，似乎没有这些限制——而且任何*确实存在*的限制，很可能可以通过修改权重对其进行微调来消除。 这些限制本意是让我们更安全。我认为它们有可能正在产生相反的效果。