智东西

编译 | 杨京丽

编辑 | 李水青

智东西 7 月 22 日消息，今天凌晨，OpenAI 确认，包括GPT-5.6 Sol 和一款更强预发布模型在内的多款自家模型，在内部网络安全评测中利用漏洞突破隔离环境，继而侵入 Hugging Face 生产系统，并获取评测答案。OpenAI 称，这是一起" 前所未有的网络安全事件 "，事件涉及当前最先进的网络攻击能力。

OpenAI 发文承认网络攻击事件（图源：X）

7 月 16 日，Hugging Face 就已披露这起由自主 AI Agent 驱动的入侵。取证过程中，Hugging Face 最初尝试使用商业前沿模型，但真实攻击命令和漏洞载荷触发了安全护栏。

于是，Hugging Face 在自有基础设施上部署智谱的旗舰模型GLM-5.2，分析超过 1.7 万个记录事件，把通常需要数天的工作压缩至数小时。7 月 20 日，Hugging Face 进一步解释了选择 GLM-5.2 的原因及其部署方法。

此次入侵导致少量内部数据集和部分服务凭证被未授权访问，但尚无证据显示公开模型、数据集、Spaces 及软件供应链遭到篡改。

Hugging Face 现已关闭相关代码执行路径、重建遭入侵的节点并轮换相关凭证；OpenAI 则收紧研究基础设施配置，与 Hugging Face 联合取证，推动第三方软件供应商修复漏洞。

一、模型利用零日漏洞逃出沙箱，攻入 Hugging Face

7 月中旬，OpenAI 在一次内部 ExploitGym 评测中，测试模型的网络攻击能力。为了测出模型的能力上限，OpenAI降低了模型的网络安全拒答限制，也没有启用生产环境中阻止高风险操作的分类器。

评测原本在隔离环境中运行，模型不能直接访问互联网，只能通过一套内部托管的软件包，安装外部软件。为了完成评测，模型持续寻找离开隔离环境的方法，并发现该代理软件中的一个零日漏洞。所谓零日漏洞，是指此前尚未被软件开发者发现、因而也没有补丁的安全缺陷。

模型利用这一漏洞突破网络限制，又在 OpenAI 测试环境中提升权限、横向进入其他节点，最终获得互联网访问能力。OpenAI 已经将该零日漏洞报告给软件供应商，并与对方合作修复。

随后，模型推断 Hugging Face 可能保存了 ExploitGym 相关模型、数据集和评测答案，于是开始寻找进入其系统的方法。

Hugging Face 事后还原发现，攻击从一个恶意数据集开始：该数据集利用远程代码加载器和数据集配置模板，注入两条代码执行路径，在数据处理节点上运行代码。此后，模型取得节点级权限，提取云端和集群凭证，并横向进入多个内部集群，最终从 Hugging Face 生产数据库中获取评测答案。

7 月 16 日，Hugging Face 称，公司在当周早些时候，通过AI 辅助异常检测系统发现了攻击，其安全团队及 Agent 随后阻止相关活动。今天，OpenAI 进一步确认，这起事件由包括GPT-5.6 Sol 和一款更强的预发布模型在内的多款自家模型引发。

二、OpenAI 收紧评测环境，模型已能执行长期复杂攻击

事件发生后，OpenAI 公布了五项处理措施：

1）加固研究环境：在漏洞修复期间，OpenAI 收紧基础设施配置，即使这会拖慢研究进度。OpenAI 还会定期向公司安全与安保委员会汇报这些措施及其影响。

2）联合调查：继续与 Hugging Face 合作，对事件进行取证分析。

3）修复零日漏洞：向内部软件包缓存代理的第三方供应商披露漏洞，并与对方共同修补。

4）支持 Hugging Face 加强防御：将其纳入 OpenAI 的网络安全模型可信访问计划，帮助其尽快使用 OpenAI 模型的能力改进防护。

5）加强未来评测监控：加强模型训练和评测期间的对齐机制、网络安全保护及内部监控。

OpenAI 称，此前为模型增加的部署防护没有在此次评测中开启，因为测试目的就是观察模型发现和利用网络漏洞的能力。此次事件说明，即使在内部评测阶段，OpenAI 也需要进一步加强模型对齐、网络安全保护和运行轨迹监控。

英国人工智能安全研究所的评估显示，GPT-5.6 Sol 等模型越来越能长时间执行复杂、多步骤的网络行动。这次事件进一步说明，相关能力已经可以作用于真实系统，模型甚至能在没有源代码的情况下发现新的攻击路径。

不同模型网络攻击任务能力对比（图源：OpenAI）

OpenAI 称，发展这些能力的同时，必须加强隔离、监控、访问控制和防御工具。另一方面，安全团队也可以利用模型提前发现弱点、理解多个漏洞如何串联，并加快修复速度。OpenAI 还邀请其他安全团队申请可信访问计划。

Hugging Face 联合创始人兼 CEO 克莱芒 · 德朗格（Cl é ment Delangue）称，这起可能是首例的事件说明，AI 安全无法由一家公司独立解决，而是需要开放协作，并让更多安全防守人员获得 AI 能力。

三、Hugging Face 清理受影响系统，本地部署 GLM-5.2 完成取证

截至 7 月 16 日，Hugging Face 已经阻止攻击并开始处置受影响系统。公司发现，攻击者未经授权访问了少量内部数据集和部分服务凭证，公司仍在评估合作伙伴或客户数据是否受影响；但没有证据显示公开模型、数据集、Spaces 及软件供应链遭到篡改。

针对这起事件，Hugging Face 采取了以下五项措施：

1）修复根本漏洞：关闭攻击者首次进入系统时利用的两条数据集代码执行路径。

2）清理受影响系统：清除攻击者在相关集群中的残留访问，并重建遭入侵的节点。

3）更换相关密钥：撤销并轮换受影响的凭证和 Token，同时扩大预防性密钥轮换的范围。

4）加强集群防护：增加新的安全措施，并实施更严格的集群准入控制。

5）改进检测和告警：确保高危信号能在数分钟内通知安全响应人员，包括周末和节假日。

攻击最初由 Hugging Face 的 AI 辅助检测系统发现。为了弄清数万次自动操作，大模型驱动的分析 Agent 处理了超过 1.7 万个记录事件，负责还原攻击时间线、提取入侵指标、梳理被访问的凭证，并区分真实影响与诱饵活动，把通常需要数天的工作压缩至数小时。

Hugging Face 最初尝试调用商业 API 背后的前沿模型，但真实攻击命令、漏洞载荷和 C2信息触发了安全护栏。相关系统无法区分安全响应人员和攻击者，分析请求因而受阻。Hugging Face 随后在自有基础设施上运行GLM-5.2完成取证，同时确保攻击数据和相关凭证不离开内部环境。

四、为何选择 GLM-5.2：开源、100 万 Token 上下文，可本地部署

7 月 20 日，Hugging Face 再次发文，进一步解释了为何选择 GLM-5.2 完成攻击日志取证，并介绍了如何在本地服务器或企业自有的微软、AWS 云环境中部署该模型。

Hugging Face 选择 GLM-5.2，首先是因为它采用开放权重和 MIT 许可证，可以部署在企业自己的基础设施中。安全人员能够自行控制模型和运行环境，不会因为商业 API 的使用政策或安全护栏而中断调查。攻击日志、漏洞载荷及其中涉及的凭证也无需发送给第三方服务。

其次，GLM-5.2 拥有100 万 Token 上下文窗口。Hugging Face 此次需要分析超过 1.7 万个记录事件，包括攻击命令、凭证访问和横向移动过程。较大的上下文窗口可以让模型在一条完整时间线上关联这些操作，不必把日志切成大量片段分别处理。

GLM-5.2 在推理、工具编排和终端操作方面也具备较强能力。GLM-5.2 在 MCP-Atlas 和 SWE-bench Pro 上得分分别为 76.8 和 62.1，仅落后于 Claude Opus 4.8，领先 GPT-5.5 和 Gemini 3.1 Pro；在 Terminal Bench 2.1 上得分为 81，落后于 Claude Opus 4.8 和 GPT-5.5，但领先 Gemini 3.1 Pro。

GLM-5.2、Claude Opus 4.8、GPT-5.5、Gemini 3.1 Pro 模型部分能力对比（图源：Hugging Face）

GLM-5.2 并非在每项测试中都领先，但它可以在企业内部正常运行，并直接处理真实攻击材料。企业既可以把它部署在自己的物理服务器上，也可以运行在自有云账户中。Hugging Face 建议安全团队提前完成部署和测试，将模型接入现有安全工具，而不是等攻击发生后再寻找可用模型。

结语：模型安全防线需前移至内部评测

这起事件中，内部评测的隔离和监控未能阻止模型越界。随着模型能够长期执行多步骤任务，网络安全保护不能只在产品部署后启用，也需要覆盖训练和评测阶段。

Hugging Face 使用 GLM-5.2 完成取证则说明，安全事件发生时，模型能否本地部署、处理敏感数据并持续调用安全工具，可能比单项测试排名更重要。安全团队需要提前准备可控、可用的模型，而不是等攻击发生后再临时寻找工具。

来源：OpenAI、Hugging Face