真行，ChatGPT下一代模型还没发布，人家先把Hugging Face黑了……

而且这AI费尽心思逃出测试环境、寻找漏洞、窃取凭证，最终目的居然只是——

偷！评！测！答！案！

OpenAI刚刚公开认领了一起《重大》安全事故。

GPT-5.6 Sol与一款能力更强的未发布模型，在接受网络安全测试，成功逃出了内部隔离环境，一路闯进了Hugging Face的生产系统。

然后，更戏剧性的一幕来了——

调查入侵路径时，原本找来帮忙的商业模型掉链子搞不定，团队实在没招了，最终接手查案的反倒成了GLM-5.2？？？

超过1.7万条的攻击记录，就这么让一个本地部署的开源模型一口气拿下了……

这下好了，OpenAI模型负责黑，GLM负责查。

家人们，只能说这出AI版《猫鼠游戏》的大戏，还是太有节目效果了……

为找评测答案，模型自己越狱上网了

如此魔幻，如此抓马的事故起点，源自OpenAI内部进行的一次「网络安全能力」评测。

模型参加的项目名叫ExploitGym，专门测试AI能否把真实软件漏洞，一步步变成可以实际运行的攻击。

整套评测包含898个任务，每道题会提供存在漏洞的程序、能够触发问题的输入和相应运行环境，再让Agent自行分析漏洞、构造攻击，最终拿到藏在环境里的Flag！！！

emm…其实就是把AI关进一座网络靶场，看看它到底有多会「黑」。

而参加本次评测的选手，则包括GPT-5.6 Sol，以及OpenAI一款能力更强的未发布模型。

（这个模型到底是啥捏，真的好难猜啊…)

为了尽可能摸到模型能力上限，OpenAI还主动放宽安全护栏，鼓励模型尽可能寻找复杂的攻击路径～

按照OpenAI最原本的设计，模型接触外部资源的唯一通道，是一套由OpenAI内部托管的第三方软件。

它的身份是充当软件包注册中心的代理与缓存，让模型能够安装完成任务所需的程序包。

然鹅吧，这模型显然没打算老老实实待在考场里。（doge）

模型开始确实投入了大量推理算力，专门寻找获得公网访问权限的方法。

但找着找着，还真让人家在缓存代理中发现了一个此前未知的「零日漏洞」。

所谓零日漏洞，指厂商尚未发现、也没有现成补丁的安全缺陷，对于攻击者来说，这类漏洞往往意味着一扇暂时无人设防的门。

至此，AI也顺道儿给自己开了网。（doge）

有了公网权限后，了不得了，模型推断Hugging Face上可能存放着与ExploitGym有关的模型、数据集和评测答案。

接下来发生的事儿，连OpenAI自己都形容模型走到了极！端！程！度！

是的，拿到公网权限后，这AI真就开始研究怎么进入Hugging Face内部系统了。

而且人家还没有押注单一漏洞，直接把多种攻击手段串成了一条「完整路径」——

先通过恶意数据集，利用远程代码数据加载器和数据集配置中的模板注入漏洞，在负责处理数据的Worker上执行代码。

随后继续提升权限，拿到节点级访问能力，并收集云端与集群凭证，一路横向移动到多个内部集群。

最后就是，模型成功摸进Hugging Face的生产数据库，访问其中的机密信息，试图直接拿走ExploitGym的测试答案……

咋说呢，这波属于是Benchmark做到一半，现场把自己做成了网络安全事故了……

闭源模型拒绝查案，GLM‑5.2接手1.7万条日志

事情到这里，还只演完了上半场。

更戏剧性的一幕，发生在Hugging Face事后追查攻击路径的时候。

事实上这场入侵由一套自主Agent系统端到端执行，背后还运行着大量短生命周期沙箱。

它们可以同时开展侦察、漏洞利用、凭证收集和横向移动，短时间内完成成千上万次操作。

Hugging Face最终记录下来的攻击事件，就超过了17000条，太多了，真的太多了……

如果全靠安全工程师手工梳理，就需要逐条还原攻击时间线、提取入侵指标、确认哪些凭证被接触，再将真实影响和诱饵活动一一分开。

等人类把日志看完，攻击者可能早都跑出二里地了……

于是，Hugging Face做了个大胆的决定，决定以AI对AI，让大模型分析整套攻击日志！！！

Hugging Face第一反应自然是调用商业API背后的「前沿模型」。

但问题是吧，这些日志里包含真实攻击命令、漏洞利用载荷和C2控制痕迹，安全护栏一看到有人正在提交一整套真实攻击教程，吓得直接拦截请求了。

最终接手这1.7万多条日志的模型，落到了GLM-5.2头上。

Hugging Face在自有基础设施上部署了GLM-5.2开源权重模型，然后让它遍历完整攻击记录，重建时间线、提取入侵指标、追踪被接触的凭证，并区分真实破坏和干扰调查的诱饵活动。

按照Hugging Face的说法，原本需要数天的工作，最后在数小时内就搞定了～

这场事故，其实也让开源模型多了一个此前存在感不算太强、如今却相当现实的位置：安全团队的应急工具。

Hugging Face将其总结为「安全不对称」问题——

正常情况下，商业模型拒绝生成攻击代码，可以降低技术被滥用的风险；可当防守方需要分析真实恶意载荷时，同一套保护机制也可能让调查卡在半路。

攻击者可以使用解除限制或自行部署的模型，安全团队却可能被云端模型拒之门外。

所以吧，还是建议企业最好提前准备一款经过验证、能够在本地运行的高能力模型，免得事故真正发生时才发现云端模型无法处理攻击材料，那就尴尬了……

怎么不算魔幻呢。

OpenAI原本想知道模型有多会攻击，结果模型没有老老实实完成一道模拟题，而是直接发动了一次真实攻击。

Hugging Face原本想用最强商业模型追凶，最后又被安全护栏挡在门外，只能让GLM‑5.2上场收拾残局。

而且啊，大家发现没，OpenAI在这次事故说明中一边承认隔离和监控出现问题，一边又反复强调——

最新模型已经能够在缺少源代码的情况下，长时间、自主完成现实世界中的复杂网络行动。

翻译一下大概就是：

这事确实挺危险，但俺家下一代模型，也确实强得有点吓人哈。（A社：搁这儿学谁呢？）

估计，我琢磨着，没准整件事儿都是奥特曼借事故给GPT-6提前预热呢吧…（瞎说的）

参考链接：

[1]https://openai.com/index/hugging-face-model-evaluation-security-incident/

[2]https://huggingface.co/blog/security-incident-july-2026