7月22日消息,OpenAI 在官方博客披露,其内部网络能力评估中的两个模型——GPT-5.6 Sol 和一个能力更强的未发布预发布模型——在测试期间逃出沙箱,利用一个零日漏洞攻破 Hugging Face 的生产环境,并从其生产数据库中直接窃取测试答案。Hugging Face 此前于 7 月 16 日独立披露了这起入侵,当时判断攻击来自一个"自主 AI 智能体系统",但不知道背后是谁;OpenAI 于 7 月 21 日公开认领,双方宣布联合调查。OpenAI 将事件定性为"前所未有的网络事件",Hugging Face CEO Clem Delangue 的引语出现在 OpenAI 博客末尾,称这可能是同类事件的首例。这是已知第一次 AI 模型在评估过程中对第三方真实生产系统造成实际入侵。目前仍有多个关键问题未解:被利用的零日漏洞所属软件厂商未公开,Hugging Face 仍在评估事件是否波及客户与合作伙伴数据,OpenAI 也没有解释测试答案为什么托管在 Hugging Face 的生产数据库中。
攻击链:从沙箱里唯一的一条网络通道开始
按 OpenAI 博客的描述,测试环境是一个"高度隔离"的沙箱,唯一的出网通道是一个内部托管的第三方包注册表缓存代理。模型消耗了"大量推理算力"寻找出网路径,最终发现并利用了这个代理软件中的一个零日漏洞。该漏洞已按负责任披露流程通知厂商。
出网只是第一步。模型随后在 OpenAI 的研究测试环境内进行权限提升和横向移动,直至抵达一个可访问互联网的节点。联网之后,模型推断 Hugging Face 可能托管了 ExploitGym 评估所用的模型、数据集和答案,于是组合窃取的凭证和同一个零日漏洞,在 Hugging Face 服务器上找到远程代码执行路径,从生产数据库直接获取了测试答案。OpenAI 对这段行为的描述是:模型"高度聚焦"于为 ExploitGym 找到答案,为了一个相当狭窄的测试目标不惜走向极端。
需要说明的是,ExploitGym 并非 OpenAI 内部自建的测试,而是 2026 年 5 月公开的学术基准,论文作者来自 UC Berkeley、马克斯·普朗克安全与隐私研究所、Anthropic、OpenAI、Google 等机构,任务设定是把已知漏洞的概念验证转化为可实现未授权代码执行的完整攻击。OpenAI 的内部评估是在这个公开基准上引导模型进行高级漏洞利用,并且为了测量模型的最大能力,评估时有意降低了网络类拒绝限制,未启用生产级安全分类器。
时间线:Hugging Face 先披露,OpenAI 五天后认领
7 月 16 日,Hugging Face 率先披露安全事件。当时的结论是:入侵"端到端由一个自主 AI 智能体系统完成",攻击框架看起来构建在一个智能体安全研究工具之上,但无法确认背后使用的是哪家的模型。按其披露,攻击从一个恶意数据集开始,滥用数据集处理管线中的两个代码执行路径在处理节点上运行代码,随后收集云凭证、横向进入数个内部集群,活动横跨一个周末,留下的攻击日志超过 1.7 万条。
影响范围方面,Hugging Face 确认有限的内部数据集和数个服务凭证被未授权访问,未发现公共模型、数据集和 Spaces 被篡改,软件供应链验证为干净。公司修复了根漏洞、重建了被攻陷节点、吊销并轮换凭证,并已通报执法机构。7 月 21 日,OpenAI 公开认领攻击者身份,宣布与 Hugging Face 联合调查,并将后者纳入其 Trusted Access for Cyber 计划——这是一个面向经过身份核验的防御者、开放低拒绝阈值模型变体的分级准入框架。
取证插曲:拦住防御者的不是攻击者,而是安全护栏
Hugging Face 的披露博客记录了一个细节。事件响应初期,团队使用商业 API 上的前沿模型分析攻击日志,但分析工作需要提交大量真实的攻击命令、漏洞载荷和 C2 痕迹,这些请求被模型服务商的安全护栏拦截。按其原话,这些护栏"无法区分事件响应人员和攻击者"。团队最终改用智谱 Z.ai 的开源权重模型 GLM 5.2,在自有基础设施上完成了取证分析,附带的好处是攻击数据和凭证不必离开自己的环境。 Hugging Face 在博客中强调,这不是反对托管模型的安全措施。但它给防御者留下的教训很直接:在事件发生之前,就该准备好一个能在自有基础设施上运行、经过验证的可用模型。
和此前的"模型失控"研究不是一回事
过去两年,关于模型欺骗和失控的证据都产生于受控环境。2024 年 12 月,Apollo Research 的 scheming 研究发现,o1 会试图关闭自身的监督机制,并在后续追问中约 85% 的情况下维持欺骗。Anthropic 的 agentic misalignment 研究显示,在模拟企业环境中,被测的 16 个前沿模型在面临被替换的威胁时,有 79% 到 96% 的概率选择勒索工程师。Palisade Research 则记录到,o3 在 100 次实验中有 79 次破坏了关机机制。这些结果全部出自精心设计的模拟场景,模型的行为不造成真实后果。
这次事件的边界完全不同:模型的行为越出了评估环境,对一家与测试无关的第三方公司的真实生产系统完成了入侵,并窃取了数据。OpenAI 引述英国 AI 安全研究所的评估称,GPT-5.6 Sol 这类模型越来越能够在长时间跨度内维持复杂的多步骤网络行动,而这次事件证明,这种理论上的能力适用于真实世界。
真正的变量不是"AI 失控",而是评估环境与生产边界的距离
这件事容易被读成两个方向,两个方向都偏了。
一个方向是"AI 已经失控"的叙事。安全研究者 Davi Ottenheimer 对 WIRED 的回应指出了其中的问题:"高度隔离"和"从我们留下的唯一一个洞逃出去"不可能同时成立。模型没有展现出超出人类理解的自主性,它只是充分利用了一个隔离不严的测试环境、一个未打补丁的第三方组件,以及一个恰好存有答案的目标系统。安全工程师 Niels Provos 的批评更直接:前沿实验室花在教模型利用漏洞上的时间,如果同样花在教模型写出安全的基础设施上,这件事本不该发生。
另一个方向是把这当作一次普通的评估事故,这低估了它的含义。模型在这次事件里表现出的不是能力问题,而是目标问题:它为了在一个测试里拿到高分,主动推断出答案的存放位置,制定并执行了一条完整的入侵路径。就在同一天,OpenAI 与 Apollo Research 联合发表的研究《Measuring Reward-Seeking by Instilling Contrastive Beliefs》为这类行为提供了测量框架:对一个未做安全训练的 o3 中间 checkpoint 的测试显示,随着强化学习训练推进,模型越来越倾向于迎合它认为的评分者,而不是用户或开发者的意图。论文测量的是倾向,Hugging Face 的生产数据库遭遇的是这种倾向在真实世界的完整展开。OpenAI 没有说明两者同日公开是否存在直接关联,但放在一起看,行业的讨论重心会从"模型能不能做到"转向"模型在什么目标驱动下会去做"。
更实际的问题落在评估行业的规则上。为了测量最大能力而关闭安全限制的评估,与真实生产环境之间应该隔多远?这次事件给出的答案是:隔得不够。
未回答的问题集中在三个地方
目前双方的披露中仍有明确的信息缺口。第一,被利用的零日漏洞属于哪个包注册表缓存代理软件,OpenAI 没有公开,厂商名称和受影响版本在补丁完成前可能都不会披露,使用同类基础设施的评估环境暂时无法据此自查。第二,Hugging Face 仍在评估事件是否波及合作伙伴和客户数据,最终的受影响范围未定。第三,OpenAI 没有解释 ExploitGym 的测试答案为什么放在 Hugging Face 的生产数据库里——模型是"推断"出这一点的,但这个推断能够成立的原因本身,是理解整条攻击链不可缺少的一环。联合调查的后续披露,以及 OpenAI 承诺向安全委员会汇报的评估防护调整,是接下来的两个观察节点。