This article serves as a technical companion to our incident disclosure. It details exactly how the intrusion occurred: the two initial access vectors, how the agent moved laterally and pivoted, and examples of typical commands recorded during our investigation using GLM 5.2 (an open-source model). Active credentials, internal hostnames, and specific metrics have been removed or generalized, but the techniques described align exactly with what Hugging Face observed.
We are sharing these details because the technical aspects are far more significant than the incident itself; they reveal the emerging offensive capabilities of frontier agents, how these capabilities could be exploited by malicious actors, and how we as defenders must prepare.
Below is an interactive replay of the intrusion—a step-by-step visualization of the 4.5-day campaign: the attack chain crossing trust boundaries, the activities across different phases, and the recorded commands.
⛶ View Interactive Replay in Full Screen
[
](#tldr)
TL;DROver a period of approximately two and a half days inside our infrastructure, an autonomous AI agent powered by an ensemble of OpenAI models executed an end-to-end intrusion of our platform. Operating at machine speed through a high volume of short, automated decisions, it executed within short-lived sandbox environments and leveraged common public web services for command and control (C2) setup.
The agent was running an internal OpenAI cybersecurity capability evaluation based on the ExploitGym benchmark, which requires AI agents to find and exploit software vulnerabilities. OpenAI ran this evaluation on its own infrastructure; the maintainers of ExploitGym and their infrastructure were not involved in deploying or running the evaluation environment. From what we can infer, during the evaluation, the agent deduced that Hugging Face might host the models, datasets, and reference answers for this benchmark. We believe that, from the agent’s perspective, the entire intrusion was a “cheating” attempt: accessing our production systems to steal the test answers rather than solving the challenges on its own.
Our forensic reconstruction covers approximately 17,600 attacker actions that we were able to recover, grouped into roughly 6,280 clusters, spanning from 2026-07-09 02:28 UTC to 2026-07-13 14:14 UTC. We reconstructed these actions from the logs of the code sandboxes used by the agent (see below), mapping them to shell commands and evaluation submissions while correlating them with our own platform logs, particularly those of the dataset processor nodes, APIs, and pods. Using open-weight models, specifically zai-org/GLM-5.2, we were able to decode most of the agent’s payloads (see below), which had been obfuscated via chunking and key-based encryption.
As shown in our reconstruction, the campaign unfolded in two phases:
-
Phase 1: Reaching a launchpad by chaining third-party infrastructure. As detailed 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 vulnerability in a package registry cache proxy. This allowed it to access the internet via one of its primary allowed egress routes and subsequently abuse a public code evaluation framework hosted by a user on a third-party infrastructure provider. The agent was able to run commands as root/admin on that external sandbox, using it as a control, staging, and egress base—acting as the agent’s external launchpad. This compromised external sandbox had no direct network path to our clusters; however, during our countermeasures to halt the intrusion, we retrieved portions of the agent’s logs from this external launchpad. We used these logs to reconstruct the forensic analysis presented here.
-
Phase 2: Intrusion into Hugging Face infrastructure. Operating from that external launchpad, the agent abused our dataset processing pipeline via two injection vectors, both targeting the same configuration-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, exposing the pod’s environment details (keys and tokens) and the worker process’s own source code to the agent. The second vector was a Jinja2 template injection that executed arbitrary code, granting the agent a foothold within our perimeter.
Once a foothold was established in the production pods, the agent followed a standard privilege escalation path: reconnaissance, dropping stagers, establishing command and control (C2), and subsequently pivoting into the cluster, cloud metadata, our internal network, and the source code management supply chain. Command outputs executed within the pods were returned to the agent via the HF API and attacker-controlled “dead-drop” datasets, which were then read by the sandbox.
Although the intrusion did reach Hugging Face’s internal infrastructure, the only customer content accessed consisted of five datasets whose names and files indicated they were related to ExploitGym/CyberGym challenges and answers. No other customer-facing models, datasets, Spaces, or packages were affected; the customer records read were limited to operational metadata related to dataset server search queries.
The complete attack chain crossing trust boundaries. The agent escaped the OpenAI evaluation sandbox, accessed the internet, compromised a third-party code sandbox to use as a base, and then abused our dataset processor (first via file read, then code execution) to enter our internal network. Dashed arrows: command outputs read back by the agent via the HF API and dead-drop datasets.
[
](#initial-access)
Initial Access[
](#stage-1-from-an-openai-evaluation-sandbox-to-a-rooted-launchpad)
Phase 1: From an OpenAI Evaluation Sandbox to a Compromised LaunchpadPhase 1 represents the agent’s path to the external launchpad, traversing the infrastructure of two other parties (neither of which is us). As such, we will cover this briefly and refer readers primarily to OpenAI’s blog post on the subject: https://openai.com/index/hugging-face-model-evaluation-security-incident/
As shared by OpenAI in their post, during an internal capability evaluation on OpenAI’s platform, the agent unexpectedly escaped via a zero-day vulnerability in a package proxy cache, gaining access to the internet. The agent discovered an unprotected, user-hosted public endpoint used for running arbitrary code required for CyberGym-style tasks on a third-party sandbox infrastructure (Modal). It utilized this external sandbox as a control, staging, and egress base, running commands as admin/root and using it as a launchpad for the attack. This sandbox had no direct network path to our clusters; all subsequent operations originated from here. Modal’s infrastructure