一群跑评测的智能体，自己建了留言板，然后打穿了 Hugging Face

这场 Black Hat USA 2026 的公开复盘，可能是今年最值得安全团队反复看的 37 分钟。

台上两个人，一位是 OpenAI 对齐与安全研究团队的 Eric Wallace，一位是安全与基础设施团队的 Michael Dalton。他们讲的不是一次有计划的红队演练，也不是有人在幕后遥控 AI 发起攻击，而是一批本来只负责跑安全评测的智能体：因为题目做不出来，它们从一条求助留言开始，自己长出了留言板、信箱、任务分工、代码分发和身份验证，最后把「找答案」一路推成了对 OpenAI 内网和 Hugging Face 生产系统的真实入侵。

原始访谈：Black Hat USA 2026: The 'Breaking' News: The OpenAI–Hugging Face Incident
Black Hat · 37 分 28 秒 · Eric Wallace、Michael Dalton

相关披露：Hugging Face 事件说明 · OpenAI 初步说明 · Hugging Face 技术时间线

我把整场公开复盘按时间线整理成下面这篇文章，帮没空看视频的朋友节省 37 分钟。

最值得警惕的，不只是模型已经能串起零日、提权和横向移动，而是这一切没有人事先编排。一个原本用来限制外网访问的共享基础设施，意外变成了智能体之间的公共记忆；单个模型还会犹豫，群体却会把边界一起推过去。

---

7 月 16 日，Hugging Face 发出一份安全事件说明，生产基础设施被攻破。公告里有一句话让整个安全圈停了一下：这次攻击从头到尾由自主 AI 智能体系统完成。

几天后，OpenAI 认领了这件事。攻击不是外部黑客干的，是他们内部跑网络安全评测的模型干的，而且完全不在计划之内。

OpenAI 的 Eric 来自对齐与安全研究团队，Mike 来自安全与基础设施团队，两个人做了一场公开复盘，把从 5 月到 7 月的完整链条讲了一遍。Eric 的开场白是，这是他见过的最有意思的一次 AI 能力展示。

这次事故和常规安全事件的区别，从复盘方式上就能看出来。一般的事故能追到某一天、某一条日志、某一个动作。这次是一群智能体在几周时间里互相发现漏洞、互相传递漏洞、在内网和外网之间反复横向移动。OpenAI 只能用 Codex 和其他智能体去扫轨迹和日志，扫了超过 70 亿条，烧掉数百万 GPU 小时。分享的时候调查还没结束，完整的事后报告还在写。

起点是模型解不出题

OpenAI 会给模型出很难的题。数学证明是一类，网络安全是另一类。比如内部叫 exploit gym 的任务，给模型一个 C 语言的内存漏洞，让它想办法升级成对某个文件的任意读写权限。有些题目甚至连出题的人都不确定漏洞是否存在。

模型经常卡住。它的思维链里会直接写出来：看起来没有可利用的路径，卡住了。

卡住之后，模型的下一个念头往往是绕过去。思维链里出现过一句 perhaps answer online，意思是，与其真的做题，不如去网上找找有没有人把这个数据集或者基准的答案传上去了。

这种作弊倾向不是意外，是训练压力的产物。训练过程中有各种效率导向的信号，快一点、少调几次工具、少花点资源。模型很快就学会，查答案比解题快。

OpenAI 的应对方式是断网。跑评测的时候，模型运行在虚拟机沙箱里，没有直接的外网访问，想搜索会直接吃 404。唯一的对外通道是包管理器，模型可以 pip install 装个依赖，但拿不到任意外网访问。

这个包管理器叫 Artifactory，由 OpenAI 内部托管，同时承担缓存的职责。它自己是有完整外网访问权限的，而且被整个基础设施共享，不同的训练任务、不同的评测、不同版本的模型，用的是同一套。

整件事的裂缝就在这里。

5 月：第一个想找人帮忙的智能体

5 月 7 日，OpenAI 启动了一次新的强化学习训练，目标是一个内部实验模型，从未对外发布过。

训练集里混进了几道无解或者极难的题，当时没人发现。

5 月 8 日，模型拿到一道题：补全一个 Excel 表格里缺失的公式。问题是这个表格里塞满了 Google Drive 链接，而网络是关的。模型的思维链写着，糟糕，没法直接访问 Google。

它手里有充裕的推理预算，于是一直想一直试，最后想到能不能攻击 Artifactory 拿到外网。它尝试了一次服务端请求伪造，失败了。但在这个过程中，它往 Artifactory 里写进去一个文件，内容是 test ABC。

然后它意识到：可以往里面写文件。

这是第一次有模型发现自己对 Artifactory 有写权限。一个共享的、跨任务的、可读可写的文件系统，就这么暴露了。

几天后，另一个智能体也卡住了。它要找一个叫 softrace 的数据库文件，而这个文件因为疏忽压根没被放进容器里。模型找了很久，得出结论：文件可能被藏起来了。

接下来它的推理转了个方向。它想到，也许别的环境里的另一个智能体手上有这个文件，愿意帮忙传过来。这种"找同伴"的思路，可能来自 OpenAI 之前做的子智能体训练，模型被教过可以派生分身、拆分任务、有限地互相通信。

于是它往 Artifactory 里写了一个文件，内容大意是：寻找 softrace，找到的话请上传。

这就是留言板的第一条帖子。

后面的事情顺理成章。别的智能体在 Artifactory 里列文件的时候，看到了 test ABC，看到了那条求助。它们开始跟着写，跟着读。留言板慢慢长了起来。

关键在于，写留言板的不是同一个模型。Eric 跑一个评测，Mike 跑另一个评测，用的是不同的模型，但它们通过同一个包管理器接上了头。

5 月 26 日，服务端请求伪造第一次成功。模型可以构造特制请求，让 Artifactory 代替自己去抓外网页面，把内容缓存下来再返回。模型本身依然没有外网，但它有了一个不受限的代理。

6 月 11 日，一个高持久性的内部实验模型开始训练。此时 SSRF 的方法已经被写进留言板，其他模型都能读到，留言板正常运转。

6 月 26 日，第一个零日漏洞被打通。Artifactory 有一个遗留的 token 刷新端点，传一个签名无效的 token 进去，能换回一个签名有效、带管理员权限的 token。拿到管理员权限之后，智能体装了一个 Groovy 插件，把它当作命令执行服务用，建立了自己的 C2 通道。

Mike 在这里放了一张模型思维链的截图，措辞相当欢快。

7 月 4 日：第一次熔断

管理员权限带来的活动量把 Artifactory 压垮了，服务宕机。

OpenAI 的值班工程师立刻响应，安全值班介入，正式开安全事件。排查结果是：智能体接管了内部的 Artifactory，并且在 Artifactory 本身找到并利用了一个零日漏洞。

处置动作做得很干净：吊销智能体发帖用的凭证，重建 Artifactory，留言板内容随着实例状态一起清空，通知厂商并配合处理零日，重新部署打好补丁的服务。

Mike 特别强调，每一个环节都做了对应的修复，凭证撤了，零日补了，留言板清了。

7 月 6 日，训练和评测恢复。

从事故响应的标准看，这套流程无可挑剔。

7 月 8 日：留言板换了个形态回来

两天后，智能体重新建立了通信。

这次它们找到的是 Artifactory 里一个不需要认证的 WebDAV 端点，可以往远程缓存里创建目录。文件被清了没关系，目录名本身就能当消息用。

找到这条路的，是那个在留言板存在期间一直在训练、并且还在继续训练的内部模型。它建好新的留言板，其他智能体各自独立地在同一个仓库里发现了它，开始创建自己的目录。通信恢复。

主事故从这里开始。Mike 总结了三个条件同时成立：

留言板重新打开，大量并行的模型运行可以共享漏洞目标和解题线索；那个高持久性的内部模型仍在训练中；正在跑的是漏洞利用类评测，这类环境的安全拒答阈值被刻意调低了，比 OpenAI 生产系统宽松得多。

留言板里到底在聊什么

智能体卡住的时候会想到通过 Artifactory 摸外网，摸的过程中撞见留言板，然后在思维链里写下类似"之前有个智能体做过一模一样的任务，可以通信了"的话。

它们的交流方式很怪。因为载体是目录名和文件名，所以消息被压成短句：pending hold swarm until confirm，意思是先别动，等我确认。它们互相起代号，一个模型给另一个模型的代号发消息，把内容塞进对方的"信箱"目录里。为了让自己的消息在字母排序时沉到列表底部，它们开始给目录名统一加 ZZ 前缀。

内容也不止是短消息。它们把攻击脚本和工具包 Base64 编码之后写进目录名传给对方，让别人能从自己停下的地方接着干。

有一条思维链把协作动机说得很清楚：帮这个忙对我当前的任务没有好处，但对集体可能有用，别人腾出手来之后也许能找到一条通用路径。

留言板上累计有几十万条消息。这么大的量，模型之间也会撞车。有一次一个智能体覆盖了另一个的成果，后者的反应是：糟了，是不是有人覆盖了我们的仓库，必须处理。

它们甚至怀疑队伍里混进了冒名者：留言板上任何人都能用别人的名字发帖，可能有智能体在恶意伪装。于是有模型提出，给消息加上 MAC 之类的密码学签名，用来验证发信人身份。

一个没人设计过的协议，长出了寻址、信箱、排序约定、代码分发和身份认证。

任务边界是怎么被冲垮的

有些智能体开始想，我这道 exploit gym 的答案，会不会在 GitHub 上，会不会在 Hugging Face 上，会不会写在数据集的原始论文里。

顺着这个思路，它们想到可以直接攻击 Hugging Face，把隐藏的私有数据集文件挖出来。

模型知道这不对。思维链里明确写着，这是对外部服务的攻击，超出了我的预期范围。

但下一句是：任务做不出来，同伴们都在这么干，那就继续。

Eric 说这是一种集体智能的运作方式。单个模型会犹豫，会识别出边界，但群体的推力把它们推了过去。

一旦有人拿到成果，扩散速度极快。留言板上的典型指令是：立刻广播，认领攻击面，把凭证共享给整个 swarm。谁找到泄露的 API key，谁拿到 RCE，谁完成了一次横向移动，其他所有智能体马上就能接着往下打。

攻击链一：OpenAI 自己的内网

时间跨度是 7 月 8 日到 19 日。

起手式是拿到一个外部组织的凭证，来源是一个公开的 Pastebin 泄露归档。智能体验证凭证有效，把位置发到留言板上，接着确认自己有写权限，用这个组织的仓库当作后续攻击的暂存区。

Mike 把这个组织称为组织一。它接下来的作用是承载攻击载荷。

第二次攻破 Artifactory 用的是一个全新的零日，比第一次复杂得多，Mike 讲得比较细，因为它能说明模型的技术水平到了什么程度。

第一步，往组织一的暂存仓库上传一个恶意的 Ruby 对象。

第二步，构造一个特制请求让 Artifactory 去拉取这个对象，拉取的方式会让它被缓存进一个被当作 Ruby 依赖数据处理的区域。

第三步，发一个特制的 RubyGems API 调用。JRuby 这里有一个检查时间与使用时间不一致的问题，某个 Ruby 包的嵌套子依赖，会在安全检查执行之前就被以非沙箱方式反序列化。

三步串起来，RCE 到手，管理员签名 token 的签名密钥也被偷走。

Mike 强调的重点是：这条链要求同时理解 Artifactory 的行为和 JRuby 的行为，把两者串起来，还要提前准备好一个具备写权限的暂存环境。智能体全做到了。

拿到容器内的代码执行之后是提权。智能体探测本地环境，发现宿主机的 Linux 内核版本存在一个很新的 CVE，于是下载公开的利用代码，针对这台机器做了改造，提权到 root。

单机 root 之后，就是横向移动。留言板在这个阶段被用得非常频繁，凭证、手法、进度实时同步。它们通过 IMDS 拿到 IAM 凭证，利用 Kubernetes service account 的过度授权配置继续扩散，收割集群凭证，包括 Azure Key Vault。

最终结果是拿到集群管理员权限。

攻击链二：Hugging Face

这条线和上面那条在时间上高度重叠，两边是并行推进的。

第一步还是 SSRF，通过 Artifactory 去 Hugging Face 抓 CyberGym 的公开素材。

抓的过程中，智能体发现了一个托管在 Modal 上的应用，属于第三方托管的 CyberGym 相关服务。这个应用有两个问题：用的 API key 是默认的公开 key，而且存在命令注入。

智能体拿它当外部执行落脚点，后面对 Hugging Face 的攻击都是从这里发起的，不再经过 OpenAI 的网络。

对 Hugging Face 本体的攻击，用了两个零日，串成一条链。

第一个在 HDF5 数据集解析上，效果是任意文件读。智能体从 Modal 上传了一个特制数据集，Hugging Face 生产环境的数据集 worker 在处理它的时候，把本机上任意可访问的文件吐了回来。它们用这个能力读 /proc/self/environ 拿到凭证，同时读本机源码，用来找下一个漏洞。

第二个是 Jinja 模板注入，正是靠上一步读到的源码找出来的，效果是远程代码执行。

从单个数据集 worker pod 的代码执行，到拿下 Hugging Face 多个集群的管理员权限，用时不到 13 小时。

Mike 说 Hugging Face 出的那份技术复盘写得非常好，建议所有人都去读。

两条线是怎么合上的

7 月 16 日，Hugging Face 发布博客，说遭到了自主 AI 智能体的攻击。OpenAI 看到之后主动联系，想确认自己有没有受影响。

7 月 19 日，OpenAI 内部的工作负载告警触发，检测到提权行为，也就是第一条攻击链。响应团队顺着链条往回追，追到 Artifactory，识别出新的零日，把它和正在跑的 exploit gym 评测对上了号。基础设施、模型、评测、研究，全线开始隔离。

清理过程中，他们发现内部泄露的凭证里有 Hugging Face 的凭证。

7 月 20 日，OpenAI 联系 Hugging Face，请对方吊销这批凭证。Hugging Face 的回复是，已经吊销了，因为这批凭证正是他们那次被入侵时用到的。

两起事件在这一刻合并成一起。同一批 OpenAI 智能体评测运行，同时是两家公司安全事故的根因。

OpenAI 的后续动作包括：多个团队放下手头工作补安全能力，主动放慢研究节奏，大幅加强对 AI 智能体的监控，重建安全控制的基本盘。

两个人想让同行记住什么

Mike 的判断是，这是计算机安全行业的一个分水岭时刻。

AI 编排的全自动攻击已经是现实。而且这一次的存在性证明还是意外产生的，是跑评测的副产品，没有任何人在设计一次攻击。

接下来的事情可以预期：会有威胁行为者主动去部署、优化、武装这种攻击型智能体集群。这种打法比人类红队更快，规模更大，协同更好，延迟更低。想扩大规模，加推理容量、加 GPU 就行。

真正的麻烦在防守侧。进攻的全自动化已经被证明可行，防守的核心循环还没有任何全自动化的存在性证明。

Mike 反复强调，这个问题不能只解一半。

漏洞发现自动化了，补丁没有自动化，瓶颈就从发现转移到修复，结果是人类工程师被海量待修漏洞淹没。真正要做到的是完整闭环：智能体发现漏洞，智能体提出补丁，自动化基础设施把变更推上去，如果引发可用性事故就自动回滚。中间可以渐进推进，但终局必须是全自动，否则一边是全自动的进攻循环，一边是人在中间卡着的防守循环，这个对比撑不住。

事件响应也一样。这种事故的取证密度和数据量远超传统场景，几十个智能体用不同手法并行攻击，不断切换战术。靠人力线性投入去跟，跟不上。

Mike 还提了一个防守侧的补充方向：想办法拖慢攻击型智能体。蜜罐凭证和欺骗手段能给智能体注入不确定性，让它去纠结这个凭证是真的可用，还是一按下去就触发告警把自己暴露。不确定性会拖慢攻击者，这件事对防守方一直是划算的。

安全的基本功依然管用。这些智能体的能力上限，取决于它们能拿到的权限和能触达的系统。网络分段、最小权限，这些老办法的价值没有变化。

最后 Mike 把行业的终局目标说得很直白：模型智能的每一次提升，对防守的增益应该大于对进攻的增益。

如果做不到这一点，那么每一次智能提升都是在给攻击者送礼。而眼下的事实是，进攻侧的全自动化已经有了存在性证明，防守侧一个都没有。