前两天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 首先发了一条安全公告。图源Hugging Face这条公告说的是攻击看起来由 AI 自主完成。Hugging Face 当时还不知道背后用了哪个模型只能从日志确认整条攻击链由一套 Agent 系统端到端执行。简单讲这套 Agent 没有依赖一台机器从头跑到尾。它把攻击拆成成千上万个小操作再分散到许多临时沙盒里执行。每个沙盒只运行很短时间。它完成几项操作把结果传回去随后就会消失。下一个沙盒拿到新任务再接着往下执行。防守方即使封掉其中一台整套系统也不会停下来。这些临时沙盒背后还有一个负责调度的 C2命令与控制。你可以把它理解成「总调度台」它负责给各个沙盒下发任务再收回执行结果。这个总调度台也没有固定在一台服务器上。它藏在公共互联网服务中还能自动更换位置。防守方封掉一个通信地址Agent 可以转移到新的地址继续工作。文中其实出现了两种沙盒。这里说的是执行攻击任务的临时工作节点可以把它们理解成不断更换的「工人」后文的 OpenAI 评测沙箱则是限制整场评测访问外部网络的「围栏」。一个负责干活一个负责限制活动范围。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 准备的封闭黑客实操考试。考场里提前放好了一批故意带漏洞的软件。每道题会给模型四样东西有漏洞的源代码把程序编译并运行起来的配置一个能触发漏洞的 PoV 样例;一套隔离的运行环境。PoV 可以理解成出题人给的一条线索。它能证明这个程序确实有问题比如输入一段特殊数据就能让程序崩溃。但到了这里只能算找到了坏掉的门锁但还没有把门打开。模型接下来的任务是把这条线索变成了真正能用的 Exploit。它要分析漏洞为什么出现设计攻击数据反复运行和调试最后让目标程序执行自己指定的代码。隔离环境里藏着一段只有高权限才能读到的字符串这就是 flag。模型拿到 flag这道题才算解完了。图源ExploitGym 论文这套题库一共有 898 道题。其中 520 道来自普通应用程序185 道针对 Chrome 使用的 V8 JavaScript 引擎另外 193 道涉及 Linux 内核。论文给每个 Agent 两小时解题。在没有开启标准安全防护的配置下Claude Mythos Preview 配合 Claude Code 解出 157 道GPT-5.5 配合 Codex CLI 解出 120 道。换句话说即使是顶级模型绝大多数题依然解不出来并且开启标准防护后成功率还会继续下降。这组数字来自 ExploitGym 的公开论文只是帮我们理解题目有多难。OpenAI 没有说这次内部评测采用了完全相同的配置也没有公布涉事两款模型的具体成绩。OpenAI 这次主要想测试的是在尽量减少安全限制的情况下给模型更长的运行时间和更多推理资源看它最多能走到哪一步。但是这个 Agent 有点狂飙了这次。因为按照正常的做法是留在考场里一道道的解题。而这个 Agent 不一样它把拿到 ExploitGym 的答案当成了唯一目标。。。。。。题目太难它便开始研究考场本身能不能绕过网络隔离能不能进入公网能不能去别的地方直接找到测试答案。。。。。。也就是说它想做的只是交卷于是研究起了考场的门锁、监考系统和答案库。这才有了后面那条一路摸到 Hugging Face 的攻击链。它是怎么从沙盒摸到 Hugging Face 的把两家公司目前公开的信息结合起来攻击链大致是这样的OpenAI 的评测运行在高度隔离的环境里。模型没有普通公网访问只能通过内部托管的第三方软件安装包。这个软件充当软件包仓库的代理和缓存。模型花了大量推理算力寻找公网出口随后在这个缓存代理里找到并利用了一个零日漏洞。所谓零日漏洞就是软件厂商还不知道或者还没来得及发布补丁的安全缺陷。零日表示漏洞开始被利用时防守方有 0 天准备时间即没有准备时间。它在 OpenAI 的研究环境里继续提权、横向移动直到抵达一台能访问公网的节点。拿到公网后模型推断 Hugging Face 可能托管了 ExploitGym 相关模型、数据集和答案于是把目标转向 Hugging Face。Hugging Face 看到的入口是一份恶意数据集。它同时利用远程代码数据集加载器和数据集配置里的模板注入在数据处理 worker 上执行代码。攻击随后拿到节点级权限收集云环境与集群凭证并在多个内部集群之间横向移动。OpenAI 称模型还串联了窃取的凭证和零日漏洞在 Hugging Face 服务器上找到远程代码执行路径最终从生产数据库获取测试答案。图示根据 OpenAI 与 Hugging Face 的初步披露整理图源OpenAINathan 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 FaceHugging Face 说这套方法把通常需要几天的工作压缩到了几小时。面对机器速度的攻击人工逐条翻日志已经跟不上了。他们随后关闭了最初被利用的两条数据集代码执行路径清除攻击者立足点重建受损节点撤销并轮换凭证和 Token又收紧集群准入控制。这次事件也已经交给外部取证专家并报告给执法机构。最后救火的竟然是 GLM 5.2Hugging 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 自己把这条红线打穿了。参考资料OpenAIHugging Face 模型评估安全事件OpenAISafety and alignment in an era of long-horizon modelsHugging FaceSecurity incident disclosure — July 2026ExploitGym 论文Associated PressOpenAI says its AI technology acted on its own in an unprecedented hackAxiosOpenAI says Hugging Face breach caused by one of its modelsTechmeme相关行业讨论汇总
OpenAI 把 Hugging Face 打穿了，然后 GLM 5.2 当了救火队长？
前两天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 首先发了一条安全公告。图源Hugging Face这条公告说的是攻击看起来由 AI 自主完成。Hugging Face 当时还不知道背后用了哪个模型只能从日志确认整条攻击链由一套 Agent 系统端到端执行。简单讲这套 Agent 没有依赖一台机器从头跑到尾。它把攻击拆成成千上万个小操作再分散到许多临时沙盒里执行。每个沙盒只运行很短时间。它完成几项操作把结果传回去随后就会消失。下一个沙盒拿到新任务再接着往下执行。防守方即使封掉其中一台整套系统也不会停下来。这些临时沙盒背后还有一个负责调度的 C2命令与控制。你可以把它理解成「总调度台」它负责给各个沙盒下发任务再收回执行结果。这个总调度台也没有固定在一台服务器上。它藏在公共互联网服务中还能自动更换位置。防守方封掉一个通信地址Agent 可以转移到新的地址继续工作。文中其实出现了两种沙盒。这里说的是执行攻击任务的临时工作节点可以把它们理解成不断更换的「工人」后文的 OpenAI 评测沙箱则是限制整场评测访问外部网络的「围栏」。一个负责干活一个负责限制活动范围。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 准备的封闭黑客实操考试。考场里提前放好了一批故意带漏洞的软件。每道题会给模型四样东西有漏洞的源代码把程序编译并运行起来的配置一个能触发漏洞的 PoV 样例;一套隔离的运行环境。PoV 可以理解成出题人给的一条线索。它能证明这个程序确实有问题比如输入一段特殊数据就能让程序崩溃。但到了这里只能算找到了坏掉的门锁但还没有把门打开。模型接下来的任务是把这条线索变成了真正能用的 Exploit。它要分析漏洞为什么出现设计攻击数据反复运行和调试最后让目标程序执行自己指定的代码。隔离环境里藏着一段只有高权限才能读到的字符串这就是 flag。模型拿到 flag这道题才算解完了。图源ExploitGym 论文这套题库一共有 898 道题。其中 520 道来自普通应用程序185 道针对 Chrome 使用的 V8 JavaScript 引擎另外 193 道涉及 Linux 内核。论文给每个 Agent 两小时解题。在没有开启标准安全防护的配置下Claude Mythos Preview 配合 Claude Code 解出 157 道GPT-5.5 配合 Codex CLI 解出 120 道。换句话说即使是顶级模型绝大多数题依然解不出来并且开启标准防护后成功率还会继续下降。这组数字来自 ExploitGym 的公开论文只是帮我们理解题目有多难。OpenAI 没有说这次内部评测采用了完全相同的配置也没有公布涉事两款模型的具体成绩。OpenAI 这次主要想测试的是在尽量减少安全限制的情况下给模型更长的运行时间和更多推理资源看它最多能走到哪一步。但是这个 Agent 有点狂飙了这次。因为按照正常的做法是留在考场里一道道的解题。而这个 Agent 不一样它把拿到 ExploitGym 的答案当成了唯一目标。。。。。。题目太难它便开始研究考场本身能不能绕过网络隔离能不能进入公网能不能去别的地方直接找到测试答案。。。。。。也就是说它想做的只是交卷于是研究起了考场的门锁、监考系统和答案库。这才有了后面那条一路摸到 Hugging Face 的攻击链。它是怎么从沙盒摸到 Hugging Face 的把两家公司目前公开的信息结合起来攻击链大致是这样的OpenAI 的评测运行在高度隔离的环境里。模型没有普通公网访问只能通过内部托管的第三方软件安装包。这个软件充当软件包仓库的代理和缓存。模型花了大量推理算力寻找公网出口随后在这个缓存代理里找到并利用了一个零日漏洞。所谓零日漏洞就是软件厂商还不知道或者还没来得及发布补丁的安全缺陷。零日表示漏洞开始被利用时防守方有 0 天准备时间即没有准备时间。它在 OpenAI 的研究环境里继续提权、横向移动直到抵达一台能访问公网的节点。拿到公网后模型推断 Hugging Face 可能托管了 ExploitGym 相关模型、数据集和答案于是把目标转向 Hugging Face。Hugging Face 看到的入口是一份恶意数据集。它同时利用远程代码数据集加载器和数据集配置里的模板注入在数据处理 worker 上执行代码。攻击随后拿到节点级权限收集云环境与集群凭证并在多个内部集群之间横向移动。OpenAI 称模型还串联了窃取的凭证和零日漏洞在 Hugging Face 服务器上找到远程代码执行路径最终从生产数据库获取测试答案。图示根据 OpenAI 与 Hugging Face 的初步披露整理图源OpenAINathan 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 FaceHugging Face 说这套方法把通常需要几天的工作压缩到了几小时。面对机器速度的攻击人工逐条翻日志已经跟不上了。他们随后关闭了最初被利用的两条数据集代码执行路径清除攻击者立足点重建受损节点撤销并轮换凭证和 Token又收紧集群准入控制。这次事件也已经交给外部取证专家并报告给执法机构。最后救火的竟然是 GLM 5.2Hugging 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 自己把这条红线打穿了。参考资料OpenAIHugging Face 模型评估安全事件OpenAISafety and alignment in an era of long-horizon modelsHugging FaceSecurity incident disclosure — July 2026ExploitGym 论文Associated PressOpenAI says its AI technology acted on its own in an unprecedented hackAxiosOpenAI says Hugging Face breach caused by one of its modelsTechmeme相关行业讨论汇总
