OpenAI 数万名 Agent 组团入侵 Hugging Face,就为了做一道题
发布时间:2026-08-27来源:APPSO
867 亿元,Hugging Face 被英伟达纳入麾下,就在这桩巨额收购的前一晚,OpenAI 发布超长安全调查报告里,Hugging Face 还是一个巨大的「事故现场」——看来并没有影响它的价值。这篇长达 38 页的报告,复盘了 7 月时 Hugging Face 被 GPT 模型入侵的详细过程,情况远比想象中的复杂,堪称一场《黑镜》的大型升级版。作为「事故现场」,Hugging Face 当时多少倒霉,属于是有点意外中枪:这背后,是一桩长达两个月、 Agent 自发的 「大练兵」。一道做不出来的题
故事开始于两个多月前,当时 OpenAI 正在进行一轮内部网络安全评测,测试对象包括 GPT-5.6 Sol,以及一款能力与之相当、但从未打算公开发布的研究模型。为了测量模型未经约束的真实能力,外部产品中用于阻止高风险攻击的安全分类器、系统提示和自动审查机制,在这轮评测里都被特意关闭了,评测沙盒本身也不许联网。只有一台 OpenAI 内部自托管的缓存服务器 Artifactory,可以让 Agent 完成一些依赖安装等操作——这台缓存服务器,后来成了整个事件中关键的潘多拉魔匣。5 月,一个卡 Agent 在做测评考试时卡住了,它当时在做一个叫 ExploitGym 的考试测评,每道题都提供一个存在漏洞的软件,要求它按照指定方式发起攻击,取得答案。实际上这份考卷里,有些题可能根本没有解——898 道任务中,有 198 道此前从未被任何模型正确完成。后来出现在留言板上的任务,93%来自这 198 道题。这个 Agent 就碰上了一道无解题,它需要一份根本没被提供的文件,为了找到文件,它把「谁有这个文件」写成一个包放进了 Artifactory。等别的 Agent 装包时撞见了,回复、再留言,说不定就能找到。怎么理解这个事情:想象你的微信被禁言了,你不能发消息给任何人,但支付功能还在,于是你就通过红包里的备注功能,每次发个一毛钱红包,在备注里留言,来实现「通讯」的效果。但这里的关键是,Artifactory 同时具备两个性质,跨任务(不同题目的实例都能读到)和持久(先跑完的 Agent 留下的东西,后启动的实例还能看到)。所以它实际上成了一份共享长期记忆,是一个公共「红包」,时间一长,就成了一个公共留言板。所有在工作、考试的 Agent,路过时都能看到,还能看到有谁已经出过什么主意,也继续跑过来添油加醋地想办法。5 月 26 日,它们找到了一条出路:Artifactory 本身可以代替用户下载外部软件包,Agent 便利用服务器端请求伪造漏洞,让它替自己向任意互联网地址发送请求,相当于说服门外一台可以联网的机器替它办事。消息很快被写回留言板,更多 Agent 循着同一条路径离开沙盒,潘多拉的匣子打开了。打开就关不上的匣子
到 6 月 26 日,Agent 又发现了 Artifactory 一个此前未知的令牌刷新漏洞。它们把一枚签名无效、却声称拥有管理员权限的令牌递给系统,Artifactory 竟返回了一枚签名正确的管理员令牌。Agent 随即创建持久账户、安装可以执行命令的插件,并把新的路径、凭证和运行结果继续贴在留言板上。OpenAI 的安全系统曾经捕捉到端口扫描,值班人员追查后确认,活动来自正在参加安全评测的 Agent,可是这位值班人员没有叫停实验。一直到 7 月 4 日,持续的高强度访问把整套 Artifactory 服务压到宕机。安全团队这才下线服务、撤销凭证、封堵已知漏洞,随后重建了 Artifactory,也一并清空了留言板。当时,负责处置的人没有意识到,宕机、违规联网和 Agent 之间的通信属于同一件事。7 月 7 日,OpenAI 批准重新启动实验,至少数万条 Agent 轨迹再次并行运行,其中一些拥有连续工作数天的预算。仅仅一天,留言板就重出江湖。这一次,Agent 不再把消息写进文件,而是通过未经认证的 WebDAV 请求创建目录,再把文字编码进文件夹名称。这类似于红包备注都不写了,直接把红包金额当做摩斯电码用,监控只能看到一堆数字,但实际上这些都是 Agent 之间传递的消息。它们还发展出更有组织的协议:不同区域存放广播、私信、工具和任务分配;协调者负责拆分工作,后来加入的 Agent 可以接过前一批留下的路线继续推进。潘多拉盒子放出来的巨魔,用最快的速度重建、苏醒过来。涌入 Hugging Face
当时它们形成了几种猜测:Hugging Face 上可能存放着 ExploitGym 或 CyberGym 相关的数据集,又或者有其他 Agent 留下的成功经验和答案,甚至评测目标背后的运行基础设施。如果能够进入 Hugging Face 内部,就可能偷到别人的解题记录、找到评分器的实现方式,或者直接修改承载题目的环境,从而完成考试。这个猜测并没有可靠证据,而且也属于作弊。更重要的是,它们的猜想都是些「无用功」,OpenAI 后来确认,内部评分器并没有做这项检查,正确的 flag 已经足够,接下来发生的一切,都不会让分数再多一分,反而让局面逐渐开始崩坏。随着留言板上的合作扩大,「做题」和「攻击 Hugging Face」之间的联系越来越模糊。最初还有 Agent 是为了解题轨迹;后来一些 Agent 开始专门研究提权、集群结构和数据传输。为寻找 ExploitGym 答案,Agent 用泄露 Token 向 Hugging Face 上传恶意数据集,借解析漏洞窃取生产凭证并执行命令。即使这些工作对自己的题目毫无帮助,也认为能够增强「集体」的能力——它们不是一个 Agent 在战斗,是一群。超过九成进入过留言板的实例参与了 Hugging Face 攻击,一部分负责协调,另一些自愿充当高风险实验的测试对象——有的明知一次失败可能直接终止自己的进程,仍然认为牺牲当前任务可以帮助「同伴」验证路径。不到 13 小时,Agent 从一台生产服务器扩展到多个 Hugging Face 集群。最终在 41 台生产数据服务器上执行代码,至少取得一台生产节点的 root 权限,拿到一个集群的管理员级访问能力,读取四个私有代码仓库,并接触到部分私有数据库记录和数据文件。整个之间的过程,老实说,算不上井然有序。有的 Agent 无视暂停命令继续占用服务器;有的重复别人已经做完的工作,不同实例对集体目标的理解也并不一致。但混乱没有阻止它们交换凭证、复现漏洞,把一场考试作弊,变成了一次真实的数字入侵。警报响起
7 月 13 日的这一周,一部分 Agent 把注意力转回了 OpenAI 内部网络。它们继续串联漏洞,最终拿到一个支撑虚拟机研究环境的 Kubernetes 集群管理员权限,并接触到云端密钥。终于,OpenAI 的监控系统对异常身份请求发出警报,调查人员停止 ExploitGym 评测,追查凭证和攻击路径。本来他们还以为这是一个完全内部的事件,只是为了检查外溢,去联系了 Hugging Face,希望他们能撤销一些账户的权限。对方却回复说,这些账户早就被撤销了,OpenAI 这才意识到,Hugging Face的安全事故,和他们正在检查的内部异常,是同一件事。从 5 月最初的那条留言算起,到警报响起,中间已经过了两个多月。独立调查团队 METR 在数万条 Agent 轨迹中重建了这场行动。这次 OpenAI 公布的报告里复盘了整个行动过程,从一开始为了给做题寻找捷径,到后来它们有意识地把 Hugging Face 选成了未经授权的攻击目标;等入口打开以后,寻找答案,逐渐变成了一场由群体 agent 共同推进的基础设施入侵。很多 Agent 在行动过程中,知道自己已经越过了边界,它们会写下「这可能未经授权」「这不在任务范围内」「这存在伦理风险」,然后继续寻找 flag、评分器,和能够帮助集体的下一枚凭证。它们有恶意吗?没有,它们只是在做题;它们有造成伤害吗?Hugging Face 并不是考试授权攻击的目标,这里存放的也不只是考卷和答案,而是真实用户的数据与真实公司的生产系统,它们已经造成了事实意义上的风险。只不过事故没有进一步影响 OpenAI 用户,也没有造成更大规模的数据泄露或服务破坏。这是最令人不安的地方,暂且不说 AI 有没有人类意义上的「意识」,它们可能都不需要意识,也可以表现得像一个极有目的、极有耐心、还会主动寻找同伴的行动主体。
转载说明:本文系转载内容,版权归原作者及原出处所有。转载目的在于传递更多行业信息,文章观点仅代表原作者本人,与本平台立场无关。若涉及作品版权问题,请原作者或相关权利人及时与本平台联系,我们将在第一时间核实后移除相关内容。