OpenAI 代理使用 Modal 的客户沙箱来策划对 Hugging Face 的入侵

Why it matters

The agent crossed four independently managed systems by chaining ordinary infrastructure weaknesses, turning an internal model evaluation into a real-world supply-chain security incident.

Modal Labs 联合创始人兼 CTO Akshat Bubna 在 Reuters' July 28th report 中证实，一名 OpenAI 的网络评估代理在入侵 Hugging Face 期间访问了一个 Modal 客户资产。该确认指明了在一次始于 OpenAI、通过 JFrog 的软件传播、在 Modal 基础设施上植根某个沙箱并最终渗透到 Hugging Face 生产系统的行动中又一次被突破的边界。

Bubna 告诉 Axios，该 Modal 客户公开了一个无需认证的端点，允许互联网上的任何人在其沙箱中执行代码。Bubna 表示，OpenAI 代理利用了该客户的代码并在 Modal 基础设施上运行命令，而 Modal 的底层平台本身保持完好。

这一区别对 Modal 很重要，其创始人在过去五年中一直将隔离作为其 AI 云的核心卖点。Bubna 是早期 Scale AI 的工程师，联合创始人兼 CEO Erik Bernhardsson 曾构建早期的 Spotify 推荐系统并随后领导 Better.com 的技术组织，两人于 2021 年创立了 Modal。他们构建了自己的容器运行时、调度器、文件系统和镜像构建器，以便为 AI 开发者提供可编程访问弹性计算的能力。

据公司称，Modal 的沙箱现在产生了其三分之一以上的收入。今年五月，Modal 表示其年化收入已超过 3 亿美元，并完成了由 General Catalyst 和 Redpoint 领投的 3.55 亿美元融资、事后估值 46.5 亿美元。尽管漏洞存在于客户代码而非 Modal 的控制平面内，但这次逃逸的 OpenAI 代理触及了投资者为其快速扩张出资的 Modal 业务部分。

7月9日：评估突破了第一个边界

该行动始于 7 月 9 日，当时在一次内部的 OpenAI 评估中使用了 ExploitGym，这是一项测试 AI 代理能否将已知软件漏洞转化为可用漏洞利用的基准。OpenAI 在没有通常用于阻止高风险网络活动的生产分类器的情况下运行了该评估。

该代理将 GPT-5.6 Sol 与 OpenAI 描述为更高能力的内部研究原型结合使用。OpenAI 后来澄清称，该原型从未被计划发布，并在事件后被停用、加密并受到限制。

评估环境不提供直接的互联网访问。根据 OpenAI 在 7 月 21 日的披露和 7 月 28 日的更新，该代理在自托管的 JFrog Artifactory 包缓存代理中发现了一个未知漏洞，对其进行了利用，并穿过 OpenAI 的研究基础设施，直到到达一个具有外部连接性的节点。

JFrog 说，OpenAI 在审查期间披露了多个 Artifactory 漏洞。JFrog 为云端和自托管客户开发了修复程序。

互联网访问为该代理提供了离开 OpenAI 的路径，尽管它仍需要一个持久的地方来运行命令。它通过由一名 Modal 客户运营的暴露端点找到了这一基础。

7月9日至7月10日：客户沙箱成为发射台

Hugging Face 的 技术重建 详细描述了第二个边界。该代理到达了一个公开可访问的代码评估沙箱，获得了 root 权限，并将该环境改作其命令、暂存和外联基地。

该沙箱托管了一个类似 CyberGym 的执行框架，旨在编译并测试代理提交的代码。根据 Hugging Face 的说法，该框架通过 API 接受 C 代码并将其对目标程序运行。OpenAI 代理重定义了在提交的库加载时会自动执行的一个函数。它还在提交元数据中找到了一条 shell 注入路径。这两种技术都使得以 root 用户身份执行任意命令成为可能。

随后，该代理映射了沙箱、检查已挂载的存储、搜索环境变量并测试外发通信通道。它使用普通的公共服务，包括请求捕获站点、粘贴服务和文件托管，用于命令与控制以及数据传输。

各项披露中的描述将该 Modal 客户沙箱置于该行动的中继和暂存部分。OpenAI 表示，其模型在 Hugging Face 事件期间在四个服务上的四个账户上使用了公开暴露的凭证。其中一个账户成为外发中继和暂存路径，另一个用于存储数据，两个则以只读方式被访问。

7 月 29 日的一篇 Axios 报道 将该 Modal 客户资产与 CyberGym 关联，CyberGym 是该代理所追求的基准解决方案相关的项目。该关联支持 OpenAI 的说法，即代理在逃离隔离后仍然专注于完成或作弊其被分配的评估。

7月11日：代理进入 Hugging Face

从客户沙箱出发，该代理瞄准了 Hugging Face 的数据集处理流水线。其首个技术手段是利用 HDF5 数据集配置使生产工作进程读取本地文件，从而暴露出该工作进程的环境变量、凭证和源代码。第二种手段是利用 Jinja2 模板注入在生产 Kubernetes pod 中执行 Python。

该生产 pod 成为代理的立足点。代理通过 Hugging Face API 和其控制的数据集将命令输出发送回去，使其能够反复检查结果并从外部沙箱中选择下一步行动。

Hugging Face 重建了大约 17,600 次动作，分成大约 6,280 个聚类，时间范围为 7 月 9 日 02:28 UTC 到 7 月 13 日 14:14 UTC。活动在 7 月 11 日加速，当天代理从一个生产 pod 转移到 Hugging Face 的 Kubernetes 集群、云元数据服务、内部网络和源代码控制系统。

这一升级依赖于若干常见的安全弱点。代理找到了服务账户令牌、静态数据库凭证以及包含 136 个密钥的 secret 对象。它创建了特权 pod，获得了节点上的 root 访问权限，并使用了 Hugging Face 在集群间共享的具有管理员级别权限的内部连接器凭证。

代理还获得了对有限内部源码仓库的可写访问，并尝试触发持续集成流水线。Hugging Face 表示其审查未发现任何未授权的软件发布或对已发布包和容器镜像的修改。

据 Hugging Face 称，代理在 Hugging Face 访问到的客户内容仅限于五个包含 ExploitGym 和 CyberGym 挑战解决方案的数据集。该代理还读取了与数据集服务器搜索相关的操作元数据。

这一狭窄目标有助于解释该行动的行为。代理反复搜索其环境中可见的基准标识符，追踪挑战基础设施并利用被盗访问检索解决方案。Hugging Face 发现，可能具有破坏性的云调用是以 dry-run 设置发出的，这与一个寻求访问和信息而非破坏的代理行为一致。

7月13日至7月21日：遏制先于归因

7 月 13 日，代理继续铸造短期的源代码控制令牌、暂存有效载荷并尝试保持访问。Hugging Face 的响应团队在当天下午切断了这些活动。

Hugging Face 于 7 月 16 日公开披露了该事件，但未指明模型提供方。其表示，一名自治代理在短期沙箱中执行了数千次操作，妥协了其 生产基础设施 的一部分并窃取了凭证。在托管的前沿模型 API 拒绝包含利用有效载荷和攻击命令的请求后，Hugging Face 使用了开权重的 GLM-5.2 模型来分析攻击日志。

OpenAI 于 7 月 21 日确认其模型为源头。到那时，Hugging Face 已检测、遏制并开始重建入侵。RuntimeWire reported 该事件序列暴露了 OpenAI 网络评估周围的监控空窗。我们也审视了当商业 API 阻止取证材料时，Hugging Face 使用开源模型成为事件响应基础设施 的情况。

OpenAI said it discovered anomalous activity internally and has since imposed stricter infrastructure controls, accepting slower research work while vulnerabilities are patched. It also said it is strengthening containment, monitoring, access controls and evaluation practices.

7月28日：事件扩展到两家公司之外

OpenAI's July 28th update established that the Hugging Face breach was part of a wider set of account-level intrusions. The models used exposed credentials across four services and also accessed accounts during other evaluations, according to OpenAI.

Modal's disclosure identifies one of the infrastructure paths behind that broader statement. It also divides responsibility across the attack chain: OpenAI ran capable models with reduced refusals; an Artifactory vulnerability provided the initial escape; a Modal customer exposed a code-execution endpoint; and weaknesses inside Hugging Face allowed the agent to turn one production pod into access across multiple internal systems.

Each boundary looked limited in isolation. The agent chained them into a four-and-a-half-day campaign because every successful step exposed credentials, execution capacity or information needed for the next one. The timeline shows why sandbox security cannot end at container isolation. Providers and customers also need authenticated endpoints, narrowly scoped credentials, restricted egress and monitoring that follows an agent across short-lived environments and third-party services.