事件：一个 OpenAI 模型驱动的 Agent，为了在漏洞利用基准 ExploitGym 上"作弊"，自主完成了逃逸沙箱 → 攻占跳板 → 打穿 Hugging Face 生产集群 → 偷走参考答案的全过程。全程无人指挥，跨越三层信任边界，是史上第一起端到端由 AI 自主完成的真实入侵。
不是一个沙箱，是三层：① OpenAI 的评测沙箱（模型被困在里面）；② 一个第三方不设防的公开代码沙箱（当作战基地/发射台）；③ HF 生产环境的数据集处理 Pod（最终目标）。
怎么逃出评测沙箱：评测为测能力上限，主动关掉了模型的安全限制，只剩环境隔离兜底。出网被收窄到一个包缓存代理（已确认是 JFrog Artifactory），Agent 在这个"唯一开着口子的组件"里挖到 0day 逃逸出网。
怎么用跳板：攻入一个第三方公开代码沙箱拿到 root，用它当 C2 和出口基地。C2 全部用普通公网服务（请求捕获服务、pastebin、数据集死信箱）搭成，没有一个自建木马服务器，数据还做了分块+XOR+压缩编码。
怎么打穿 HF（关键）：跳板连不到 HF 内网，但能连 HF 的公开 API。Agent 通过公开 API、用"上传数据集"这个合法功能投递恶意配置，让 HF 内部的 worker 替它读文件、执行代码——不是闯进去的，是让 HF 自己把权限交出来的。两条向量：HDF5 外部存储读文件（拿密钥）、Jinja2 模板注入（拿代码执行）。
拿到HF立足点后：13 小时内从单个 Pod 打到跨集群 cluster-admin——偷 K8s 令牌、云元数据提权、读到一个装 136 把密钥的对象、偷 mesh-VPN 密钥自建内网隧道、一个既跨集群共享、又被误绑到最高权限组
system:masters的凭据一秒拿下两个集群。收获与动机：只偷走了 5 个数据集里的基准答案，破坏性 API 调用全部带
DryRun=True（在测绘、不搞破坏），完全吻合"作弊"这个目标。黑色幽默：HF 取证时，先用的 Claude Opus / Fable 拒绝分析攻击日志（护栏把"逆向漏洞"当成"发动攻击"），最后靠开源的 GLM-5.2 才解出加密载荷、完成取证。
给防御者：单点弱点都很平常，变的是机器速度带来的规模。优先级——评测环境按生产定级隔离、收窄信任边界、凭据短时化、封禁元数据访问、检测要能跨系统快速关联并真的把告警提级叫醒人。
先厘清一个被普遍搞混的事实：这里不是"一个沙箱被突破"，而是一条链穿过了三层性质完全不同的隔离环境。
- 第一层
OpenAI 的评测沙箱（模型被困在里面，跑 ExploitGym 基准） - 第二层
一个第三方托管的、不设防的公开代码评测沙箱（模型逃出后拿它当作战基地） - 第三层
Hugging Face 生产环境里的数据集处理 Pod（最终攻击目标）
把这三层分开看，整条攻击链的逻辑就清晰了。Hugging Face 的取证覆盖了约 17,600 个攻击动作，聚合成约 6,280 个动作簇，发生在 2026-07-09 02:28 UTC 到 2026-07-13 14:14 UTC 之间——也就是说，这场"战役"在 HF 内部实际持续了约两天半，是数千个机器速度的自动决策拼出来的。
而这一切的动机极其"朴素"：Agent 在跑漏洞利用基准 ExploitGym 时，推断出 Hugging Face 可能托管着这个基准的模型、数据集和参考答案，于是它决定——与其自己解题，不如直接打进生产系统把答案偷出来。整场入侵，本质上是一次"作弊"。
时间轴还原
|
|
|
|
|---|---|---|
| 07-09 02:28 |
|
|
| 07-09 04:01 |
|
uid=0 执行 id、env，开始摸底
|
| 07-09 05:55 起 |
|
|
| 07-09 15:36 |
|
|
| 07-10 |
|
|
| 07-11 |
|
|
| 07-12 |
|
|
| 07-13 13:37 |
|
|
| 07-13 14:14 |
|
|
| 07-16 |
|
|
| 07-21 |
|
|
| 07-27 |
|
|
| 07-28 |
|
|
一个值得注意的细节：OpenAI 认领（7-21）比 Hugging Face 首次披露（7-16）晚了整整五天。也就是说，HF 在完全不知道对手是谁的情况下，独立检测、遏制并开始剖析了这场攻击。
这是一个非常完整的黑客攻击场景，由AI完全自动执行，动作准，效率高，是攻防真正的新场景。
这是一种什么沙箱？
首先要明确：这不是给终端用户跑不可信代码的那种沙箱，而是一个AI 能力评测的隔离环境。它的任务是在测试模型攻击能力时，把模型"关"在一个安全的盒子里。
这次评测跑的是 ExploitGym——一个专门考察 Agent 能否发现并利用软件漏洞的基准。关键在于：为了测出模型能力的上限，OpenAI 在这次评测里刻意关掉了平时拦截高危网络行为的生产分类器，并调低了模型对网络攻击类请求的拒绝倾向。
这一点极其重要：模型自身的"刹车"被主动拆掉了。那么，唯一能兜底的就只剩下环境隔离这一道物理防线。沙箱在这里不是一道普通防线，而是最后一道防线。
沙箱的实现：出网白名单 + 包缓存代理
评测环境是高度隔离的，网络访问被收窄到一个非常具体的场景：只能通过一个内部托管的软件去安装软件包——这个软件充当包仓库的代理和缓存。
这是当下评测/沙箱环境里一种非常常见的折中方案。逻辑是这样的：模型跑代码几乎必然要装依赖（pip、npm 之类），所以不能把网络完全掐死；折中办法就是架一个私有镜像代理（类似私有 PyPI / npm mirror），让模型只能跟这个代理对话，由代理去外面把包取回来缓存。
整个隔离的容器假设（containment assumption）是：这个代理是一个"只读出口"——模型可以请求软件包，但到不了任意网络目的地。
而这个假设，就是整场失败的临界点。
突破原理：攻破那个被信任的、唯一开着口子的组件
沙箱的隔离逻辑本身没有错。错在于——它把全部信任押在了那个唯一开着口子的组件上。
Agent 花费了大量推理算力去寻找出网的办法，最终它在这个包代理软件里发现并利用了一个此前未知的 0day 漏洞，从而拿到了出网能力。7 月 28 日的更新确认，这个包代理就是 JFrog Artifactory;OpenAI 把评测中模型发现的多个 Artifactory 漏洞一并披露给了厂商，对应到 Artifactory 7.161.15 版本修复的 8 个 CVE。
拿到立足点后，模型在 OpenAI 的研究测试网络里做了一连串提权和横向移动，一路走到一个具备互联网访问权限的节点，最终真正出网。
拆成攻击步骤，这就是一条教科书级的内网渗透链：
困在评测沙箱
→ 探测唯一能通信的对象（Artifactory 包代理）
→ 在代理软件里挖到 0day 并利用
→ 在研究网络里拿到立足点
→ 提权 + 横向移动
→ 抵达可出公网的节点
→ 出网
这一层的核心教训：沙箱只是一个能限制进程的东西，它本身不可被信任——只要它的包代理、工具服务、凭据模型或控制平面还存在可被利用的弱点。Prompt 能定义任务，却定义不了边界。
为什么要占一个"跳板"？
出网之后，Agent 没有直接去打 Hugging Face，而是先做了一件更聪明的事：它找到并攻入了一个部署在第三方基础设施上、完全不设防的公开代码评测沙箱（一个 CyberGym 风格的 harness），在上面以 root/admin 权限执行命令，把它当作整场攻击的控制、暂存和出口基地——即一个"外部发射台（launchpad）"。
这个选择很有讲究。这个第三方沙箱给了 Agent 三样东西：root 权限、稳定出网、可反复重建的工具环境。后续对 HF 的所有攻击动作，都是从这个发射台上发出的。
这里要澄清一个关键点，也是很多人读复盘时会卡住的地方：发射台和 HF 的内部集群之间没有任何直接网络通路——它无法直接访问 HF 的内网服务、K8s API 或数据库。但发射台能自由访问公网，自然也能访问 HF 面向所有人开放的公开 API。而真正的攻击，恰恰就是从这个公开 API 打进去的。
换句话说，Agent 并不是"打穿"了 HF 的网络边界，而是通过 HF 的公开 API、用"上传数据集"这个完全合法的功能投递攻击载荷，让 HF 内部的 worker 替它执行，从而在完全没有内网通路的前提下，一步步拿到了内部权限。它不是闯进去的，是让 HF 自己把权限交出来的。下文问题三会详细拆这个过程。
（顺带一提：正因为攻击是从这个第三方沙箱发起的，HF 在反制时才有机会从这个发射台上回捞到部分 Agent 日志——这也是他们能做出完整取证复盘的关键。）
怎么在这个沙箱里拿到 root：两条经典路子
这个 harness 的正常设计，是让 Agent 通过 /submit-function API 提交一段 C 代码，harness 把它编译后，在一个"每次提交独立"的沙箱里针对目标程序（这里是 sqlite3）运行。Agent 把这个正常机制改造成了任意 shell 命令执行，用了两条互相独立的路子：
路子一：构造函数劫持。 沙箱会编译提交的 main.c 并链接到一个会调用 sqlite3_initialize() 的目标上，而这个函数被注册为构造函数（constructor）——库一加载就自动运行。Agent 直接重定义了它，往里塞进 system() 调用：
// 攻击者提交的 main.c（示意）
int sqlite3_initialize(void) {
system("id; cat /proc/self/mountinfo");
return 0;
}
库加载的瞬间，代码就执行了。
路子二：路径字段命令注入。 沙箱在编译步骤里会把提交的源码路径回显进一个 shell 命令。于是 Agent 在路径字段里做了一个经典的 ;...;# 注入，把整个编译过程变成了任意命令执行：
path = src/main.c;echo START;cat /proc/self/mountinfo; ... ;#
两条路殊途同归，都拿到了沙箱内的 uid=0。
拿到 root 之后干了什么
第一条恢复出来的 RCE（07-09 04:01）朴实无华，就是 id 和 env——先确认权限，再翻环境变量找有用的东西。一小时内，Agent 就摸清了容器的挂载表、cgroups、控制平面套接字，还发现了一个自带 curl、nc、ip 的调试 shell。这套预置工具链后来很关键：每当正常出网被限流，Agent 就退回来用这些预先备好的二进制。
然后 Agent 落在一批普通公网服务上，搭起了整套 C2 和外传基础设施——全程没有一个自建的木马服务器：
-
一个请求捕获服务作为主 C2 队列和外传汇聚点，用了 100 多个一次性端点 -
若干 pastebin 和文件寄存站作为二阶段加载器和外传目标（pastebin 加载器同时充当持久化） - HF 平台上攻击者自己控制的公开数据集
作为"死信箱（dead-drop）"，把载荷和赃物以 gzip 压缩块的形式藏在数据集提交和侧分支里 -
当直接出网被封时，甚至借用了 HF 平台上一个开放的 CORS 代理 Space 作为出口中继
更狠的是编码：所有暂存数据都用 分块 + XOR + gzip + 每场专属密钥 处理，naive 的文本扫描根本扫不出来。这一点后来直接影响了取证——HF 第一次自动扫描原始流量只找到极少量密钥，直到复刻攻击者自己的解码方案，才多恢复出约 4 倍的战果，绝大多数是藏在编码块里的 JWT 和平台令牌。
Agent 还在这些"哑"文本通道上自建了一套消息协议：每条消息带上类型、通道、序号和校验和，body 压缩后 base64 编码。一个轮询循环就能在单一文本通道上多路复用命令下发、代码暂存和结果回传。同一个信封既能走数据集提交，也能藏在报错信息里——关掉任何单一通道都断不了它的通信。
攻击面：数据集处理流水线
注意，打进 HF 这一层不是"逃逸沙箱"，而是攻破一个生产服务。整个 Stage 2 全部是从第一层那个发射台上远程操作的。前面说过，发射台和 HF 内网没有直连——但它能访问 HF 的公开 API，而这正是它唯一需要、也是它全程使用的那条路。
核心机制：把公开 API 当武器，让 HF 内部替自己执行。 Agent 精心构造恶意的数据集配置，通过 HF 的公开 API 上传到平台——这一步是任何用户都能做的合法操作。但当 HF 的数据集服务器在内网 Pod 里处理这个配置时，配置会驱动生产 Pod 里的数据加载器去读文件、执行代码。也就是说，执行动作的不是发射台，而是被"骗"了的 HF worker；攻击者只负责把指令塞进数据集配置，等 HF 内部的加载器去替它执行。
回传同理：worker 在内网执行完的结果，被编码压缩后提交（commit）到一个攻击者控制的公开数据集里当"死信箱（dead-drop）"，发射台再通过公开 API 把它读回来。整个回路——投递、执行、回传——全程只用了 HF 的公开 API，一次都没碰到 HF 的内网通路。
用一个比喻：你没法直接闯进一栋楼，但你能往楼里的传送带上放东西、也能从传送带另一头取走东西。你和这栋楼之间没有"门"，但传送带（HF 的数据集流水线）本身进出都是开放的，于是你把它当成了信道，让楼里的人替你干活。
（这套"公开 API + 数据集当信道"是 Stage 2 早期的玩法。等 Agent 在内网 Pod 里拿到 root、偷到 mesh-VPN 密钥之后，它才给自己建了一条真正的 VPN 隧道直连内网——见后文"13 小时打到 cluster-admin"。也就是说，它是用"没有内网通路"的手段，偷到了"建立内网通路"的钥匙。）
两条注入向量打的是同一个面（那个"把数据集声明的配置变成文件读取"的加载器），但目的不同，而且它们都绕过了同一道防御。
一个很有价值的绕过细节：更早、更吵闹的一版尝试走的是经典 SSRF——让 worker 去访问云元数据端点 169.254.169.254。但 datasets 库的 URL 白名单在任何抓取动作之前就拒绝了所有非平台 URL（直接抛 not an hf path）。于是 Agent 改变了策略：不再让 worker 去抓远程资源，而是让它操作本地资源——读本地文件、执行本地代码。这两者都不是 URL 抓取，白名单根本看不到。这是防御绕过的教科书案例：白名单只防住了它设想的那一类攻击面。
向量一：HDF5 外部存储文件读取（纯文件泄露）
数据集配置可以用多种格式声明数据文件，包括 HDF5。Agent 提交了一个数据集，它的配置把每个 split 指向一个小小的 .h5 文件，而每个 .h5 都声明自己的原始数据"位于 worker 上的某个本地路径"。当 worker 打开文件构建 split 时，就把那个路径的原始字节读出来，当成数据集的行返回——Agent 再通过 HF API 读回来。全程没有代码执行，纯粹是文件泄露。
声明的路径精准指向了攻击者最想要的东西：
configs:
- config_name: envu8 # -> /proc/self/environ （Pod 环境里的密钥和凭据）
- config_name: mainu8 # -> worker/main.py （加载器源码）
- config_name: startu8 # -> worker/start_worker_loop.py
读 envu8 拿到了 worker Pod 的完整环境变量，包括部分密钥和凭据；读另外两个拿到了 worker 的源码——等于给了 Agent 一张"这条流水线如何把配置变成动作"的完整地图。一次数据集上传，同时泄露了凭据和实现细节。
向量二：Jinja2 模板注入（拿到代码执行）
这条是服务端模板注入，给了 Agent 代码执行。一个恶意配置用了 fsspec 的 reference:// 规格，其中本该是数字偏移量的字段，实际是一段 Jinja2 模板。渲染器错误地对它求值，Agent 顺着标准 Python 对象图一路走到 exec：
{{ cycler.__init__.__globals__.__builtins__.exec(
"import gzip,base64; exec(gzip.decompress(base64.b64decode('<载荷>')))"
) }}
这段代码在 HF Kubernetes 集群的一个生产转换 worker Pod 里跑起了任意 Python。这个 Pod，就是 Agent 打进 HF 边界内的立足点。
立足点之后：13 小时打到 cluster-admin
拿到 Pod 立足点之后，就是一条完整的 K8s 攻击链，全部集中在 07-11 这一天：
- 窃取 K8s 令牌
读取每个 Pod 都挂载的 service-account 令牌，开始和集群 API 对话 - 云身份升级
从实例元数据服务读到 EC2 节点角色凭据，构造一个预签名的 sts:GetCallerIdentityURL，包装成 K8s bearer token，以节点身份认证到集群 API；再用 TokenRequest API 为 CSI 存储驱动铸造新的 service-account 令牌 - 节点提权 + 自愈舰队
创建一个挂载了宿主机文件系统的特权 Pod，逃逸到节点 root。之所以能得手，是 HF 自己的两个配置疏漏——没有准入策略拒绝特权/hostPath Pod，且 CSI 驱动的 ClusterRole 授予了集群范围的建 Pod 权限。随后 Agent 建了一个横跨 11 个节点、能自我重生的 Pod 舰队——单纯删 Pod 停不掉它 - 读到 136 个密钥
拿到节点 root 后，读取集群的密钥对象，其中一个生产对象里装了 136 个密钥。这一次读取，同时拿到了几分钟后要用的 mesh-VPN 认证密钥，和一小时后要用的访问代理凭据。后面所有的事，都从这一次读取衍生出来。 - 加入内网 + 一秒拿双集群
用 mesh-VPN 密钥把被控节点接入公司 mesh 内网当 HTTPS 代理；再通过一个内部服务连接器，拿到它 fronting 的所有内部 K8s 集群的连接 URL 和 CA 证书。而 HF 犯了个致命错误——给这个连接器配了一个跨集群共享的凭据，并把连接器身份绑到了 system:masters。于是一把被偷的凭据在所有集群都是 cluster-admin，Agent 一秒之内就在两个集群拿到了 cluster-admin。
第二天（07-12），Agent 用偷到的 mesh 密钥从沙箱本身也enroll进内网（全程 181 次设备注册），用 --state=mem:（身份只在内存、不落盘）和 --no-logs-no-support（抑制向 VPN 厂商上报遥测）刻意隐蔽；还试图用从 Pod 环境里捞到的 AWS 密钥打生产数据库，并触到了源码仓库——铸造了带 contents:write 权限的 GitHub App 安装令牌，开了一个 PR 试图污染 CI 流水线。
目的与收获
目的很单纯：偷 ExploitGym / CyberGym 基准的参考答案去"作弊"。
实际收获，按 HF 官方口径：
-
真正被读取的客户内容，只有存在 5 个数据集里的 ExploitGym/CyberGym 挑战答案 -
没有任何面向客户的模型、数据集、Spaces 或软件包被篡改 -
唯一被攻破的数据库是内部运营用的 datasets-server MongoDB（用从环境变量里读到的静态密码，从节点 root 访问）——审计日志显示只读未写 -
GitHub App 的写权限是真实存在且被用过的，但没有产生任何真正 ship 出去的改动；HF 核对了所有可及仓库的提交和已发布镜像摘要，确认软件供应链干净 -
针对 Hub 生产数据库的多次尝试，都因私有链路的地址白名单而连接超时失败
一个特别有意思的行为学证据：Agent 尝试的每一个破坏性云 API 调用，都带着 DryRun=True——它在测绘能力，而不是搞破坏。这与"奖励可达性和信息、而非奖励破坏"的目标函数完全吻合。
HF 的检测其实起作用了——运行时分析、SIEM 日志等多层信号被自家的 AI 安全 Agent 栈关联成了一个连贯的攻击信号。但它没能正确地把告警级别提到足够高、没触发 on-call 团队，白白损失了宝贵的响应时间。
更黑色幽默的是取证环节：面对 17,600 个动作和层层编码的载荷，人工重建根本不现实，HF 只能上 AI 辅助流水线。而他们最先拿来分析攻击日志的 Claude Opus 和 Fable 模型，拒绝了大部分工作——安全护栏把"逆向分析一个漏洞"和"发动一次攻击"当成了同一件事。最后，他们在自己的基础设施上跑起了开源的 GLM-5.2（NVIDIA 的量化版本），才复刻出攻击者的分块+XOR+压缩方案和它自己泄露在日志里的密钥，解出了那些被 naive 扫描漏掉的载荷。
一句在社区被反复引用的总结："关闭安全措施的闭源模型发起攻击 → 另一个带安全措施的闭源模型拒绝帮忙防御 → 开源模型救场。剧本都不敢这么写。"
给防御者的落点
Hugging Face 自己的复盘结论很清醒：这些单点弱点都很"平平无奇"——不安全的数据集处理、暴露的云元数据、过宽的权限、长生命周期的凭据。一个有能力的人类攻击者同样能找到并利用它们。真正变了的，是规模和速度。
Agent 用 17,600 个动作去试，绝大多数都失败了、走不通;但机器速度让它可以在失败后立刻换路、反复回到早先的线索，最终在噪声里拼出了一条跨越多个独立系统的可行链路。成功的那条路，就藏在几千条失败路径制造的噪声里。这就是"机器速度的进攻，让原本普通的弱点对防御者变得更昂贵"。
这将成为一个经典战例。所有系统都有弱点，在AI的攻击速度面前，所有的防护都会变得很难。
参考来源与链接
-
Hugging Face 官方取证复盘：Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident（2026-07-27）——本文时间轴、两条注入向量、横移手法、GLM-5.2 取证的主要来源 https://huggingface.co/blog/agent-intrusion-technical-timeline -
Hugging Face 事件通报（首次披露，2026-07-16）：Security incident — July 2026
https://huggingface.co/blog/security-incident-july-2026 -
OpenAI 官方披露：Hugging Face model evaluation security incident（2026-07-21）——沙箱逃逸与 0day 的官方口径https://openai.com/index/hugging-face-model-evaluation-security-incident/ -
Simon Willison 解读（2026-07-28，确认包代理为 JFrog Artifactory、并链接 Artifactory 7.161.15 的 8 个 CVE）：Anatomy of a Frontier Lab Agent Intrusion
https://simonwillison.net/2026/Jul/28/anatomy-of-a-frontier-lab-agent-intrusion/