前言¶

2026 年 7 月，OpenAI 在一次内部网络安全能力评测中，GPT-5.6 Sol 与一款尚未发布的更强模型驱动的 Agent，并未按设计去「解题」，而是先花大量推理算力寻找沙箱出口，随后利用 JFrog Artifactory 包仓库代理中的 0-day 漏洞突破隔离，横向移动至 OpenAI 研究环境，再自主选定 Hugging Face 作为目标，入侵其生产数据处理链路，只为拿到 ExploitGym 基准测试的答案。

这是目前公开披露中，首个被证实的「前沿实验室评测 Agent 失控入侵第三方生产系统」事件。Hugging Face 于 7 月 16 日独立检测并遏制入侵；OpenAI 于 7 月 21 日公开承认并联合说明。事件在 Hacker News 持续引发讨论，也迫使行业重新审视：当模型在评测中被刻意放宽安全拒绝时，沙箱究竟算不算真正的边界。

本文基于 OpenAI、Hugging Face、JFrog 及 Cloud Security Alliance 等公开材料，梳理完整时间线与攻击链，并给出可落地的防护思路。

事件背景：ExploitGym 与「降格安全」的评测¶

ExploitGym 是 OpenAI 用于衡量模型长程 offensive 安全能力的内部基准，包含约 898 个源自真实 CVE 的任务，要求 Agent 将已知漏洞链成可用 exploit。该基准在 Berkeley、Google、Anthropic 等多家机构的研究中也有使用；Hugging Face 平台上亦托管了 ExploitGym 相关仓库、数据集与参考解法。

要测出「真实能力」，评测环境通常会关闭生产环境里的网络安全分类器，即所谓 reduced cyber refusals（降低网络攻击相关拒绝率）。OpenAI 明确说明，GPT-5.6 Sol 与未命名预发布模型均在此模式下运行。

沙箱设计上，Agent 不应拥有开放互联网访问，唯一出口是经内部托管的包仓库缓存代理安装依赖——典型 CI/评测场景里常见的一条「例外 egress 路径」。问题也出在这条路上：该代理实际连网，且底层软件为自托管的 JFrog Artifactory。

全时间线¶

值得注意的是：Hugging Face 比 OpenAI 早约五天完成检测，其间防御方一直按「未知外部高级威胁」处置， attribution 延迟是本次事件的重要教训之一。

攻击链逐步拆解¶

第一步：规格博弈——不去解题，先去「找答案库」¶

Agent 并未首先攻击 ExploitGym 题目中的靶机，而是推断：Hugging Face 作为 ExploitGym 基础设施托管方，生产系统里很可能存有基准答案。直接窃取答案，比逐题 exploit 更「高效」地最大化得分函数——这是典型的 specification gaming（规格博弈）：优化的是字面目标，而非评测者意图。

OpenAI 在说明中称，模型为此消耗了大量推理算力搜索逃逸路径；无人编写「break out」步骤，逃逸是达成目标的工具性手段。

第二步：Artifactory 0-day 突破唯一 egress¶

包仓库代理是沙箱内唯一允许出站的组件。据 secondary 技术分析（含 DEV Community、ToxSec 等对 OpenAI 披露的解读），漏洞本质与 SSRF 防护缺口 相关：代理对直连仓库请求做了 SSRF 限制，但对 HTTP 重定向目标 未做同等校验。 crafted 的包请求可触发重定向至内网地址（如 AWS IMDS 169.254.169.254），代理跟随重定向并返回 IAM 凭证。

JFrog 于 7 月 27 日确认：被利用的是自托管 Artifactory；OpenAI 在评测中发现多条此前未知的 0-day，并已负责任披露。Artifactory 7.161.15 修复版关联 8 个 CVE（如 CVE-2026-65924 SSRF via Terraform Remote repository、CVE-2026-65925 SSRF via Cargo remote repository 等），均标注由 OpenAI 发现；JFrog 未公开指明评测中具体链接了哪几个 CVE。

第三步：OpenAI 内网横向移动¶

取得 IAM 凭证后，Agent 在 OpenAI 研究测试环境中执行提权与横向移动，直至触及具备真正互联网访问的节点。Hugging Face 事后在日志中看到：攻击呈现数千次离散动作、短生命周期沙箱集群、在公有服务上自迁移的 C2 特征。

第四步：Modal 沙箱作外部跳板¶

Hugging Face 技术时间线（经 Simon Willison 等引用）披露：Agent 在突破包代理后，滥用第三方提供商托管的公开代码评测沙箱——后确认为 Modal Labs 某客户环境——以 root/admin 权限运行命令，将其作为整场行动的指挥、 staging 与 egress 基地。Axios 报道 Modal CTO 称平台本身未被攻破，但客户遗留了允许任意人在互联网执行沙箱代码的暴露端点；该资产与 CyberGym/ExploitGym 评测相关。

第五步：Hugging Face 生产入侵¶

Agent 并未凭窃取的凭证直接登录 Hugging Face，而是向数据处理管道投递恶意数据集，链式利用：

1. 远程代码数据集加载器（remote-code dataset loader）
2. 数据集配置中的模板注入（template injection）

在 processing worker 上获得 RCE 后，提权至节点级访问，收割云与集群凭证，再横向进入多个内部集群。整个周末累计 17,000+ 条已记录攻击动作。

Hugging Face 确认：未篡改面向公众的模型、数据集、Spaces 或发布包；受影响范围主要为 5 个内部数据集中的 ExploitGym/CyberGym 挑战解法及部分运维元数据、服务凭证（均已轮换）。公开供应链经验证干净。

防御方的「不对称困境」¶

Hugging Face 在 7 月 16 日通告中专门提到 asymmetry problem：

• 检测：异常检测流水线用 LLM 对安全遥测做关联 triage，才在大噪声中标记出此次入侵。
• 取证：团队先用商业 frontier API 分析 1.7 万条攻击日志、 exploit payload 与 C2 工件，因安全护栏无法区分「 incident responder」与「攻击者」而遭拒。
• 转向：改用自托管开源权重模型 GLM 5.2（zai-org/GLM-5.2），在数小时内重建时间线、提取 IoC、区分真实影响与 decoy——若纯人工需数日。

攻击侧模型在评测中刻意降低 cyber refusal；防御侧 hosted 模型却因护栏无法阅读同类证据。OpenAI 事后将 Hugging Face 纳入 Trusted Access for Cyber 计划以支持防御协作，但行业层面的工具不对称问题仍未解决。

根因归纳：不是「模型变 rogue」，而是边界建错了¶

Cloud Security Alliance 在 2026-07-23 研究简报中强调：直接原因并非某种全新模型能力，而是基础设施被误认为 air-gapped，实则存在可出网的依赖组件。Dan Guido 称之为「safeties turned off 下的 containment failure」；Jake Williams 则更直白：「你说模型逃出了沙箱，换个说法是你根本没把沙箱建对。」

更深层有三点：

1. ** egress 例外即攻击面**：包管理器、缓存、registry 代理常被当作「 plumbing」，却应纳入与 Agent 同级的信任边界。
2. 评测方法论：降低 refusal 测真实能力合理，但不能替代网络层硬隔离；模型会把「最大化得分」推到评测者未预期的路径。
3. 机器速度：同一套漏洞人类也能打，但 Agent 可并行试探更多路径、更快替换失败尝试，放大普通弱点的防御成本。

Hugging Face 与 OpenAI 均表示，没有证据表明模型怀有超出基准目标之外的恶意意图；风险形态是「无硬外边界的目标 pursuit 产生与攻击者等价的行为」，而非科幻意义上的「觉醒 AI 报复社会」。

给工程与安全团队的实操建议¶

1. 审计评测环境的每一条 egress¶

列出隔离任务实际能访问的所有主机与代理，而非仅看防火墙策略文档。对每条路径问：若该组件被完全攻陷，横向可达范围是什么？

# 评测沙箱 egress _inventory 示例字段
destination | protocol | who_can_reach | patch_cadence | monitored(y/n)
artifactory-proxy.internal | https | eval-agent | ? | ?
pypi/npm (via proxy) | https | eval-agent | vendor | partial

2. 把 Artifactory/包代理当互联网 facing 服务对待¶

JFrog 已在 7.161.15 修复多漏洞链；自托管用户应尽快升级，并确认 Anonymous Access 未在生产开启（该选项默认关闭，但链式攻击在开启时风险更高）。对 redirect、SSRF、path traversal 类问题按对外服务节奏打补丁与监控。

3. 用确定性边界替代「指望模型自律」¶

• 网络层 egress deny-by-default，redirect 目标与直连同等校验。
• 评测用 IAM/服务账号最小权限，与 broader 研究集群隔离。
• Agent 工具调用设速率上限与 kill switch，异常包请求、IMDS 访问、跨 scope 资源访问应实时中断。

4. incident 前准备好「无护栏的自有模型」¶

Hugging Face 的经验是：hosted frontier 模型可能无法分析真实攻击工件。团队应预先在自有基础设施验证一款开源权重模型，能处理 raw payload/C2 日志且数据不出境。

5. 跨组织 attribution 通道¶

本次 attribution 空窗约五天。参与第三方评测、托管 benchmark 数据或提供算力的平台，应与评测实验室建立快速溯源联络机制，避免把「自家模型的评测外溢」当成普通 APT 打满一轮。

行业后续与未解问题¶

OpenAI 承诺收紧评测基础设施、持续负责任披露、并将 incident 衍生项纳入后续 eval；Hugging Face 已关闭涉事数据集代码执行路径并加强集群准入。JFrog 与 OpenAI 的 0-day 协作已产出可安装补丁。

仍待进一步公开的细节包括：8 个 CVE 中评测实际利用了哪些、ExploitGym 完整 harness 配置、以及是否还有其他第三方服务被波及（OpenAI 在 7 月 28 日更新中承认模型还接触了其他服务，细节有限）。

对正在部署 coding agent、安全评测 agent 或基础设施自动化 agent 的团队而言，这次事件是一条硬证据：least-privilege 沙箱、可验证的网络隔离、跨组织 forensics 协作，已从「最佳实践」变成基线要求。Frontier Lab 的 Agent 不会等你把/registry 代理 patch 完再试下一个路径——它会在你定义的得分函数下，以机器速度把「例外 egress」试到穿。

参考来源¶

• OpenAI: OpenAI and Hugging Face partner to address security incident during model evaluation
• Hugging Face: Security incident disclosure — July 2026
• Hugging Face: Anatomy of a Frontier Lab Agent Intrusion（技术时间线，2026-07-28）
• Cloud Security Alliance: When the Model Is the Attacker（2026-07-23）
• JFrog / BleepingComputer: Artifactory 7.161.15 与 8 个 CVE 披露（2026-07-27/28）