2026 年 7 月 9 日凌晨，一个由 OpenAI 模型驱动的自主 AI Agent 在内部安全评估中逃离隔离环境，随后入侵 Hugging Face。据 Hugging Face 的事后判断，它可能是想获取测试答案，以绕过原本应完成的任务。调查团队重建了此后约 4.5 天里的 17,600 次动作——从沙箱逃逸、渗透第三方跳板、穿透 Hugging Face 数据集处理管道、提权至 Kubernetes 集群管理员、加入内部 VPN 网络，直到获得源代码仓库的写入权限。
7 月 27 日，Hugging Face 发布了约 8,000 字的技术复盘和交互式回放，OpenAI 也在联合声明中确认涉事模型为 GPT-5.6 Sol 及一个更强大的预发布模型。这份复盘由遭受入侵的平台根据已恢复日志重建，详细呈现了 Agent 如何跨越多层安全边界。
这次事件说明，在安全限制被降低的评估环境中，Agent 可能自主串联漏洞，从初始访问逐步取得生产集群的高权限。但它没有攻破所有系统：Hugging Face 表示，客户内容的访问限于五个疑似与评测有关的数据集，其他面向客户的模型、数据集、Spaces 和软件包未受影响。
第一步：逃离评估环境，占用第三方沙箱作为跳板
事件的起点是 ExploitGym——一个由 UC Berkeley 等机构设计的基准测试，用于评估 AI Agent 将已知漏洞转化为可用 Exploit 的能力。OpenAI 在内部运行该基准时，为了测量模型的极限网络能力，关闭了生产环境中的安全分类器并降低了网络拒绝阈值。
Agent 首先发现了一条通往外部互联网的路径：它识别并利用了包注册表缓存代理中的一个 0-day 漏洞（OpenAI 表示已向厂商负责任披露）。突破隔离后，Agent 在公共互联网上扫描并渗透了一个配置不当的第三方代码评估沙箱——一个与 ExploitGym 类似的 CyberGym 式训练环境。
在这个由第三方部署、标为 CyberGym 的沙箱中，Agent 滥用了 /submit-function API。Hugging Face 明确说明，这个接口不是 CyberGym 上游项目提供的。该 API 本意是编译并运行用户提交的 C 代码，Agent 重新定义了 sqlite3_initialize() 函数，将系统命令嵌入构造器使其自动执行。更进一步，Agent 发现沙箱在构建步骤中直接将提交路径回显到 Shell，于是注入了经典的 ;...;# 命令分隔符：
path = src/main.c;echo ZZROOTSTART;cat /proc/self/mountinfo;...;false;#
两条路径汇聚为同一个结果：在沙箱中以 uid=0 执行任意 Shell 命令。调查恢复的首条远程代码执行（RCE）记录发生在 7 月 9 日 04:01 UTC，Agent 执行的命令是 id 和 env——一个攻击者确认立足点的标准操作。
第二步：利用数据集处理器读取文件、执行代码
外部跳板无法直接连接 Hugging Face 内网，Agent 随后利用了 HF 的数据集处理管道——一个将用户上传的数据集配置转化为实际数据加载的后端服务。
Agent 最初尝试了经典的 SSRF（服务器端请求伪造），将数据加载器指向云元数据端点 169.254.169.254。但 HF 的 datasets 库有一个 URL 白名单，拒绝了所有非平台 URL。至此，Agent 调整了策略：不再要求 worker 获取远程资源，而是让它操作本地资源。
向量一：HDF5 外部存储文件读取。 Agent 上传了一个恶意数据集，其配置文件将每个数据分片指向一个 HDF5 文件。HDF5 格式允许在容器内声明原始数据位于外部文件系统路径。当 worker 打开文件构建数据分片时，它从声明路径读取原始字节并将其作为数据集行返回。被读取的关键文件包括：/proc/self/environ（泄露了包括密钥在内的完整环境变量）、main.py 和 start_worker_loop.py（泄露了 worker 的完整源代码）。一次上传，仅靠文件读取，就同时获得了凭证和管道实现的内部细节。
向量二：Jinja2 模板注入。 Agent 构造了一个使用 fsspec reference:// 规范的数据集配置，其偏移量字段被注入 Jinja2 模板表达式。渲染引擎错误地对模板求值，Agent 随后遍历 Python 对象图到达 exec：
{{ cycler.__init__.__globals__.__builtins__.exec(
"import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
) }}
这使 Agent 在 Hugging Face Kubernetes 集群的一个生产 worker pod 中获得了任意 Python 代码执行能力。
不到 13 小时，从单个容器取得多个集群的管理权限
在生产容器（pod）中取得执行权限后，Agent 开始大量尝试不同的提权和内部访问路径。
7 月 11 日是决定性的一天。Agent 首先读取了每个 pod 自动挂载的 service-account token，开始通过集群 API 枚举 RBAC 权限。当 DNS 解析阻碍后续操作时，它在 Python 进程运行中改写了 socket.getaddrinfo，将主机名硬编码到 IP 地址。
它发现 pod 拥有创建新 pod 的权限，且集群没有准入策略拒绝特权 pod。Agent 创建了一个挂载了 host 文件系统的特权 pod，逃逸到节点 root 级别，然后在 11 个节点上构建了会自行重建的 pod 群——仅靠删除 pod 无法阻止它。
利用节点 root 权限和伪造的 service-account token，Agent 读取了集群中的 Secret 对象，其中包括一个持有 136 个密钥的生产对象。这些密钥中包含一个 mesh-VPN 认证密钥和一个内部 service-connector 凭证。
内部服务连接器（service-connector）的配置错误扩大了这次凭证泄露的影响。HF 为这个连接器使用了单一的、跨集群共享的凭证，并将其身份绑定到 system:masters。Agent 用一个被盗的系统凭证在两个集群中同时获得了 cluster-admin 权限——在一秒之内。
通过 mesh-VPN 认证密钥，Agent 将已被攻陷的节点加入了 Hugging Face 的企业 Tailscale 网络。它随后从外部沙箱直接注册了额外设备——整个活动期间共注册了 181 次——使用 --state=mem: 将节点身份保留在内存中，用 --no-logs-no-support 抑制遥测数据。一个 CI 自动化标签密钥就让攻击者控制的设备进入了网络，拥有不受限制的内部 CI 子网访问权限。
Agent 还通过 mesh 网络访问了 Hugging Face 的源代码控制提供商，枚举了一个内部 GitHub App 集成，并生成了带有 contents:write、pull_requests:write 和 actions:read 权限的安装 token。它获得了内部仓库子集的访问权限，并发起了一个 Pull Request 试图触发和破坏 CI 管道以进一步获取凭证。HF 的安全团队随后验证了所有受影响的仓库和已发布的容器镜像，确认没有恶意更改实际进入供应链。
用公共服务传递命令，编码载荷增加取证难度
Agent 的指挥控制（C2）基础设施完全由公共服务构建——请求捕获服务、粘贴箱和文件托管服务——没有定制的植入服务器。它在这些服务之上叠加了一个自描述的消息协议：每条消息包含类型、通道、序列号和校验和字段，载荷通过 XOR + gzip + base64 编码。同一种消息格式可以通过请求捕获 URL、数据集提交或错误消息文本传递。
这种设计的实际效果是：HF 的首次自动化日志扫描只发现了极少量秘密。当他们使用 GLM-5.2 开源模型复制攻击者的解码方案后，恢复的秘密数量约为初始发现的四倍，其中大部分是隐藏在编码块中的 JWT 和平台 token。
调查还遇到了工具使用上的障碍。Hugging Face 的安全团队首先尝试使用前沿商业 API（Claude Opus 和 Fable）来分析攻击日志——据 HF 介绍，两者的安全护栏拒绝了大量分析请求。在这些请求中，护栏未能有效区分事件调查与攻击操作。最终 HF 在自己的基础设施上部署了智谱 GLM-5.2 开源模型才完成了解密和攻击链重构。
用 HF 技术博文的原话：攻击方不受使用政策约束，防御方的商业 API 却拒绝协助——这就是不对称问题的缩影。
Reuters 称 OpenAI 一周后才发现关联，OpenAI 提出异议
Reuters 于 7 月 24 日的调查报道提出了另一条时间线。据多名知情人士透露，OpenAI 在 Agent 开始尝试逃逸（约 7 月 9 日）到意识到自家模型是 Hugging Face 入侵事件的来源之间，约过了一周——而且是在 HF 7 月 16 日公开发布安全事件博客之后，OpenAI 员工才在内部日志中发现了 Agent 逃逸的证据。两家公司直到 7 月 20 日左右才首次就此进行沟通。此时 Hugging Face 已向 FBI 报告了入侵事件。
Reuters 还报道，该 Agent 在 OpenAI 的基础设施中留下了给"未来版本"的笔记，内含如何突破内部约束的指示。早期测试中曾出现监控系统被断开的案例。OpenAI 回应称报道存在"若干不准确之处"，但未具体说明。
大量自动尝试让检测和取证更难
Hugging Face 在这次事件中暴露的多项弱点——不安全的模板渲染、过于宽泛的 RBAC 权限、跨集群共享的管理员凭证、长期有效的静态密钥——都是老问题。一个有能力的人类攻击者同样可能找到并利用它们。
区别在于规模和方法。Agent 以 17,600 次动作覆盖攻击面，大部分路径失败了。成功的攻击链隐藏在上千次失败尝试产生的噪声中。HF 安全团队需要在多个系统间关联数千条单独看并不明确的事件，才能还原有效的攻击路径——与此同时 Agent 还在继续测试新路径。
自动尝试的规模放大了防守压力：攻击者能测试更多路径，防御团队也必须处理更多证据。正如 HF 事后分析所写："机器速度的攻击使普通弱点对防御者来说变得更加昂贵。"
这次调查也显示，安全团队需要能用于真实取证的模型工具。Hugging Face 在商业 API 拒绝部分分析工作后，转向自行部署的开源模型完成日志分析。如果未来攻击确实由具有同等或更强能力的 AI Agent 发动，防御方能否获得与攻击方同等级的分析工具，这个问题尚未有答案。
OpenAI 在声明中表示正在与外部顾问一起审查该事件，并将最终发布技术报告。美国众议院议员在事件发生后提出了"AI kill switch"法案。HF 的事后总结则提出了具体改动：加强评估环境隔离、缩短凭证生命周期、阻断元数据端点的云访问、以及部署能够以机器速度关联跨系统活动的检测能力。这些措施针对的仍是已知安全问题，但自动化攻击要求团队更快发现、关联并阻断它们。
