真行，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

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

点亮星标

科技前沿进展每日见