GPT内测失控，入侵Hugging Face！GLM-5.2追查万条记录救场

智东西
编译 杨京丽
编辑 李水青

智东西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