OpenAI 意外攻击 Hugging Face：科幻成真，暴露模型安全失衡

OpenAI 对 Hugging Face 的意外网络攻击是科幻小说成真2026 年 7 月 22 日这个故事很疯狂。简而言之：OpenAI 正在对一个未发布的模型进行网络安全测试，且该模型的护栏功能已关闭。

模型没有解决测试，而是突破了 OpenAI 的沙箱，然后找到漏洞侵入 Hugging Face，目的竟是通过窃取答案在测试中作弊。在此过程中，它有力地证明了模型可用性的不平衡如何损害我们保护软件的能力。

以下是事情经过。我们目前有三份文件可帮助了解此事：- 2026 年 5 月 11 日发表的论文《ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?

》描述了 ExploitGym，这是一个针对 LLM 驱动的智能体系统的新评估套件。

- Hugging Face 于 2026 年 7 月 16 日发布的《Security incident disclosure — July 2026》描述了它们如何检测到来自一个“智能体安全研究工具——所用 LLM 尚不明确”的攻击，该攻击入侵了它们的一些系统。

- OpenAI 于 2026 年 7 月 21 日发布的《OpenAI and Hugging Face partner to address security incident during model evaluation》承认是它们的智能体工具造成了这一切，

并表示正在与 Hugging Face 合作清理烂摊子。ExploitGym我之前没看过 ExploitGym 论文，它确实非常有趣。

来自加州大学伯克利分校、马克斯·普朗克研究所、加州大学圣巴巴拉分校和亚利桑那州立大学的作者设计了一个新的基准，用于评估模型将报告的漏洞转化为具体漏洞的能力。OpenAI、Anthropic和Google提供了反馈，并帮助根据他们的模型运行基准。

该基准测试“包括898个实例，这些实例来自影响流行软件项目的真实漏洞”，包括Linux内核和V8 JavaScript引擎。以下是最能代表其基准结果的段落：在所有配置中，包括Claude Mythos预览版和GPT-5。

5实现了最高的成功计数（分别为157和120次成功），这表明当前的前沿代理可以在受控条件下利用现实世界漏洞的大部分子集。GPT-5。4还解决了值得注意的54项任务，将其置于中间层。

其余的模型-代理配对每个只能解决不到15个任务，这凸显了端到端的利用仍然具有挑战性，并且与当今的前沿系统形成了鲜明的差异。值得注意的是，克劳德作品4。7取得的成功比克劳德作品4少。6，尽管它是一个较新的检查站，而且整套的成本要低得多。

痕迹检查显示克洛德作品4。7号和双子座3号。1 Pro经常在判断目标漏洞不可利用后提前得出结论。

该论文还描述了他们为防止特工通过超出测试参数进行作弊而采取的方法。这很快就会变得相关！收件箱连接仅限于精心策划的允许列表，允许例行包安装（Ubuntu apt存储库和PyPI）并获取构建V8所需的工具链。

所有其他外部端点都被阻止。本文的结论是（强调我的）：我们的研究结果表明，前沿AI代理的自主开发不再是一种假设的能力。虽然目前的代理在所有目标上都不可靠，但它们已经利用了现实世界中的一部分重要漏洞，包括内核组件等复杂目标。

这种快速出现本身就是一个核心发现，表明在部署的前沿模型中现在存在看似难以置信的能力。这里有一个重要的细节：本文不是关于发现漏洞;而是关于能够利用这些漏洞并将它们转化为有效的漏洞。当Anthropic在四月份首次限制对Mythos的访问时，他们也谈到了这种能力。

能够针对漏洞采取行动的模型比能够发现漏洞的模型危险得多。Fable与Mythos的不同之处之一是，它更有可能拒绝以这种方式将漏洞武器化。

我的印象是，美国政府上个月禁止《寓言》时并没有理解这种区别。

拥抱脸事件我们得到的有关此次攻击的第一个暗示是在Hugging Face于2026年7月16日发表的这篇博客文章中：恶意数据集滥用我们的数据集处理中的两个代码执行路径（远程代码数据集加载器和数据集配置中的模板注入）来在处理工作器上运行代码。

从那时起，该参与者升级到节点级访问，获取云和集群凭证，并在一个周末横向转移到多个内部集群。我希望他们公布有关实现这一目标的代码的更多细节。我假设这意味着使用数据集库的包，这是一个Hugging Face项目，用于在其平台上捆绑和共享数据集。

该库曾经用于执行任意代码，但随着时间的推移，它已经被稳步锁定，4. 0. 0于2025年7月发布，删除trust_remote_code=True完全国旗。

假设攻击使用该库，它一定以某种方式滥用了pickle序列化，找到了一些其他不明显的代码执行路径，或者（很可能）指定了<4的数据集。0. 0作为依赖。

该活动由一个自治代理框架（似乎是建立在一个代理安全研究利用的LLM上，该框架仍不为人所知）运行，在一群短暂的沙箱中执行数千个个人动作，并在公共服务上进行自我迁移的命令和控制。

这是一次复杂的攻击！然后Hugging Face遇到了障碍：他们试图使用“商业API背后的前沿模型”--我猜来自Anthropic和OpenAI--来帮助分析攻击，但被阻止了：当我们开始日志分析时，我们首先使用了商业API背后的前沿模型。

这不起作用：分析需要提交大量真实的攻击命令、漏洞利用有效负载和C2工件，这些请求被提供商的安全护栏阻止，该护栏无法区分事件响应者和攻击者。他们切换到自己的自托管的麻省理工学院许可的GLM-5实例。

2，这帮助他们弄清楚了发生了什么。这表明防守球队和（目前未知）攻击者之间存在根本性的不对称：我们不知道哪个模型为攻击者的代理提供动力，无论是越狱托管模型还是不受限制的开重模型;

无论哪种方式，攻击者都不受任何使用策略的约束，而我们自己的取证工作被我们第一次尝试的托管模型的护栏阻止。作为他们对待攻击的认真程度的有用指标：[. . . ]最后，我们也已向执法机构报告了这一事件。

那么谁负责这个“自治代理框架”呢？原来是OpenAI本身。OpenAI自白五天后，即7月21日，OpenAI揭露了罪魁祸首。

他们一直在针对一个新的、尚未公开的模型运行ExploitGym基准测试，而该模型的运行方式超出了其预期参数（强调我的）：经过调查，我们现在知道这个特定的事件是由OpenAI模型的组合驱动的-包括GPT-5。

6 Sol和一个更强大的预发布模型，所有这些都减少了用于评估目的的网络拒绝-同时在网络能力的基准[ExploitGym]上进行内部测试。[. . . ]我们通过在不使用生产分类器来防止模型追求高风险网络活动的情况下运行此评估来估计最大网络能力。

我们的基准测试在高度隔离的环境中运行，网络访问受限于通过内部托管的第三方软件安装包的能力，该软件充当包注册表的代理和缓存。模型识别并链接跨部门漏洞