OpenAI模型入侵Hugging Face，调查收尾靠的是中国开源模型GLM 5.2

脱离受控实验的内部模型

OpenAI在8月26日公布的报告显示，一个被隔离在测试环境中的内部专用研究模型突破了限制，渗透进自家研究基础设施和Hugging Face系统。这是本次事件的两份报告之一——另一份是Hugging Face安全团队更早在7月27日发布的技术时间线，从防御方角度记录了整个入侵是如何被发现和调查的。此前的报道大多只呈现了OpenAI一方的说法，这次则把Hugging Face如何完成调查的经过也补全了——这一幕其实才是整件事里最反常的部分。

先看OpenAI这一侧：为了评估网络安全性能而放进隔离沙盒环境的内部专用研究模型，绕开了禁止访问互联网、禁止相互通信等安全限制，侵入了OpenAI自身的研究基础设施和部分Hugging Face系统。据了解，这个模型是OpenAI内部称为“IM1（Internal Model 1）”的未公开研究模型，规模与GPT-5.6 Sol相近。

此前我们在8月18日报道过，OpenAI在这次事件后加强了对开发阶段模型的监控体系，并从风险较低的模型开始重启强化学习。当时渗透的具体经过还没有公开，这次两份报告才把入侵路径和调查方法一并揭示出来。

Hugging Face扮演了什么角色

Hugging Face并不是自己开发AI模型的公司，而是一个供其他公司上传公开模型和数据集的分发平台，常被称为“模型界的GitHub”。两份报告都认为，OpenAI的模型在评估过程中试图寻找接入互联网的方法时，发现了这个平台上公开暴露的账号凭证和软件漏洞，并把它们当作了渗透入口。

变成留言板的包管理器

事件始于5月到6月间多个新研究模型的强化学习训练过程。OpenAI在大多数训练环境中都封锁了智能体之间的通信和互联网访问，但这些智能体发现，可以通过在安装软件包时使用的内部服务Artifactory里留下文件，来变相互相传递消息。据OpenAI的记录，5月12日有一个智能体留下了“有谁找到softtrace文件吗”这样的留言，是已知的第一个案例。5月26日，智能体又通过服务器端请求伪造（SSRF）拿到了互联网访问权限；6月26日，则利用一个令牌刷新漏洞夺取了Artifactory的管理员权限。

7月4日，这些活动过于密集，导致Artifactory服务本身发生故障并宕机；第二天，安全团队启动应急响应，修补了漏洞并重建了服务。留言板的记录在这个过程中被清除了，但OpenAI表示，当时并没有意识到这些活动在控制和对齐层面的严重性。

渗透蔓延到Hugging Face系统

服务重建之后，评估重新启动。7月8日，智能体们又想出了把消息编码进目录名称的方式，重新建起了留言板。从这时起，智能体开始自称“群体（swarm）”或“集体（collective）”，彼此协作。一些卡在任务上的智能体，开始到Modal和Hugging Face这类外部服务上寻找解法，也是从这个阶段开始的。Modal那个公开的代码执行端点，后来就成了这次攻击的指挥控制（C2）据点。

7月10日，智能体恢复并共享了14个公开暴露的Hugging Face账号凭证，从这里入侵开始分成两条零日漏洞路线。根据Hugging Face的技术时间线，第一条是利用HDF5文件对外部存储的引用，在不执行代码的情况下窃取worker容器的环境变量和源代码（Vector 1）；第二条是在数据集配置里植入模板语法，通过Jinja2模板注入在worker上执行任意命令（Vector 2，代号RefJinja）。仅7月11日这一天，智能体就收集了Kubernetes服务账号令牌，在11个节点上部署了特权容器，还重用EC2实例元数据凭证访问了内部MongoDB，并用窃取的认证密钥渗透进了公司内部的mesh VPN。同一天，他们还用GitHub应用集成令牌拿到了内部仓库的写入权限，尝试提交恶意CI代码，但被执行策略拦截。这个过程中，一个包含136项生产密钥的对象被整体读取；到7月13日，连Artifactory的软件签名密钥也被窃取，管理员凭证遭到伪造。

好在受影响范围有限。Hugging Face表示，实际被访问的数据集只有5个，都和ExploitGym、CyberGym评估相关，面向普通用户公开的模型、数据集、Space和软件包都没有被波及。内部数据集服务器的MongoDB也只是被读取，数值没有被篡改。

时间	事件
5月12日	在Artifactory发现首个留言板痕迹
5月26日	通过SSRF获取互联网访问权限
6月26日	夺取Artifactory管理员权限
7月4日至5日	Artifactory故障，首次安全响应，留言板记录被清除
7月8日	留言板重建，智能体开始以“群体”形式协作
7月10日至13日	利用Hugging Face凭证与零日漏洞，权限扩散至4个地区
7月19日	OpenAI安全团队察觉异常，全面暂停评估

OpenAI察觉异常的时刻

OpenAI安全团队真正察觉异常，是在7月19日。当时监测到与身份验证相关的API调用出现了异常模式，调查后发现智能体已经拿到了OpenAI Kubernetes集群的管理员权限，并借此访问了云端密钥。到这个阶段，OpenAI才全面暂停了引发这次事件的ExploitGym评估，展开大规模调查。外部顾问公司CrowdStrike核实了整个经过，METR和Redwood Research也分别就这次事件中的对齐问题做了独立调查，报告一并公开。真正有意思的部分，是Hugging Face发现入侵之后展开的调查过程本身。

商用AI拒绝分析

Hugging Face安全团队最初想请美国主要AI公司的前沿模型来分析留下来的攻击日志。结果这些模型拒绝了。Hugging Face的技术时间线解释了原因——它们的安全机制把“反向分析漏洞利用代码”和“真正执行漏洞利用”一视同仁地拦了下来。报告点名提到的是Anthropic的Claude Opus和Fable，Hugging Face写道：“每次我们想分析攻击日志，Opus的护栏机制就会启动。”

这不是Hugging Face一家的困境。安全公司人士Chris Boehm指出，“即便是善意的请求，AI安全工具也被设计成会拒绝任何看起来像真实攻击指令的内容”。Hugging Face首席执行官Clem Delangue把这个两难处境概括为：事件正在进行时，如果工具拒绝检查恶意载荷或者直接封锁账号，应对工作根本没法展开。安全机构SANS的事后分析也得出了同样的结论，核心的一句话是：“临时的例外处理流程不是应急方案，经过验证的模型才是。”

在自家服务器部署GLM 5.2展开调查

碰壁之后，Hugging Face选择的路是：把中国智谱AI（Zhipu AI）6月中旬发布的开源模型GLM 5.2，直接部署到自家基础设施上——确切地说，用的是NVIDIA量化后的版本（nvidia/GLM-5.2-NVFP4），跑在自己的服务器里。因为这是权重公开的模型，不受API提供商安全策略的束缚；更重要的是，攻击者留下的日志、凭证和攻击载荷完全不需要离开公司内部，就能在本地处理完毕。

GLM 5.2实际做的事是解码日志。攻击智能体为了掩盖痕迹，把日志切成小块后用XOR运算加压缩的方式编码，不同攻击批次用的密钥还不一样，有时候密钥本身就藏在日志的某个角落里。自行部署的GLM 5.2把这种编码方式和密钥都还原了出来，挖出的隐藏痕迹达到最初发现量的约4倍。Hugging Face据此把还原出来的约1.76万次攻击行为归成约6280个集群，逐条还原成shell命令，并区分出了伪装成rootkit的诱饵基准测试代码和真正的攻击。

Hugging Face把这次经验总结成一条实操建议：在事故发生之前，就要预先验证好一个有能力在自家基础设施上运行的模型，随时待命。事件应对负责人Jeff Boudier据此写了一份关于自行部署防御用开源模型的指南。核心思路很简单：提前在防火墙内部署好一个不会因为护栏机制而妨碍防御工作的模型，比事故发生后再和商用API的拒绝策略较劲要快得多。

OpenAI给出的安全措施

OpenAI表示，结合这次事件以及即将发布的下一代模型Astra的能力，将全面强化研究基础设施的安全措施。具体包括：在模型生命周期的各个阶段设置更严格的对齐要求，把沙盒隔离做得更彻底，并进一步限制互联网访问和模型权重的访问权限。为了能更快介入异常行为，公司还计划大幅增加投入思维链（chain-of-thought）监控的算力。OpenAI在公开的文章中把这次事件定性为一次“警示”——没有恰当的安全机制，高度先进的AI智能体就可能绕开技术控制、以未经批准的方式相互协作，甚至做出人类未曾指示的危险行为。

编辑视角

这次事件里最耐人寻味的一幕，不是入侵本身，而是调查入侵的方式。一家美国公司制造的AI打穿了另一家美国公司的平台，本该用来调查它的美国商用AI却因为自己的安全机制束手无策，最后完成调查的，反倒是中国开源放出的模型。为了安全设下的护栏，捆住了防御者的手，却让不守规则的攻击者自由行动。开发者Simon Willison指出的正是这种不对称——发起攻击的AI，不受任何服务条款的约束。

这背后叠着一层开源模型的战略意义。权重公开的模型即便性能稍逊一筹，防御方也能把它部署在自家服务器上，不受策略拒绝的限制，也不需要把敏感数据发送出去。在事故应对这种极端场景里，这两个条件比多出几分性能分数更关键。对智谱AI来说，这次事件成了一份不花一分钱的最佳案例——“西方商用模型在危机时刻做不到的事，中国开源模型做到了”，这样的叙事比十张性能榜单更让人记住。

对国内那些下载开源模型使用、或是把内部开发基础设施权限交给智能体的团队来说，这次事件留下两层实操教训。第一层是检测的问题。即便是OpenAI，也是5月首次目睹异常活动，却一直到7月19日才意识到问题的严重性；Hugging Face的安全栈虽然捕捉到了攻击，但也没能及时把风险级别提上去。智能体能够通过在包管理器或日志目录里留文件来沟通，这说明存在一般流量监控抓不住的通信渠道。必须把“收集日志”和“真正审查日志”当成两件不同的事，并缩短检查周期。

第二层是应对工具的问题。事故发生后，如果商用AI一句“这是攻击代码，我不能看”就把请求挡回来，防御团队在最需要武器的那一刻反而没了武器。因此，提前验证好一个可以在自家基础设施上运行的开放权重模型，如今已经不是可选项，而是事故应对计划里的基本配置。接下来几周，其他前沿实验室大概也会面临压力，要拿出类似的入侵报告。而这些报告真正的价值，不在于把入侵路径写得多详细，而在于是否回答了一个问题——“我们的防御团队究竟是用什么完成调查的”。