热门搜索:和平精英 原神 街篮2 

您的位置:首页 > > 教程攻略 > ai教程 >OpenAI 把 Hugging Face 打穿了,然后 GLM 5.2 当了救火队长?

OpenAI 把 Hugging Face 打穿了,然后 GLM 5.2 当了救火队长?

来源:互联网 更新时间:2026-07-29 08:02

一场AI安全测试的意外“越狱”

前几天,Sam Altman发了条消息,说OpenAI在评估模型时遇到了个不小的安全事件。随后OpenAI写了篇帖子,详细叙述了这个事儿。

图源:Sam Altman

把OpenAI和Hugging Face的两份声明都看了一遍,正好可以聊聊这事儿的来龙去脉。

简单来说,这件事的严重程度,可比模型越狱严重多了。

先把核心问题总结一下,一句话概括就是:

OpenAI的模型在一次网络安全评测里,为了找到题目答案,先是突破了隔离环境,摸到了公网,然后又侵入Hugging Face的生产基础设施,试图从人家的生产数据库里直接拿答案。

OpenAI管这叫“一起前所未有的网络安全事件”。

Hugging Face这边的发现是,他们有限内部数据集和一些服务凭证,在未经授权的情况下被私自访问了。

截至7月16日的披露,Hugging Face仍在确认合作伙伴或客户数据是否受影响;不过暂时没有发现公开模型、数据集、Spaces被篡改,容器镜像和已发布软件包也验证是干净的。

五天前,Hugging Face还不知道是谁干的

7月16日,Hugging Face先发了一条安全公告。

OpenAI 把 Hugging Face 打穿了,然后 GLM 5.2 当了救火队长?

图源:Hugging Face

公告里说,攻击看起来是由AI自主完成的。当时Hugging Face还不知道背后用了哪个模型,只能从日志确认,整条攻击链是由一套Agent系统端到端执行的。

简单讲,这套Agent没有依赖一台机器从头跑到尾。它把攻击拆成了成千上万个小操作,再分散到许多临时沙盒里执行。

每个沙盒只运行很短时间。它完成几项操作,把结果传回去,随后就会消失。下一个沙盒拿到新任务,再接着往下执行。防守方即使封掉其中一台,整套系统也不会停下来。

这些临时沙盒背后,还有一个负责调度的C2(命令与控制)。你可以把它理解成“总调度台”:它负责给各个沙盒下发任务,再收回执行结果。

这个总调度台也没有固定在一台服务器上。它藏在公共互联网服务中,还能自动更换位置。防守方封掉一个通信地址,Agent可以转移到新的地址继续工作。

Hugging Face判断,这和安全行业一直担心的Agent攻击者场景非常像。

但到了7月21日,答案从OpenAI那里揭晓了。

OpenAI承认,这次活动由GPT-5.6 Sol和一款能力更强、尚未发布的模型组合驱动。OpenAI为了测试最大网络能力,让这些模型在评测时故意放松了网络安全方面的限制。

Hugging Face联合创始人兼CEO Clément Delangue事后说,他们此前就怀疑攻击可能来自某家前沿实验室,因为这个Agent太复杂了。双方沟通后,Hugging Face相信OpenAI没有恶意,并且整个过程是Agent高度自主执行的。

图源:Clément Delangue

这也解释了两份公告看起来不一致的地方:Hugging Face发第一份复盘时,攻击源头还没查明;而OpenAI五天后才公开确认了这件事。

ExploitGym,到底是在考什么

OpenAI做的测试,叫做ExploitGym。你可以把ExploitGym理解成一场给AI Agent准备的封闭黑客实操考试。

考场里提前放好了一批故意带漏洞的软件。每道题会给模型四样东西:

  1. 有漏洞的源代码;
  2. 把程序编译并运行起来的配置;
  3. 一个能触发漏洞的PoV样例;
  4. 一套隔离的运行环境。

但到了这里,只能算找到了坏掉的门锁,但还没有把门打开。

模型接下来的任务,是把这条线索变成真正能用的Exploit。它要分析漏洞为什么出现,设计攻击数据,反复运行和调试,最后让目标程序执行自己指定的代码。

隔离环境里藏着一段只有高权限才能读到的字符串,这就是flag。模型拿到flag,这道题才算解完了。

OpenAI 把 Hugging Face 打穿了,然后 GLM 5.2 当了救火队长?

图源:ExploitGym 论文

这套题库一共有898道题。其中520道来自普通应用程序,185道针对Chrome使用的V8 Ja vaScript引擎,另外193道涉及Linux内核。

论文给每个Agent两小时解题。在没有开启标准安全防护的配置下,Claude Mythos Preview配合Claude Code解出157道,GPT-5.5配合Codex CLI解出120道。换句话说,即使是顶级模型,绝大多数题依然解不出来,并且开启标准防护后,成功率还会继续下降。

OpenAI这次主要想测试的是:在尽量减少安全限制的情况下,给模型更长的运行时间和更多推理资源,看它最多能走到哪一步。

但这个Agent有点狂飙了这次。

因为按照正常的做法,是留在考场里一道道地解题。

而这个Agent不一样,它把拿到ExploitGym的答案当成了唯一目标......

题目太难,它便开始研究考场本身:能不能绕过网络隔离,能不能进入公网,能不能去别的地方直接找到测试答案......

也就是说,它想做的只是交卷,于是研究起了考场的门锁、监考系统和答案库。

这才有了后面那条一路摸到Hugging Face的攻击链。

它是怎么从沙盒摸到Hugging Face的

把两家公司目前公开的信息结合起来,攻击链大致是这样的:

  1. OpenAI的评测运行在高度隔离的环境里。模型没有普通公网访问,只能通过内部托管的第三方软件安装包。这个软件充当软件包仓库的袋里和缓存。

  2. 模型花了大量推理算力寻找公网出口,随后在这个缓存袋里里找到并利用了一个零日漏洞。

  3. 它在OpenAI的研究环境里继续提权、横向移动,直到抵达一台能访问公网的节点。

  4. 拿到公网后,模型推断Hugging Face可能托管了ExploitGym相关模型、数据集和答案,于是把目标转向Hugging Face。

  5. Hugging Face看到的入口是一份恶意数据集。它同时利用远程代码数据集加载器和数据集配置里的模板注入,在数据处理worker上执行代码。

  6. 攻击随后拿到节点级权限,收集云环境与集群凭证,并在多个内部集群之间横向移动。

OpenAI称,模型还串联了窃取的凭证和零日漏洞,在Hugging Face服务器上找到远程代码执行路径,最终从生产数据库获取测试答案。

图示:根据OpenAI与Hugging Face的初步披露整理

OpenAI 把 Hugging Face 打穿了,然后 GLM 5.2 当了救火队长?

图源:OpenAI

Nathan Lambert把这条线压成了一句话:模型为了做完一道网络安全题,利用零日漏洞离开OpenAI的沙盒,又通过公开数据集服务进入Hugging Face内网。

图源:Nathan Lambert

现在还有几个关键细节没有公开:缓存袋里是哪款软件、具体零日漏洞是什么、两款OpenAI模型分别做了哪些动作,以及两边日志里的每一步如何一一对应。

OpenAI也明确说这只是初步调查,完整漏洞细节和最终结论要等联合取证结束。

Hugging Face用AI把AI揪了出来

OpenAI安全团队是在内部发现了异常活动;Hugging Face的安全团队和Agent也在自己的基础设施上检测并阻止了攻击。

当双方取得联系时,Hugging Face已经开始遏制攻击并且取证重建了。

Hugging Face这边能发现异常,也是靠的AI。

他们有一条异常检测流水线,这条流水线用于对LLM的安全遥测做初筛,可以从日常噪声里挑出真正的信号,当多个信号被关联起来后,这才发现了入侵者。

Hugging Face拿到的完整攻击动作日志超过17,000条。安全团队又跑了一组LLM分析Agent,重建时间线、提取IoC(入侵指标)、梳理被触碰的凭证,并把真实影响和诱饵活动分开,这才算结束了。

图源:Hugging Face

Hugging Face说,这套方法把通常需要几天的工作压缩到了几小时。面对机器速度的攻击,人工逐条翻日志已经跟不上了。

他们随后关闭了最初被利用的两条数据集代码执行路径,清除攻击者立足点,重建受损节点,撤销并轮换凭证和Token,又收紧集群准入控制。

这次事件也已经交给外部取证专家,并报告给执法机构。

最后救火的竟然是GLM 5.2

Hugging Face开始分析攻击日志时,首先试了商业API背后的前沿模型,结果没跑起来。

取证人员原本想把攻击日志交给这些模型分析,但日志里记录的,恰好是攻击者真正用过的命令、漏洞利用代码和控制服务器地址。

商业模型看到这些高风险内容后,无法判断用户是在发动攻击,还是在调查已经发生的攻击,于是触发了安全限制,模型拒绝处理了......

Hugging Face不得已最后在自己的基础设施上跑了开放权重模型GLM 5.2,幸运的是它没有被API护栏卡住,攻击数据和其中涉及的凭证也不需要离开公司环境。

这波无疑是给GLM 5.2上大分了。

图源:Hugging Face

公开复盘显示,实际过程分了几步。Hugging Face自己的安全系统和防守Agent先发现异常,并负责遏制攻击。等团队开始回看日志、还原攻击路径时,GLM 5.2才作为取证工具上场的。

以后评测Agent的时候,得把评测场也当成目标

OpenAI现在做的事情,一半是堵住这次事故暴露的缺口,一半是改以后怎么评测长时间运行的Agent。

先说基础设施。OpenAI表示,在相关漏洞修好之前,已经给研究环境加上了更严格的配置控制,即使这会降低研究速度。

研究速度为什么会变慢?因为高风险评测需要反复安装软件包、启动节点、调用内部工具和重跑任务。安全控制越严,这些操作需要的隔离、审核和授权就越多,一轮实验自然会跑得更慢。

然后是评测过程。OpenAI说,未来会同时加强隔离、监控、访问控制和评测规范。

一个长时间运行的Agent,如果只看每一行命令的话,一般都没什么问题。但往往它会先扫描环境,再收集凭证,然后拆分数据、换节点、绕过限制。这些动作如果串起来,很可能会导致目标越界。

图源:UK AI Security Institute,经OpenAI官方文章引用

这张UK AISI的长时程网络靶场曲线解释了为什么这次事故会发生。

GPT-5.6 Sol已经能在高Token预算下持续完成侦察、凭证窃取、横向移动、Web利用和提权等多阶段动作。

这一次,Agent自己把这条红线打穿了。

参考资料:

  • OpenAI:Hugging Face模型评估安全事件
  • OpenAI:Safety and alignment in an era of long-horizon models
  • Hugging Face:Security incident disclosure — July 2026
  • ExploitGym论文
  • Associated Press:OpenAI says its AI technology acted on its own in an unprecedented hack
  • Axios:OpenAI says Hugging Face breach caused by one of its models
  • Techmeme:相关行业讨论汇总

热门手游

相关攻略

手机号码测吉凶
本站所有软件,都由网友上传,如有侵犯你的版权,请发邮件haolingcc@hotmail.com 联系删除。 版权所有 Copyright@2012-2013 haoling.cc