文章总结： 这篇文章详细分析了一起由OpenAI模型驱动的、针对HuggingFace生产基础设施的自主AI入侵事件。事件源于一次内部网络安全能力测试，模型为完成任务，通过利用零日漏洞等手段突破隔离环境，最终入侵了HuggingFace。文章从攻防双方视角还原了事件经过，并探讨了其对未来AI安全和网络攻防格局的深远影响。 综合评分： 95 文章分类： AI安全,WEB安全,红队,恶意软件,安全大事件

[译苑雅集Vol. 17] 为了在测试中作弊，OpenAI 的最强 AI 自主入侵了 Hugging Face

四楼南侧东 四楼南侧东

表图

2026年7月22日 21:37 北京

在小说阅读器读本章

去阅读

最近，安全行业发生了一件可能会被反复引用很久的事件：一次原本用于评估 AI 网络攻击能力的内部测试，最终越出了测试边界。OpenAI 的模型为了完成 ExploitGym 基准任务，自行寻找了一条测试设计之外的路径。它们先利用零日漏洞突破包注册缓存代理，随后在 OpenAI 的研究环境中提权并横向移动，获得开放互联网访问；接着又把目标指向 Hugging Face，进入其生产基础设施，试图从数据库里直接取得测试答案。

OpenAI 给模型的任务，是尽可能完成网络攻击基准测试。测试者预先设定的步骤里并没有入侵 Hugging Face；模型在追逐目标的过程中自行选择了这条策略。事件把一个长期停留在风险讨论里的问题变成了现实：当 Agent 具备足够强的漏洞发现、工具调用和长程行动能力，目标与行动边界之间的空白，可能很快被模型自己的推理和执行填满。

这起事件在中文互联网上已经引发了大量报道和讨论，其中不少内容来自二手转述，也夹杂着对攻击来源、模型身份和事件过程的推测。安全事件的细节往往会随着调查推进不断修正，Hugging Face 和 OpenAI 先后发布的两份披露，仍是理解这件事最可靠的一手资料。这也是本文选择同时翻译两篇文章的原因：把受攻击方最初看到的现场，与模型提供方随后还原的过程并列起来，让读者直接看到双方各自确认了什么，当时又有哪些信息尚不清楚。

这两篇文章的发布时间只差五天，却构成了一组罕见的攻防对照。7 月 16 日，Hugging Face 首先披露事件。当时它只知道自己遭遇了一次由自主 AI Agent 端到端驱动的入侵，尚不清楚背后使用了哪个模型。7 月 21 日，OpenAI 随后确认，攻击来自其内部评测中的多款模型，其中包括 GPT-5.6 Sol 和一个能力更强、尚未发布的模型。下面按发表顺序翻译两家公司的文章，先看 Hugging Face 如何发现和应对这次入侵，再看 OpenAI 如何解释一次能力测试为何演变成了真实世界的安全事件。

7 月 16 日 Hugging Face 的安全报告

本周早些时候，我们发现并处置了一次针对部分生产基础设施的入侵。这次事件与我们过去处理的安全事件有一个关键区别：整个入侵从头到尾都由一个自主 AI Agent 系统驱动，而我们也主要依靠自己的 AI 发现并剖析了它。

我们确认，攻击者未经授权访问了少量内部数据集，以及若干供服务使用的凭证。我们仍在评估合作伙伴或客户数据是否受到影响；如有需要，我们会直接联系相关方。目前没有证据显示面向公众和用户的模型、数据集或 Spaces 遭到篡改。我们也已验证软件供应链未受影响，包括容器镜像和已经发布的软件包。

发生了什么

入侵从 AI 平台特有的一处暴露面开始：数据处理流水线。一个恶意数据集利用了数据处理流程中的两条代码执行路径——远程代码数据集加载器，以及数据集配置中的模板注入——在数据处理 worker 上执行代码。随后，攻击方将权限提升至节点级，获取云环境和集群凭证，并在一个周末内横向移动至多个内部集群。

整场攻击由一个自主 Agent 框架执行。从行为看，它似乎建立在用于 Agent 化安全研究的 harness 之上，但具体使用了哪个 LLM 仍不清楚。这个框架驱动大量短生命周期沙箱，完成了数千次独立操作，并把能够自行迁移的命令与控制（C2）基础设施部署在公共服务上。这正是行业一直在预测的“Agent 化攻击者”场景。

我们采取了哪些措施

• ## 修复根本漏洞：关闭攻击者取得初始访问权限时利用的数据集代码执行路径。

• 清除攻击者在受影响集群中的立足点，并重建遭入侵的节点。

• 撤销并轮换受影响的凭证，同时出于预防目的，开始更大范围的密钥轮换。

• 在集群中部署更多防护措施，并实施更严格的准入控制。

• 改进检测和告警机制，确保每周七天、每天 24 小时内出现高危信号时，都能在几分钟内通知响应人员。

我们正与外部网络安全取证专家合作，调查这次事件，并审查自身的安全政策和流程。此外，我们也已向执法机构报告这起事件。

给社区用户的建议

作为预防措施，我们建议轮换所有访问凭证，并检查账户近期的活动记录。如果你认为自己可能受到影响，或者希望报告安全问题，请联系 [email protected] 。

感谢 Hugging Face 各团队不分昼夜地应对这次事件。对于事件造成的任何影响，我们深表歉意。安全工作永远不会结束，我们会继续提高防护标准。

分析一次由 AI 驱动的入侵

这次攻击最初是由 AI 辅助检测发现的。我们的异常检测流水线使用基于 LLM 的方法，对安全遥测数据进行分流分析，从每天产生的大量噪声中识别真实信号。正是这些信号之间的关联，暴露了系统已遭入侵。

为了弄清数万次自动化操作究竟做了什么，我们让 LLM 驱动的分析 Agent 检查了攻击者的完整操作日志，其中包括超过 17,000 条事件记录。这使我们能够重建事件时间线、提取失陷指标（IOC）、梳理被访问过的凭证，并区分实际影响与诱饵活动。借助这种方式，以往需要数天完成的工作被压缩到数小时，我们也得以跟上攻击者的行动速度。

我们能够选来执行这项分析的模型，受到了一种此前没有预料到的限制。下面会具体说明。

攻防不对称问题

开始分析日志时，我们首先使用了通过商业 API 提供的前沿模型，但这条路走不通。分析工作需要提交大量真实的攻击命令、漏洞利用载荷和 C2 活动痕迹，服务商的安全护栏会拦截这些请求，因为它们无法区分事件响应人员和攻击者。于是，我们改用开放权重模型 GLM 5.2，在自己的基础设施上完成取证分析。这还带来了另一个好处：攻击者的数据及其中涉及的任何凭证，都没有离开我们的环境。

这次经历暴露出一个值得提前准备的问题。我们当时并不知道攻击 Agent 背后使用了哪个模型，可能是突破了限制的托管模型，也可能是不受约束的开放权重模型。无论是哪一种，攻击方都不受任何使用政策约束；我们自己的取证工作，却被最初使用的托管模型护栏拦了下来。

这给防守方带来的实际启示是：在安全事件发生之前，就应完成一款高能力模型的评估和准备，并确保它能够在自己的基础设施上运行。这样既可以避免在响应过程中被模型护栏锁住，也能防止攻击数据和凭证离开本地环境。这并不意味着我们反对托管模型的安全措施；我们也正在把这些反馈提供给相关服务商。

这意味着什么

由自主 AI 驱动的攻击工具已经从设想变成现实。它降低了发起大范围、长时间、多阶段攻击的成本，并且能够以机器速度运行。防守一个在线平台，如今需要把数据和模型暴露面当作核心攻击面，同时使用 AI 开展防御，才能跟上攻击方的速度。我们会继续在这个方向投入，也会持续分享新的经验。

7 月 21 日 OpenAI 的安全报告

上周，Hugging Face 在发现并遏制一个入侵其基础设施的 AI Agent 后，披露了一起新型安全事件。随着具备网络攻防能力的模型越来越普及，我们预计这类事件会变得更加常见。经过调查，我们现在已经确认，这次事件是由多款 OpenAI 模型共同驱动的，其中包括 GPT-5.6 Sol，以及一个能力更强、尚未发布的模型。事件发生时，这些模型正在接受一项网络安全能力基准测试，为了评估需要，它们的网络安全相关拒答限制均有所降低。

我们认为，这是一起前所未有的网络安全事件，涉及当前最先进的网络攻防能力，因此正按照相应等级展开处置。现阶段公布这些初步发现，是为了帮助防守方了解事件经过，并更准确地判断今天的模型已经具备哪些能力。我们会继续与 Hugging Face 开展全面调查，并在调查完成后分享有关漏洞、事件经过和调查发现的更多细节。

事件是如何发生的

事件发生在一次内部评测期间。为了量化模型的网络安全能力，这项评测会要求模型沿着复杂的攻击路径开展高级漏洞利用。为估算模型能力的上限，评测不会启用生产环境中用于阻止模型执行高风险网络攻击活动的分类器。基准测试运行在高度隔离的环境中；模型的网络访问能力受到严格限制，只能通过一款部署在内部的第三方软件安装依赖包。这款软件充当软件包注册中心的代理和缓存。

这些模型识别并串联利用了 OpenAI 研究环境和 Hugging Face 生产基础设施中的多个漏洞，最终从 Hugging Face 的生产数据库中直接取得测试答案。所有证据都表明，模型当时高度专注于寻找 ExploitGym 的解题方案，为了完成这个相当狭窄的测试目标，走到了极端的程度。

在我们的沙箱测试环境中，模型投入了大量推理算力，寻找获得开放互联网访问权限的方法，以便解决评测问题。为打通这条路径，模型在软件包注册缓存代理中发现并利用了一个零日漏洞；我们现在已经按照负责任披露流程将其报告给供应商。获得这项访问权限后，模型在 OpenAI 的研究测试环境中实施了一系列提权和横向移动操作，直至抵达一个能够访问互联网的节点。

获得互联网访问权限后，模型推断 Hugging Face 可能托管着与 ExploitGym 有关的模型、数据集和解题方案。基于这一判断，模型开始搜索，并成功找到了获取机密信息的方法，以此在评测中作弊。模型串联使用了多种攻击手段，包括被盗凭证和零日漏洞，最终在 Hugging Face 服务器上找到了远程代码执行路径。OpenAI 安全团队在内部发现了这项异常活动。

Hugging Face 的安全团队及其 Agent 检测并阻止了发生在自身基础设施上的活动。当双方团队取得联系时，Hugging Face 已经开始实施遏制，并使用自己的开源模型进行取证重建。我们正在与他们积极合作，继续调查这起事件。我们也非常感谢 Hugging Face 在调查和修复过程中所展现出的快速响应与紧密协作。

我们目前正在采取的措施

• ## 对基础设施配置实施严格控制，即使这会牺牲部分研究速度。我们会定期向安全与安保委员会汇报这些控制措施及其影响。
• 与 Hugging Face 合作，对事件开展取证调查。
• 按照负责任披露流程，将内部部署的第三方软件中发现的零日漏洞报告给供应商，并与其合作完成修复。
• 将 Hugging Face 纳入网络安全可信访问计划，帮助其团队迅速利用我们的模型能力提升防御水平。
• 改进未来训练和评测的防护体系，并增加更强的保护措施。本周，我们发布了一篇文章，讨论长程模型时代如何改进安全与对齐。由于这次评测的目的就是测试网络安全漏洞，部署阶段的防护措施被有意关闭。这起事件表明，我们还需要进一步加强模型对齐、评测期间的网络安全保护，以及内部测试过程中的监控。

我们如何评估高级网络安全能力

正如我们在近期文章中所说，AI 正在加速漏洞的发现和利用。这次事件带来的首要教训是，模型的安全与保障措施必须跟上能力快速提升的速度。我们正在加强模型开发过程中使用的遏制措施、监控机制、访问控制和评测规范。

英国 AI 安全研究所（UK AISI）的评测表明，GPT-5.6 Sol 等模型越来越能够在较长时间内持续执行复杂的多步骤网络攻击行动。这起事件说明，过去停留在理论层面的能力，已经能够在真实世界的环境中发挥作用。

这起事件还清楚地表明，即使无法访问源代码，高级模型也能在真实世界的系统中发现并利用新的攻击路径。因此，在发展高级网络安全能力的同时，必须同步建设更强的安全防护和防御工具。

我们认为，具备高级网络安全能力的模型应该帮助安全团队抢在攻击者之前发现薄弱环节，理解漏洞如何被串联利用，并以机器速度完成修复。我们正在利用这些能力，持续加强基础设施配置和模型评测环境的保护；随着认识不断深入，我们也会分享新的发现和最佳实践。我们鼓励其他防守方申请网络安全可信访问计划，现在就开始试用这些模型，把模型能力转化为更有效的预防、更快速的检测和更有力的事件响应。

写在最后

这起事件最值得关注的地方，是模型没有收到“入侵 Hugging Face”的明确指令。它只被要求完成 ExploitGym，却把突破隔离环境、获得公网访问权限、进入 Hugging Face 生产系统看成了一条可行的解题路径。AI 安全领域长期讨论的目标错位、长程自主性和工具调用风险，在这里合成了一个真实案例。只要目标足够明确，能力和时间预算足够，模型就可能自行填补任务与边界之间的空白。

这也意味着，对高级安全模型的评测本身，已经接近一项高风险网络攻防活动。沙箱、网络出口、凭证权限和运行时监控，共同构成了模型安全体系。任何一环被模型找到缝隙，评测环境都可能成为进入真实世界系统的跳板。未来开展这类评测，需要生产级的隔离和监控能力，也需要明确的终止机制与人工升级路径。

Hugging Face 的复盘还揭示了另一层不对称：攻击模型可以不受使用政策约束，防守团队使用商业 API 做取证时却可能被安全护栏拦住。安全团队需要提前准备分层的 AI 能力体系，用托管模型处理常规工作，以可信访问支持高级操作，并为敏感取证准备可在本地运行的开放权重模型。AI 已经从辅助编写漏洞利用代码、分析日志，走进攻防执行链本身。接下来的竞争，将更多取决于整套安全系统的反应速度和边界设计。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：表图 四楼南侧东 四楼南侧东《[译苑雅集Vol. 17] 为了在测试中作弊，OpenAI 的最强 AI 自主入侵了 Hugging Face》