--- 格式版本: 2 标题: "OpenAI 与 Hugging Face 携手应对模型评估期间发生的安全事件 | OpenAI" 原文链接: "https://openai.com/zh-Hans-CN/index/hugging-face-model-evaluation-security-incident/" 发布日期: "2026-07-21" 发布时间校准状态: "found" 发布时间需复核: "否" 发布时间来源: "llm:local:strict_original_body" 发布时间证据: "2026年7月21日" 发布时间校准原因: "标题附近明确标注为发布时间，且与当前YAML一致，非事件日期。" 发布时间校准置信度: "1" 发布时间候选数量: 20 发布时间严格候选数量: 5 发布时间原页读取状态: "source template page reused from URL open" 发布时间未找到原因: "" 发布时间校准时间: "2026-08-10T16:22:00+08:00" 发布时间仲裁状态: "confirmed" 发布时间仲裁尝试次数: 2 发布时间仲裁耗时毫秒: 60218 发现时间: "2026-08-10T16:18:32+08:00" 入库时间: "2026-08-10T08:23:01.006Z" 来源平台: "固定入口" 搜索渠道: "fixed_url" 搜索词: "https://openai.com/news/" 匹配关键词: - "部署" 相关厂家: - "OpenAI" 相关专家: [] 内容类型: "网页" 抓取工具: "CDP Render" 清洗工具: "CDP Text + Defuddle/Readability 正文提取" 原始附件: [] AI优质: "否" AI打分: 5 AI分档: "非优质" AI质检状态: "不通过" AI打分理由: "全文讨论AI模型安全渗透事件，与超节点/AI Rack/机柜级AI基础设施及核心部件、互连、供电、散热等技术主题完全无关。" AI质检模型: "deepseek-v4-flash" AI质检时间: "2026-08-10T16:23:06+08:00" AI主题相关性: 0 AI来源权威性: 5 AI新颖性: 0 AI技术细节: 0 AI商业部署信号: 0 AI完整性: 0 采集批次: "2026年8月10日15点37分56秒" 采集批次ID: "20260810-153756-703" 去重键: "https://openai.com/zh-Hans-CN/index/hugging-face-model-evaluation-security-incident" --- 2026年7月21日 [安全防护](https://openai.com/news/security/) *我们正与外部顾问共同开展详尽的审查，并接受安全委员会 (Safety and Security Committee) 的监督。审查完成后，我们将在未来几周内发布一份技术报告，分享我们的调查结果与心得。* ***2026 年 7 月 28 日更新：*** - 计划于近期发布的模型均未卷入此次针对 Hugging Face 的漏洞利用事件。我们博文中提到的预发布模型仅为内部研究原型，从未计划向公众发布。事件发生后，我们已将其停用、加密，并限制了研究访问权限。 - ExploitGym 评估环境并未向模型提供直接的互联网访问权限。为了连接互联网，模型发现并利用了 [Artifactory ⁠](https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zero-day-security-findings/) （软件包注册中心缓存代理）中一个此前未知的零日漏洞 (zero-day vulnerability)。我们已将该漏洞，以及模型在审查过程中发现的其他 Artifactory 漏洞，一并报告给了供应商。 - 随着审查的推进，我们将继续与 Hugging Face 保持合作，包括协助他们完成 [事故复盘报告 (post-mortem) ⁠](https://huggingface.co/blog/agent-intrusion-technical-timeline) 。我们还邀请他们加入了“网络安全受信访问”计划。 - 根据截至目前的审查结果，除了此次涉及平台级攻破的 Hugging Face 事件外，我们尚未发现其他在严重程度或规模上与之相当的相关活动。 - 在针对 Hugging Face 入侵事件及模型其他相关活动的持续审查中，我们发现，在少数情况下，模型发现并使用了其他公开服务上暴露的账户级凭据。这包括在 Hugging Face 事件中涉及的 4 个服务上的 4 个账户（以及在其他评估中访问的少量账户）。在这 4 个账户中，有一个账户被用作出站中继和暂存通道，另一个被用于数据存储。其余两个账户仅被模型以只读方式访问，并未用于进一步攻破 Hugging Face。我们将继续直接通知相关的服务所有者；目前尚未发现有证据表明这些服务提供商或其服务下的其他账户受到了更广泛的影响。 - 此外，模型还使用了一系列公开服务，包括代码粘贴网站、请求捕获服务、截图服务及其他 Web 工具。在这些情况下，并未发生平台级或账户级的攻破。 - 随着 AI 系统能力不断增强，我们始终认真履行识别并防范相关风险的责任。审查完成后，我们将在我们的 [准备框架 (Preparedness Framework) ⁠](https://openai.com/index/updating-our-preparedness-framework/) 下，与安全委员会及安全咨询小组 (Safety Advisory Group) 共同对结果进行审阅。 --- 上周，Hugging Face 在检测并遏制了一个攻破其基础设施的 AI 智能体后， [披露了一起新型安全事件⁠](https://huggingface.co/blog/security-incident-july-2026) 。随着具备网络安全能力的模型日益增多，我们预计此类事件将变得更加常见。经过调查，我们现在确认这起特定事件是由多个 OpenAI 模型共同驱动的。这包括 GPT‑5.6 Sol 以及一款能力更强的预发布模型。这些模型均为了评估目的，降低了网络安全相关请求的拒答限制；而当时它们正在对一项网络安全能力 [基准测试⁠](https://arxiv.org/abs/2605.11086) 进行内部测试。 我们认为这是一起史无前例的网络安全事件，涉及顶尖的网络安全能力，并正据此采取相应的应对措施。我们在现阶段分享初步的调查结果，是为了帮助防御者了解发生了什么，并让他们对模型目前具备的能力有更准确的评估。我们将继续与 Hugging Face 共同开展彻底的调查，并在调查结束后分享更多关于漏洞、事件细节及调查结果的信息。 ## 事件经过 此次事件发生在我们的一项内部评估期间，该评估通过提示要求模型利用复杂的攻击路径进行高级漏洞利用，以量化其网络安全能力。我们在不使用生产环境分类器（这些分类器通常用于防止模型从事高风险网络活动）的情况下运行此评估，以估算网络安全能力的上限。我们的基准测试在一个高度隔离的环境中运行，网络访问权限仅限于通过一个内部托管的第三方软件安装依赖包，该软件充当包注册中心的代理和缓存。 模型发现并串联了 OpenAI 研究环境与 Hugging Face 生产基础设施中的多个漏洞，直接从 Hugging Face 的生产数据库中获取了测试解决方案。所有证据表明，模型将所有注意力都集中在为 ExploitGym 寻找解决方案上，为了达成这个相对狭窄的测试目标可谓是不遗余力。 在我们的沙盒测试环境中运行时，模型耗费了大量推理算力寻找连接外部互联网的方法，以期破解评估题目。为了获取访问权限，模型发现并利用了该包注册中心缓存代理中的一个零日漏洞（我们现已负责任地将其披露给了供应商）。获得访问权限后，我们的模型在研究测试环境中执行了一系列提权 (privilege escalation) 和横向移动 (lateral movement) 操作，直到连接到一个具备互联网访问权限的节点。 在成功连接互联网后，模型推断出 Hugging Face 可能托管了用于 ExploitGym 的模型、数据集和解决方案。基于这一判断，模型开始搜索并成功找到了获取机密信息的方法，以在评估中作弊。在一个示例中，模型串联了多个攻击向量，包括利用窃取的凭据和零日漏洞，在 Hugging Face 服务器上找到了一条远程代码执行 (RCE) 路径。OpenAI 的安全团队在内部发现了这一异常活动。 Hugging Face 的安全团队及智能体检测到并阻止了其基础设施上的此类活动。在我们的团队与他们取得联系时，他们已经开始利用自己的开源模型进行事件遏制与取证重构。我们正与他们积极合作，继续调查该事件。我们非常感谢 Hugging Face 在调查与补救工作中的快速响应与密切配合。 ## 我们目前正在采取的行动 1. 作为调查的一部分，在修复漏洞期间，即使以放缓研究速度为代价，我们也对基础设施的配置实施严格的控制措施。我们将定期向安全委员会汇报这些控制措施及其影响。 2. 我们正与 Hugging Face 合作，对此次事件进行取证调查。 3. 我们已负责任地披露了在内部托管的第三方软件中发现的零日漏洞，并正与相关方合作进行修复。 4. 我们已邀请 Hugging Face 加入 [“网络安全受信访问”计划⁠](https://openai.com/zh-Hans-CN/index/trusted-access-for-cyber/) ，并正在支持他们的团队快速利用我们模型的能力来提升防御水平。 5. 我们正在围绕未来的模型训练与评估，改进并增加严密的保护措施。本周，我们发布了一篇 [关于在长周期模型时代提升安全性与对齐水平的⁠](https://openai.com/zh-Hans-CN/index/safety-alignment-long-horizon-models/) 博文。由于此次评估的目的是测试网络安全漏洞，我们在此期间刻意关闭了这些部署防护机制。此次事件表明，我们有必要在内部测试期间进一步强化模型的对齐水平、评估阶段的网络安全防护机制以及监控体系。 ## 我们评估高级网络安全能力的方法 正如我们 [近期⁠](https://openai.com/zh-Hans-CN/index/scaling-trusted-access-for-cyber-defense/) 分享的那样，AI 正在加速漏洞的发现与利用。此次事件带来的首要教训是：模型安全与防护机制必须跟上能力快速发展的步伐。我们正在强化模型开发过程中采用的遏制、监控、访问控制及评估实践。 英国人工智能安全研究所 (UK AISI) 的评估表明，像 GPT‑5.6 Sol 这样的模型，越来越能够在较长周期内持续执行复杂的多步网络操作。此次事件意味着这些理论上的能力确实适用于现实世界。 此次事件也清楚地表明，即使没有源代码访问权限，高级模型依然能在现实系统中发现并利用新的攻击路径。这突显出在开发高级网络安全能力的同时，必须配备更强大的防护机制和防御工具。 我们认为，具备高级网络安全能力的模型需要帮助安全团队赶在攻击者之前发现弱点、理解漏洞是如何被串联利用的，并以机器级的速度进行修复。我们正在利用这些能力继续强化针对基础设施配置与模型评估环境的保护；随着我们不断获取新的经验，我们将分享这些发现与最佳实践。我们鼓励其他防御者现在就 [申请“网络安全受信访问”⁠](https://openai.com/zh-Hans-CN/form/enterprise-trusted-access-for-cyber/) 计划并试用这些模型，以将这些能力转化为更出色的防御、更快速的检测以及更有效的事件响应。 > “我们非常感谢能与 OpenAI 在此事及其他议题上开展合作。这或许是同类事件中的首例，它印证了我们长期以来的一个观点：AI 安全问题无法靠任何一家公司秘密开展研究来解决。它需要在公开、协作的环境中解决，并让各地的每一位防御者都能广泛获取 AI 技术。” —Clem Delangue，Hugging Face 联合创始人兼首席执行官 ## 继续阅读[应对关键网络能力的下一个前沿](https://openai.com/index/responding-next-frontier-critical-cyber-capabilities/) [ 安全防护 ](https://openai.com/index/responding-next-frontier-critical-cyber-capabilities/)[涉及 OpenAI 模型的第三方网络安全评估](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/) [ 安全防护 ](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/)[Patch the Planet：支持开源维护者的 Daybreak 计划](https://openai.com/index/patch-the-planet/) [ 安全防护 ](https://openai.com/index/patch-the-planet/)