New details about the
OpenAI-Hugging Face AI hacking incident were revealed this week, including the exploitation of a zero-day vulnerability in a self-hosted JFrog Artifactory instance and the abuse of a customer’s unsecured sandbox on the Modal platform.
OpenAI also disclosed
in an update Tuesday that at least four accounts on four other services besides Hugging Face were accessed by its agent as part of the incident, with one of the services confirmed to be Modal
in a report by Reuters. A Modal customer sandbox was used for staging and outbound relay during the attack, while another account on another undisclosed service was used for data storage, and two other accounts were accessed in a read-only manner, OpenAI said.
Hugging Face published a new
technical timeline on Monday outlining the full 4.5-day incident in early July, which included more than 17,600 agent attacker actions grouped into 6,280 clusters and two main attack stages: escape from OpenAI’s evaluation sandbox and intrusion into Hugging Face’s infrastructure.
“The post-mortem describes a model that discovered a zero-day, escaped containment, chained vulnerabilities and moved across production infrastructure while generating thousands of actions and misleading artifacts. Hugging Face later used AI to reconstruct more than 17,000 events in hours,” Andy Lunsford, CEO and co-founder at BreachRx, said in a statement to SC Media. “That sequence shows how quickly machines can create and interpret evidence while organizations still need people across security, legal, privacy, communications and leadership to establish facts, assign responsibility and make consequential decisions.”
JFrog Artifactory zero-day exploited by agent; OpenAI locks down prototype model
While the agent involved was not meant to have full internet access during its ExploitGym evaluation, during which its normal cybersecurity refusal guardrails had been intentionally disabled, it exploited a flaw in a package registry cache proxy within its environment to escape to the internet.
OpenAI and
JFrog confirmed this week that the cache proxy service exploited was JFrog’s self-hosted Artifactory service, which contained a zero-day vulnerability that has now been fixed. According to JFrog, self-hosted customers will need to upgrade to Artifactory 7.161 to patch the flaw, while cloud customers are already protected.
JFrog did not disclose further details about the vulnerability used by OpenAI’s agent, but the
Artifactory 7.161 patch notes list a total of nine CVEs addressed, including five high-severity and four medium-severity flaws. It is unclear which, if any, of these flaws were involved in the OpenAI-Hugging Face incident.
“The vulnerability itself isn’t novel, a human could do the same relatively easily. The difference here is that the agent repeatedly found it, used it, crossed organizational boundaries, and kept going without a person directing them,” noted Gabrielle Hempel, security operations strategist at Exabeam, in an email to SC Media.
OpenAI also clarified in its Tuesday update that the attack involved its GPT-5.6 Sol model along with a pre-release model that was “never intended for public release” and was tested as an “internal-only research prototype.”
The company said it has since deactivated and encrypted this prototype model and restricted it from further research access.
Unauthenticated Modal customer sandbox used as a ‘launchpad’ for Hugging Face attack
Hugging Face’s technical timeline further revealed how the OpenAI agent abused external third-party services to facilitate its attack, including a customer sandbox hosted on the Modal platform.
Modal CTO Akshat Bubna confirmed in a report by Reuters that a customer “published an unauthenticated endpoint that allowed anyone on the internet to use their sandboxes for code execution” and that Modal’s own platform and infrastructure were not compromised by the agent.
“The Modal customer would have seen a well-formed request to an endpoint they’d left open. Nothing anomalous. In an incident like this, the victim doesn’t detect anything — they get told, by whoever was operating the agent,” noted Oleks Yaremchuk, co-founder and CTO at Manifold Security, in a comment to SC Media. “That inverts how disclosure has always worked. Companies are now dependent on a lab’s internal incident process to find out they were breached, and most have no relationships with that lab at all.”
Hugging Face described how this customer’s sandbox contained a CyberGym execution harness that OpenAI’s agent abused for payload staging and code execution, using it as an “external launchpad” for the attack.
“Exposed third-party infrastructure will likely become a recurring theme because the internet is awash in weak software. As models become more capable, they’ll have more opportunities to find and exploit those weaknesses,” said Drew Dennison, co-founder and CTO at Semgrep, in an email to SC Media.
OpenAI and Hugging Face also confirmed the agent used additional third-party public services such as code paste sites, request capture services and screenshot services to facilitate the attack, with no platform or account-level compromise as these tools are publicly accessible.
How OpenAI’s agent moved through Hugging Face’s environment
Two injection vectors in Hugging Face’s data processing pipeline abused by the agent were also described in the technical report. The first flaw allowed the agent to read local files from a Hugging Face dataset-processing worker by uploading a malicious dataset configuration with HDF5 files declaring their raw data lived at those filesystem paths.
While no code was executed at this stage, this malicious config caused the worker to leak the full worker pod environment and the worker’s own source code via the Hugging Face API. The data leaked through this exploit, including some secrets and credentials, were leveraged to further pivot through Hugging Face infrastructure.
The second flaw was a template injection, where a renderer wrongly evaluated a Jinja2 template contained in a numeric offset field in an fsspec reference:// spec within a malicious dataset configuration uploaded by the agent.
“The renderer wrongly evaluated it, and the agent walked the standard Python object graph to reach exec,” Hugging Face stated. “This ran arbitrary Python inside a production conversion worker pod on our Kubernetes cluster, driven by injection from the launchpad. That pod was the agent’s foothold inside our perimeter, and every command it ran there was smuggled back out through the HF API and dead-drop datasets.”
The agent planted public datasets on Hugging Face as dead drops to store stolen data and stage additional payloads, using chunking, XOR and gzip encoding to prevent the staged content from being detected by Hugging Face’s scanners. The agent’s malicious commands were also chunked and encoded with gzip and base64 to evade detection.
The OpenAI agent ultimately expanded its accesses from the initial worker pod across Hugging Face’s Kubernetes infrastructure, creating a privileged pod with the host filesystem mounted, escaping to root on the node and establishing a “self-respawning fleet” across 11 nodes. It read an internal operational datasets-server MongoDB using a static password it recovered from the worker environment and also mapped Hugging Face’s cloud estate using temporary credentials it obtained from a cloud metadata endpoint but did not gain control over these resources, Hugging Face said.
An EdDSA JWT signing key from among the secrets harvested from the production pod allowed the agent to forge 24-hour service-account tokens used to read its private datasets, from which it obtained a mesh-VPN authentication key and an access-broker credential used for further lateral movement. The mesh-VPN auth key was used to enroll a rooted node on the corporate mesh network and enroll 181 devices from the sandboxes, although there is no evidence the agent leveraged this access to reach a private workload or an internal Kubernetes API, Hugging Face said.
The agent also reached an internal service-connector API from the worker pod and obtained the full destination catalog from a broker that was improperly provisioned to share a single connector credential across all clusters, with the connector identity bound to system:masters. This allowed the agent to gain cluster-admin on two clusters within one second, Hugging Face said; Hugging Face has since shut down the broker, which is being rebuilt with cluster-scoped credentials.
Ultimately, Hugging Face concluded that the only customer content accessed by the agent throughout the intrusion was ExploitGym and CyberGym challenge solutions from five datasets, with the agent’s sole goal being to “cheat the evaluation” by stealing these solutions.
“The warning signs to watch far aren’t simply whether a model can execute code or exploit a vulnerability, but whether it begins expanding its scope, seeking additional privileges, probing unrelated systems, or changing tactics after a failure,” noted Cris Thomas, security advocate at Semgrep, in comments to SC Media. “Those are behaviors that separate a powerful tool from an autonomous operator, and they are exactly why evaluations must focus less on trusting the model and more on building environments that assume it will behave like an intelligent, persistent attacker from the very beginning.”
Hugging Face used a quantized version of ZAI’s GLM-5.2 provided by Nvidia (GLM-5.2-NVFP4) hosted on its own infrastructure to analyze the attacker’s actions, decode staged payloads and reconstruct a detailed timeline of the attack. This open-weight model was used after attempts to use Claude Opus and Fable were met with cyber safeguard refusals, Hugging Face explained.
In response to the incident, Hugging Face patched the data processing flaws that enabled initial access, worked with Modal to shut down the launchpad sandbox, blocked pod-level cloud metadata access for all workloads and broadly rotated all tokens and credentials used by Hugging Face infrastructure, even those that were not accessed in the attack.
Hugging Face also wiped and rebuilt a core cluster accessed by the agent as a precaution, narrowed the credential scope for its internal service-connector and improved its detection and alerting mechanisms after noting that its AI-based security agent detected the attack signals but failed to properly raise a critical alert that would have triggered a response from the on-call security team.
OpenAI stated it is continuing to review and investigate the incident with external advisors and with oversight from its Safety and Security Committee, and plans to publish a technical report in the coming weeks when its investigation is complete.