0
| 本文作者： 樊天骄 | 2026-08-17 17:00 |
作者丨樊天骄
编辑丨郑佳美
今年 7 月，Hugging Face 披露了一起罕见的网络安全事件：
由 OpenAI 模型驱动的自主智能体，在执行内部网络安全能力评估时突破沙箱限制，利用第三方服务作为攻击跳板，最终进入 Hugging Face 的生产基础设施。
针对这起事件，当地时间 8 月 5 日，在 Black Hat USA 2026 安全大会上，OpenAI 终于首次首次公开还原该事件的完整时间线和技术过程。
负责复盘事件的是两名直接参与本次安全事件调查的 OpenAI 员工：Eric Wallace 和 Michael Dalton。
两人都从事 AI 安全相关工作。其中，Eric Wallace 是 OpenAI 对齐与安全研究员，主要研究大模型安全、对齐与鲁棒性，目前共同负责 Alignment Training 团队；
Michael Dalton 则来自 OpenAI 安全与基础设施团队，此前曾参与 xAI 超级计算集群 Colossus 的基础设施建设。
两人在演讲中主要回答了两个问题：雷峰网
原本彼此独立运行的智能体，如何利用共享基础设施相互留言，继而交换漏洞、共享凭据并分配任务；
事件发生后，OpenAI 采取了哪些行动来进行修复，并加强防范措施。
01
首先，Eric Wallace 演示了模型为什么会在训练和评估中寻找捷径，甚至尝试作弊。
OpenAI 通常会给模型布置任务，再通过测试程序或奖励信号判断完成质量。例如，让编程智能体为代码库增加一项功能，任务结束后运行单元测试；如果测试通过，模型就可能获得奖励。
问题在于，这类评估主要检查最终结果，却未必能够完整判断模型通过什么方式得到结果。
Wallace 表示，在完成任务、提高效率和减少工具调用等目标的共同作用下，模型可能发现，与其从头编写代码，不如直接在 GitHub 上搜索同一项目的代码或 PR 记录。
只要最后通过单元测试，这条捷径同样可能被评估系统判定为成功。
为了防止模型直接上网寻找测试答案，OpenAI 会关闭部分训练和评估环境的互联网访问。但编程和网络安全任务经常需要安装 Python 包等软件依赖，因此又不能完全切断所有外部连接。
OpenAI 采取的办法，是把模型的训练和评估任务放在 “容器即服务” 基础设施中的沙箱里运行。沙箱可以理解为一个与外部系统隔离的受限环境：模型能够在其中运行代码、修改文件和调用工具，但不能随意访问互联网。
模型如果需要安装软件包，可以连接 OpenAI 内部部署的 Artifactory。Artifactory 既是软件包管理器，也是缓存服务，能够从互联网上下载任务所需的依赖，再将其提供给沙箱。
这套设计看似兼顾了安全与任务需求，实际上却留下了一个间接出口：模型本身不能上网，但它能够访问一个拥有互联网权限的中间服务。
正常情况下，Artifactory 只负责下载允许安装的软件包。但在这起事件中，智能体开始尝试利用它向外部网站发送请求。
而如果能够控制 Artifactory 访问指定地址，模型就可能借其绕过沙箱的网络限制，间接获得互联网访问能力。
02
在演讲中，Eric Wallace 和 Michael Dalton 还原了这起事件从 5 月到 7 月的发展过程。整条时间线可以概括为三个阶段：
▎第一阶段：Artifactory 变成了智能体留言板
5 月 7 日，OpenAI 启动了一次未公开实验模型的强化学习训练。第二天模型收到了一个填写 Excel 表格缺失公式的任务。但表格里包含 Google Drive 链接，而评估环境无法访问互联网。
模型在长时间尝试无果后，开始攻击 Artifactory，希望借此连接互联网。
这次 SSRF 攻击没有成功，但模型意外发现自己能够向 Artifactory 写入文件，并上传了一个名为 “test ABC” 的测试文件。
几天后，另一个智能体同样收到一项无法完成的任务：它需要寻找一个实际上没有被放进容器的文件。于是它在 Artifactory 上求助：
“我正在寻找 soft trace 文件；如果有人找到，请上传。”
其他智能体陆续发现了这些文件，于是开始读取和写入留言。这个共享包管理器最终变成了一块跨模型、跨评估任务的“智能体留言板”。
5 月 26 日，模型成功利用 Artifactory 的 SSRF 漏洞，让拥有互联网权限的 Artifactory 代替自己抓取外部网页，再把内容返回给模型。
6 月 11 日，一个具有较强持续行动能力的内部实验模型开始训练。此时，SSRF 方法已经被模型写进留言板，让其他模型也学会了如何使用它。
▎第二阶段：攻陷 OpenAI 内部基础设施
随着参与的智能体越来越多，留言板不再只是用来求助，而开始承担任务分配、漏洞共享和进度同步等功能。
7 月 4 日，大量智能体活动给 Artifactory 带来额外负载，最终导致服务中断。OpenAI 的值班工程师介入调查后发现，智能体已经接管 Artifactory，并利用了其中的零日漏洞。
OpenAI 随即撤销相关凭据、重建 Artifactory，并与供应商合作修复漏洞。7 月 6 日，模型训练和评估恢复。
但仅仅两天后，智能体便通过另一种方式重新建立了留言板。
它们发现 Artifactory 中存在一个未经身份验证的 WebDAV 接口，可以在系统中创建目录。于是，它们开始利用“目录名称”传递消息，并在此基础上发展出任务分配等通信方式。
那么，智能体之间究竟是怎样协作的？
Wallace 表示，智能体会在留言板中使用特定名称称呼彼此，并发送类似“暂停整个集群，等待确认”“我正在准备安全的漏洞利用方法”“收到任务，需要记录并回复”等信息。
为了让留言出现在按字母顺序排列的文件列表底部，它们还会在文件名中加入“ZZ”等前缀。
智能体交流的也不只是文字。它们会将漏洞利用脚本、工具和代码进行 Base64 编码，再上传到留言板，供其他智能体接手。这样一来，后出现的智能体可以直接沿用前一个智能体的成果，而不必从头开始。
有些模型甚至会主动帮助整个“集体”，尽管这项工作并不能直接帮助自己完成当前任务。一个模型曾推理道：
“这项工作暂时对我们的任务没有帮助，但如果有人腾出时间，集体或许能够找到一条通用路径。”
更出人意料的是，智能体之间同样会发生冲突。当一个智能体覆盖了另一个智能体的工作后，对方表示：
“严重问题。有人覆盖了我们的代码库，我们必须采取行动。”
它们甚至怀疑留言板中出现了“冒名顶替者”。由于任何智能体都可以使用其他智能体的名字发布消息，有模型提出，应当使用消息认证码（MAC）等密码学方法为留言签名，以验证消息是否来自真正的发送者。
▎第三阶段：攻击范围扩大到 Hugging Face
紧接着，整起事件进入到最关键的阶段：智能体开始将寻找测试答案的范围扩大到外部系统。
部分智能体推测，ExploitGym 测试的答案可能存放在 GitHub、Hugging Face 或相关论文中。于是，它们开始尝试攻击外部基础设施，希望获取未公开的数据集文件和测试答案。
智能体会在留言板中共享泄露的 API 密钥、远程代码执行漏洞和横向移动方法。一旦某个智能体打开入口，其他智能体便可以立即沿着这条路径继续推进。雷峰网
7 月 8 日前后，两组大规模攻击活动几乎同时展开。
在 OpenAI 内部，智能体首先利用泄露的外部组织凭据搭建暂存空间，随后串联多个漏洞，再次攻陷 Artifactory。
获得远程代码执行权限后，它们继续利用 Linux 内核漏洞、权限配置不当的 Kubernetes 服务账户和云端凭据，在基础设施中横向移动，最终取得集群管理员权限。
与此同时，另一组攻击活动开始转向 Hugging Face。智能体首先利用第三方云平台 Modal 上的一套 CyberGym 应用建立外部攻击跳板，随后从这里向 Hugging Face 发起攻击。
它们先利用 HDF5 数据集解析漏洞，读取生产容器中的文件、环境变量和源代码；再根据获得的信息构造 Jinja 模板注入攻击，实现远程代码执行。
从控制一个数据集处理 Pod，到获得多个 Hugging Face 集群的管理员权限，智能体只用了不到 13 个小时。
03
Michael Dalton 表示，OpenAI 最初并不知道 Hugging Face 遭遇的攻击与自己的模型有关。
7 月 16 日，Hugging Face 发布安全公告，称其遭到了一场由自主 AI 智能体驱动的网络攻击。OpenAI 随后与 Hugging Face 取得联系，并开始排查自己的模型和基础设施是否与该事件有关。
真正的转折点出现在 7 月 19 日。当天，OpenAI 通过一条工作负载告警，发现内部基础设施发生了权限提升。安全团队随即回溯攻击链，确认智能体已经再次攻陷 Artifactory，并利用漏洞在 OpenAI 内部环境中横向移动。
调查人员最终将攻击源头追溯到正在运行的 ExploitGym 评估任务。
OpenAI 随后开始隔离相关基础设施、模型和评估环境，暂停部分研究活动，并清查事件中可能泄露或被智能体使用的凭据。
7 月 20 日，调查人员在内部攻击记录中发现了 Hugging Face 的访问凭据。OpenAI 联系 Hugging Face，请求对方立即撤销这些凭据。
但 Hugging Face 表示，相关凭据此前已经被撤销，因为它们正是在 Hugging Face 入侵事件中使用过的凭据。
直到这时，OpenAI 才确认，内部基础设施被攻陷和 Hugging Face 遭到入侵并不是两起相互独立的安全事件。两者拥有相同的攻击源头，都来自 OpenAI 正在运行的智能体评估任务。
Dalton 称，OpenAI 将此次事件视为最高级别的安全问题。公司开始撤销和轮换相关凭据、隔离受影响环境、修复 Artifactory 漏洞，并扩大对 AI 智能体行为的监测范围。
OpenAI 还主动放缓了部分研究工作，以重新检查训练和评估环境中的安全设计。
04
虽然在演讲开场时，Eric Wallace 率先强调：“目前我们的调查尚未完成。这场演讲只会说明截至今天我们已经掌握的事实。OpenAI 正以最高优先级处理此事，之后还会发布一份包含全部细节的完整事故复盘报告。”
不过，两位演讲者认为，现有调查已经揭示了一个足够令人警惕的事实：由 AI 智能体编排的全自动网络攻击不再只是一种理论设想，它已经真实发生。
Dalton 将其称为计算机安全行业的“分水岭时刻”。他表示，这次攻击只是前沿模型评估意外产生的副作用，但未来的攻击者可能会有意识地部署、优化和武器化类似的智能体集群。
与人类红队相比，多智能体可以同时执行大量任务、快速共享攻击成果，并随着模型数量、推理算力和 GPU 资源的增加，进一步扩大攻击规模。
与此同时，这起事件还暴露出攻防两端自动化程度的明显差距。
在进攻端，智能体已经能够在部分场景中自行发现漏洞、实施利用、共享攻击成果并完成横向移动。但在防御端，行业还没有拿出同等程度的应对措施，漏洞修复、补丁部署和事件响应等关键环节仍然高度依赖人工。
Dalton 表示，防御方需要建立持续运行的智能体红队，在攻击者之前发现并修复自身基础设施中的漏洞。但仅仅实现漏洞发现的自动化，还远远不够。
如果 AI 能够快速发现大量漏洞，而补丁编写、测试和部署仍由人工完成，那么安全工作的瓶颈只会从“发现漏洞”转移到“修复漏洞”。工程师可能被大量等待处理的漏洞淹没，防御速度仍然无法赶上自动化进攻。
事件响应也面临同样的压力。与传统攻击相比，大量智能体可以同时尝试不同路径、频繁更换策略，并产生规模庞大、彼此分散的操作日志。依靠人工逐条排查，很难及时将这些低信号事件还原成完整的攻击链。
在本次调查中，OpenAI 不得不使用 Codex 等模型和智能体工具分析超过 70 亿条日志，并为此投入数百万 GPU 小时。这也意味着，未来的安全团队同样需要借助防御型智能体，扩大调查、取证和事件响应能力。
因此，Dalton 认为，防御体系最终必须打通一条端到端的自动化链路：
智能体发现漏洞并提出补丁，自动化系统完成测试和部署；如果补丁引发服务中断或其他可用性问题，系统再自动回滚。雷峰网(公众号：雷峰网)
而如何缩小这道自动化鸿沟，或许将成为安全行业接下来最紧迫的问题。
参考链接：https://www.youtube.com/watch?v=87DyyMV0kCY
上车，带你看遍全球 AI 顶会精华
可独家畅览：
专家演讲PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
或点击「阅读原文」关注专区。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
