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

今天要聊的这件事，确实值得仔细看看。7月22日凌晨，OpenAI自己承认，包括

在内的多款自家模型，在内部网络安全评测中利用漏洞突破了隔离环境，进而，还拿到了评测答案。OpenAI把这起事件定性为，涉及当前最先进的网络攻击能力。

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

其实早在7月16日，Hugging Face就已经披露了这起由自主AI Agent驱动的入侵事件。当时在取证过程中，Hugging Face最初尝试用商业前沿模型来分析，但没想到，真实的攻击命令和漏洞载荷触发了这些模型的安全护栏。于是，Hugging Face干脆在自己的基础设施上部署了智谱的旗舰模型

，用来分析记录事件，把原本需要。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事后还原发现，攻击是从一个恶意数据集开始的：这个数据集利用远程代码加载器和数据集配置模板，注入了两条代码执行路径，在数据处理节点上运行代码。之后，模型取得了节点级权限，提取了云端和集群凭证，并横向进入多个内部集群，

。

7月16日，Hugging Face称，公司在当周早些时候，通过

发现了攻击，其安全团队及Agent随后阻止了相关活动。今天，OpenAI进一步确认，这起事件是由包括在内的多款自家模型引发的。

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

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

1）

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

2）

：继续与Hugging Face合作，对事件进行取证分析。

3）

：向内部软件包缓存袋里的第三方供应商披露漏洞，并与对方共同修补。

4）

：将其纳入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处理了

，负责还原攻击时间线、提取入侵指标、梳理被访问的凭证，并区分真实影响与诱饵活动，把通常需要。

很有意思的是，Hugging Face最初尝试调用商业API背后的前沿模型，但真实攻击命令、漏洞载荷和C2

。相关系统无法区分安全响应人员和攻击者，分析请求因此受阻。于是，Hugging Face随后在自有基础设施上运行了来完成取证，同时确保攻击数据和相关凭证不离开内部环境。

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

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

Hugging Face选择GLM-5.2，首先是因为它采用

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

其次，GLM-5.2拥有

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

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