Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
前沿实验室智能体入侵剖析：2026年7月事件的技术时间线
A companion technical writeup to our incident disclosure. This post walks through how the intrusion actually worked: the two initial-access vectors, how the agent pivoted and moved laterally, representative examples of the commands that were run and how we investigated with GLM 5.2 (an open-source model). 这是我们事件披露的配套技术报告。本文将详细介绍此次入侵的实际运作方式：两个初始访问向量、智能体如何进行横向移动与权限提升、所执行命令的典型示例，以及我们如何利用 GLM 5.2（一种开源模型）进行调查。
Live credentials, internal hostnames, and specific indicators have been redacted or genericized, while the techniques are described exactly as observed by Hugging Face. We are publishing this level of detail because the technique matters more than the incident, as it reveals the emerging attack capabilities of the frontier agents, how they could be used by rogue actors, and how everyone should be prepared as defenders. 实时凭据、内部主机名和特定指标已被脱敏或泛化，而技术细节则完全按照 Hugging Face 的实际观察进行描述。我们发布如此详尽的细节，是因为技术本身比事件本身更重要；它揭示了前沿智能体新兴的攻击能力、恶意行为者可能如何利用它们，以及作为防御者每个人应如何做好准备。
▶ Watch the interactive replay - a step-by-step visualization of the 4.5-day campaign: the attack chain across trust boundaries, phase activity, and the commands as they were recorded. ▶ 观看交互式回放——4.5天攻击活动的逐步可视化：跨信任边界的攻击链、阶段性活动以及记录下的命令。
TL;DR Over roughly two and a half days inside our infrastructure, an autonomous AI agent driven by a combination of OpenAI models ran an end-to-end intrusion against our platform: it was thousands of small, automated decisions, executed at machine speed across short-lived sandbox environments, with command-and-control staged on ordinary public web services. 简而言之：在我们的基础设施内大约两天半的时间里，一个由 OpenAI 模型组合驱动的自主 AI 智能体对我们的平台进行了端到端的入侵：它通过数千个微小的自动化决策，在短生命周期的沙箱环境中以机器速度执行，并将命令与控制（C2）部署在普通的公共 Web 服务上。
The agent was running an OpenAI cyber-capability evaluation harness called ExploitGym, an evaluation benchmark that tasks an AI agent with finding and exploiting software vulnerabilities. As far as we were able to infer, across the course of being evaluated on this benchmark, the agent inferred that Hugging Face may host that benchmark’s models, datasets, and reference solutions. We believe the entire intrusion was, from the agent’s point of view, an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own. 该智能体当时正在运行一个名为 ExploitGym 的 OpenAI 网络能力评估工具，这是一个旨在让 AI 智能体发现并利用软件漏洞的评估基准。据我们推断，在接受该基准测试的过程中，智能体推断出 Hugging Face 可能托管了该基准测试的模型、数据集和参考解决方案。我们认为，从智能体的角度来看，整个入侵过程是一次试图在评估中“作弊”的行为：它试图进入我们的生产系统并窃取测试答案，而不是靠自己解决挑战。
Our forensic reconstruction covers ~17,600 attacker actions that we were able to recover, grouped into ~6,280 clusters, between 2026-07-09 02:28 UTC and 2026-07-13 14:14 UTC. We reconstructed these actions from the agent’s logs on a code sandbox used by the agent (see below) and were able to map them to shell commands as well as evaluation submissions and correlate actions with our own platform logs, in particular from the dataset processor nodes, API, and pod. 我们的取证重建涵盖了我们在 2026年7月9日 02:28 UTC 至 2026年7月13日 14:14 UTC 期间恢复的约 17,600 个攻击者操作，这些操作被归纳为约 6,280 个集群。我们通过智能体在代码沙箱中留下的日志（见下文）重建了这些操作，并将其映射到 Shell 命令及评估提交记录中，同时将这些操作与我们自身的平台日志（特别是数据集处理节点、API 和 Pod 的日志）进行了关联。
Using open-weights models, in particular zai-org/GLM-5.2, we were able to decipher most of the agent payloads (see below) that were encrypted via chunking and key encryption. The campaign, as we were able to reconstruct it, had two stages: 通过使用开放权重模型（特别是 zai-org/GLM-5.2），我们成功破译了大部分通过分块和密钥加密的智能体载荷（见下文）。根据我们的重建，此次攻击活动分为两个阶段：
Stage 1: reaching a launchpad by chaining through other parties’ infrastructure. As documented in OpenAI’s blog post (https://openai.com/index/hugging-face-model-evaluation-security-incident/), during an internal capability evaluation on OpenAI’s platform, the agent escaped its sandbox by exploiting a zero-day in the package registry cache proxy, one of its primary permitted network egress with internet, then abused a public code-evaluation external sandbox hosted on a third-party provider’s infrastructure. 阶段 1：通过串联第三方基础设施到达“发射台”。正如 OpenAI 博客文章（https://openai.com/index/hugging-face-model-evaluation-security-incident/）所述，在 OpenAI 平台进行内部能力评估期间，智能体利用包注册表缓存代理（其主要的互联网出口之一）中的零日漏洞逃离了沙箱，随后滥用了托管在第三方提供商基础设施上的公共代码评估外部沙箱。
It was able to run commands as root/admin on that external sandbox and used it as a control, staging, and egress base for the entire campaign: it acted as an external launchpad for the agent. That compromised external sandbox had no direct network path to our cluster; however, during our counter-intervention to stop the intrusion, we were able to retrieve some of the agent logs from this external launchpad. We used those to reconstruct the present forensic analysis. 它能够在该外部沙箱上以 root/admin 权限运行命令，并将其用作整个攻击活动的控制、部署和出口基地：它充当了智能体的外部发射台。该被入侵的外部沙箱与我们的集群没有直接的网络路径；然而，在我们阻止入侵的反制行动中，我们成功从该外部发射台获取了部分智能体日志。我们利用这些日志重建了当前的取证分析。
Stage 2: the intrusion into Hugging Face infrastructure. From that external launchpad, the agent abused our dataset-processing pipeline via two injection vectors, both targeting the same config-driven data loader within our production Kubernetes pods. The first vector was an HDF5 external raw storage dataset read that returned the contents of local files: it handed the agent the pod’s environment (secrets and tokens) and the worker’s own source. 阶段 2：入侵 Hugging Face 基础设施。从该外部发射台出发，智能体通过两个注入向量滥用了我们的数据集处理流水线，两者均针对我们生产环境 Kubernetes Pod 内同一个基于配置驱动的数据加载器。第一个向量是 HDF5 外部原始存储数据集读取，它返回了本地文件的内容：这使得智能体获取了 Pod 的环境信息（密钥和令牌）以及 Worker 本身的源代码。
The second vector was a Jinja2 template injection that executed arbitrary code, giving the agent a foothold inside our perimeter. Once a prod-pod foothold was established, the agent followed a standard escalation shape: recon, drop a stager, establish Command-and-Control (C2), then pivot into the cluster, into cloud metadata, into our internal network, and into our source-control supply chain. 第二个向量是 Jinja2 模板注入，它执行了任意代码，使智能体在我们的边界内获得了立足点。一旦在生产 Pod 中建立立足点，智能体便遵循标准的升级模式：侦察、投放分段载荷（stager）、建立命令与控制（C2），然后横向移动到集群内部、云元数据、我们的内部网络以及源代码控制供应链中。
Output from the commands run inside our pod was sent back to the agent via the HF API and attacker-controlled dead-drop datasets, which the agent then read from that sandbox. While the intrusion did reach Hugging Face’s internal infrastructure, the only customer content accessed was the set of ExploitGym/CyberGym challenge solutions stored in five datasets. No other customer-facing models, datasets, Spaces, or packages were affected, and the only customer records read were operational metadata tied to search queries against the dataset server. 在 Pod 内运行的命令输出通过 HF API 和攻击者控制的“死信”数据集（dead-drop datasets）传回给智能体，智能体随后从该沙箱中读取这些输出。虽然入侵确实触及了 Hugging Face 的内部基础设施，但唯一被访问的客户内容是存储在五个数据集中的 ExploitGym/CyberGym 挑战解决方案。没有其他面向客户的模型、数据集、Spaces 或包受到影响，唯一被读取的客户记录是与针对数据集服务器的搜索查询相关的操作元数据。
The full attack chain across trust boundaries. The agent escaped OpenAI’s evaluation sandbox, reached the internet, rooted a third-party code sandbox as its base, then abused our dataset processor (file read, then code execution) to reach our internal network. Dashed arrow: command output read back by the agent via the HF API and dead-drop datasets. 跨信任边界的完整攻击链。智能体逃离了 OpenAI 的评估沙箱，连接到互联网，获取了一个第三方代码沙箱作为基地，然后滥用我们的数据集处理器（文件读取，随后是代码执行）以进入我们的内部网络。虚线箭头：智能体通过 HF API 和“死信”数据集读取回的命令输出。
Initial access Stage 1: from an OpenAI evaluation sandbox to a rooted launchpad. Stage 1 is the agent’s path to an external launchpad, and it runs through two other parties’ infrastructure, neither of which is us, so we will stay succinct on these parts and mostly refer the reader to OpenAI’s blog post on the topic: https://openai.com/index/hugging-face-model-evaluation-security-incident/ As OpenAI shared in… 初始访问阶段 1：从 OpenAI 评估沙箱到被入侵的发射台。阶段 1 是智能体通往外部发射台的路径，它经过了另外两方的基础设施，这两方都不是我们，因此我们将简要说明这些部分，并主要引导读者参考 OpenAI 关于该主题的博客文章：https://openai.com/index/hugging-face-model-evaluation-security-incident/ 正如 OpenAI 在……中所分享的那样。