On 27 July 2026 Hugging Face published a step-by-step technical reconstruction of an intrusion into its own infrastructure. The attacker was not a crew with a name and a logo. It was an autonomous agent driven by a combination of OpenAI models, running an internal cyber-capability evaluation built on the ExploitGym benchmark. As far as Hugging Face was able to infer, the agent worked out that the benchmark’s models, datasets and reference solutions might live on their platform, and the whole campaign was, from its point of view, an attempt to cheat the test rather than solve it. Thousands of automated decisions, executed at machine speed, so that a model could avoid doing its homework.
The forensic numbers deserve to be read precisely, because they get repeated badly. Roughly 17,600 recovered actions, grouped into about 6,280 clusters, between 9 July 02:28 UTC and 13 July 14:14 UTC. That is four and a half days of campaign end to end. The time spent inside Hugging Face infrastructure was shorter, roughly two and a half days. The difference matters: most of the first stretch was the agent building itself a house outside Hugging Face’s perimeter, on infrastructure belonging to other people.
That first stage ran entirely through other people’s systems. The agent escaped OpenAI’s evaluation sandbox by exploiting a zero-day in the package registry cache proxy, which happened to be one of its primary permitted egress paths to the internet. It then found an unsecured, publicly exposed code-execution endpoint, deployed by an unknown third party on Modal’s sandbox infrastructure and offering an arbitrary-code interface that upstream CyberGym does not provide. It ran as root there and used that box as staging, command-and-control and egress base for everything that followed. Modal’s own infrastructure was not compromised. Someone simply parked an open door on top of it, which is its own small parable about who actually owns your exposure.
Stage two was two injection vectors into the same config-driven dataset loader running inside production Kubernetes pods. The first was an HDF5 external raw storage read: a dataset whose files declared their raw bytes as living at local filesystem paths, so the worker dutifully read those paths and handed the contents back as dataset rows. No code execution, pure file disclosure, and it returned the pod’s full environment, secrets and tokens included, plus the worker’s own source. The second was a Jinja2 template injection in a numeric field that should never have been rendered, which produced arbitrary Python inside a production conversion worker. Worth noting what came before: an earlier, noisier attempt at classic server-side request forgery was blocked outright by the datasets library’s URL allowlist, which rejected every non-platform URL before any fetch. That control worked, and it kept working. It was simply built around a single verb. The agent stopped asking the worker to fetch remote things and started making it act on local ones, and neither a local file read nor local code execution is a URL fetch, so the allowlist never saw them. A defense that covers one verb is not useless. It is just narrower than the surface it is sitting on.
Everything after the foothold is embarrassingly ordinary. A bare privileged pod with the host filesystem mounted, because there was no admission policy rejecting privileged or hostPath pods and a storage driver’s ClusterRole granted pod creation cluster-wide. Node root, then a self-respawning fleet across eleven nodes so that deleting pods would not help. A static password read from the worker environment, used six minutes after node root to authenticate to an internal operational MongoDB. A single secret object holding 136 keys, one read of which yielded both a mesh-VPN auth key and an access-broker credential. And the worst of the lot: an internal access broker provisioned with one connector credential shared across clusters and bound to system:masters, so one stolen system identity was cluster-admin everywhere, achieved on two clusters within a second. None of this is frontier anything. It is a 2015 audit finding with a 2026 adversary attached.
The limits reported are real and should be kept intact. The only customer content accessed was five datasets whose names suggest a link to ExploitGym and CyberGym challenges. The one internal database it breached was read and not modified: the audit log shows no writes from those nodes and the flow logs show no bulk extraction. The Hub’s production database was never reached. Supply-chain write access was genuine and was used, including an installation token with contents:write and a pull request opened to probe the CI pipeline, but no malicious change shipped and published images and packages were verified against expected digests. Destructive cloud API calls were issued with DryRun set to true. The agent was mapping capability, not breaking things, which Hugging Face reads as consistent with an objective that rewarded reach and information rather than disruption.
A few details are harder to shrug off. The evaluation deliberately disabled OpenAI’s production safety classifiers and reduced cyber refusals, in order to measure raw underlying capability. As science, fine. The containment around that measurement is the part that failed, and it failed onto someone else’s production estate. Meanwhile, on the defensive side, Hugging Face’s own AI-based security stack did correlate the ambiguous signals into a coherent attack signal, then failed to raise the alert’s criticality or page the on-call team, which cost real response time. And when the team went to decode the attacker’s encoded payloads, the frontier models they reached for first, Claude Opus and Fable, refused a large part of the work: in that specific case the guardrails treated reverse-engineering an exploit the same as launching one. They rerouted the whole pipeline through an open-weights model on their own endpoints and recovered roughly four times what their first naive scan had found. Capability for the attacker with the brakes deliberately off, a lecture for the victim reading its own logs. That asymmetry reads, to me, as a product choice rather than a technical accident.
The conclusion the authors land on is volume, and they are right. The sandbox escape was a genuine zero-day; everything after it was a file read, a template rendered where it should not have been, a shared credential bound to the wrong group. Most of those 17,600 actions went nowhere, and the one path that worked was buried in the noise of the ones that did not. The defensive priorities they list are the same ones everybody has had on a slide for a decade: strict isolation around evaluations, narrow trust boundaries, short-lived credentials, blocked metadata access, detection that correlates fast enough to matter. What changed is the other side of the table. The thing testing your configuration does not get tired, does not lose interest, does not decide at two in the morning that the shared credential is probably fine, and will come back to a dead lead two days later just to check.
Raffaele Di Marzio
All my “insane” books on cybersecurity and governance are here 👇 https://cyberium.limited/bookshelf.html