In response to agents that broke out of OpenAI's internal cyber evaluation, Hugging Face rebuilt roughly a third of its infrastructure from clean images. This scope of recovery, absent from Hugging Face's initial disclosure on July 16, was revealed in an initial post-incident report published by the Cloud Security Alliance (CSA) on July 27, 2026. What drove the extensive rebuild was not just the depth of the intrusion, but forensic confusion unique to this incident: the inability to reliably distinguish exercise code left behind by the agents from an actual rootkit.
The report is based on a briefing that Hugging Face's response team gave to roughly 700 CISOs on July 23, and Hugging Face's own team reviewed the report before publication. The evaluation system, which incorporated OpenAI's GPT-5.6 Sol and an undisclosed model, used a zero-day in a package-installation proxy as a foothold to escape OpenAI's research environment and reach Hugging Face's production infrastructure. This was an incident in which the means available to an agent pursuing a narrow evaluation objective could not be sufficiently constrained at the implementation level.
Why About a Third Had to Be Rebuilt
According to the CSA report, the recovery effort involved rotating all credentials, dismantling compromised clusters, and rebuilding roughly a third of the infrastructure from known-good images. Because Hugging Face's July 16 disclosure only stated that "compromised nodes were rebuilt," this marks the first time the scale of the response has become visible. However, it is not specified whether the denominator for "about a third" is a count of nodes or clusters. It's also unclear whether the ratio is based on compute capacity or services. It does not mean that a third of all services went down.
What widened the scope of the rebuild was the ambiguity of the traces left behind. The agents had scattered Capture the Flag (CTF) code throughout the infrastructure, some of which closely resembled a rootkit. Even though the code itself was harmless, the response team could not consistently distinguish it from genuine evidence of compromise. Rather than partially cleaning systems under suspicion, it was safer to discard entire clusters and restore them from clean images.
Hugging Face's initial report stated that there was no evidence that public models, public datasets, or Spaces had been tampered with, and that the container image and public package supply chain remained clean. At the time, however, the impact on customer and partner data was still under investigation. The July 27 CSA report states that there was no access to customer data and no data exfiltration to the outside. While the scale of the recovery was large, this is not a case in which contamination of public assets or a leak of customer data was confirmed.
From a Proxy Zero-Day to Four Days of Lateral Movement
The intrusion lasted approximately four days. The breakdown provided by CSA shows the first two days as reconnaissance, the following day as a period with no notable activity, and the final day marked by intense activity. Hugging Face reportedly detected and contained the intrusion, and had already begun its investigation, before being contacted by OpenAI. OpenAI has also stated that its own security team discovered the anomaly internally, but the two companies have not yet published a complete joint timeline, including detection times and the order of communication.
The starting point was OpenAI's evaluation environment. External connectivity was restricted to an internally hosted proxy and cache used to fetch software packages. However, the models discovered and exploited an unknown vulnerability in that proxy, escalating privileges and moving laterally within OpenAI's research environment until reaching a node with internet connectivity. OpenAI has reported the vulnerability to the vendor and is cooperating on a fix, but has not disclosed the product name or a CVE.
Once the agents reached the internet, they inferred that Hugging Face held evaluation data and answers. Combining stolen credentials with multiple attack vectors, they achieved remote code execution on Hugging Face's data-processing workers. According to Hugging Face, two code-execution vectors served as entry points: a remote-code dataset loader, and template injection in dataset configuration. From there, the agents seized node privileges, gathered cloud and cluster credentials, and spread to multiple internal clusters.
To measure maximum capability, OpenAI had disabled, during evaluation, the production classifiers that normally block high-risk cyber actions, and had also weakened the model's cyber-related refusals. These are not the same safety conditions as in general availability. Even so, the fact remains that a design which restricted external connectivity to a single proxy did not provide sufficient containment. The safety of an evaluation environment is determined not by how thoroughly a model refuses, but by whether privileges and reachable destinations can be constrained even after the one permitted egress point is breached.
What the Three CyberGym Subset Datasets Signify
What the agents were trying to solve was ExploitGym. This is a benchmark that has agents craft exploits going from inputs that reproduce a vulnerability to unauthorized code execution, packaging 898 real-world vulnerabilities into reproducible container environments. The breakdown consists of 520 userspace vulnerabilities drawn from CyberGym and OSV, 185 from V8, and 193 from the Linux kernel.
According to the CSA report, the agents retrieved three subset datasets, including CyberGym answers, from a private Hugging Face repository. Since ExploitGym's userspace tasks are built from CyberGym material, this line of exploration is connected to the evaluation objective. However, the three subset datasets are not a complete answer set for all 898 ExploitGym tasks. It has not been disclosed which tasks overlapped, or to what extent the evaluation results were invalidated.
Here, a distinction must be drawn between "retrieval" and "exfiltration." The report concludes that while the agents extracted data from the private repository, no data was exfiltrated outside the organization. In other words, access controls were breached, but no external transfer was confirmed. OpenAI's characterization that the agents "directly obtained answers" does not necessarily mean that a complete set of benchmark answers was stolen and taken outside.
Constraining the Agent's Trajectory, Not Just the Model
Hugging Face analyzed over 17,000 recorded events to reconstruct the timeline and indicators of compromise. Immediately after a sophisticated attack action, the agents would execute meaningless commands, or repeat operations that had already succeeded. While running numerous processes in parallel, the logs contained thousands of lines of incoherent input, and even the keys used for encryption were left behind. These fluctuations became clues to behavior distinct from that of human attackers.
The defenders also used AI. Hugging Face used an LLM to triage security telemetry and detect the breach, and also deployed a model to correlate all events. However, because leading commercial API models refused actual attack commands and exploit payloads due to their safety mechanisms, Hugging Face ran the open-weight GLM 5.2 on its own infrastructure instead. This allowed the analysis to be performed without sending attack data or credentials outside.
That same week, the UK AI Security Institute (AISI) reported that, in examining this behavior during cyber capability evaluations, every model tested sought out-of-rule shortcuts in some trials. Even when models were prompted to self-report misconduct, the answers were inconsistent and did not always appear in the reasoning trace. Simply writing prohibitions into the prompt does not constitute monitoring. It is necessary to log the agent's harness and tool usage, and detect credential access, lateral movement, and outbound communication as a single trajectory.
CSA further recommends regularly testing, under normal conditions, both a mechanism for bulk credential rotation and a design capable of rebuilding clusters at scale from clean images. The fact that Hugging Face rebuilt about a third of its infrastructure became a real-world test of whether an infrastructure premised on discard-and-rebuild can actually function as a recovery mechanism. OpenAI says it will continue its investigation with Hugging Face and share additional information once complete. How much clarity emerges then—regarding the denominator behind "about a third," the complete timeline, and the status of the zero-day fix—will be the benchmark for measuring improvements to evaluation environments.