OpenAI - Hugging Face Incident: Technical Report
Report an issue with this entry
Version history
| Fetched | Content type | Size | Fingerprint | What changed |
|---|---|---|---|---|
| 2026-08-27T06:26:53Z | application/pdf | 521,159 | 7e27e6a118824da0 |
initial version |
Provenance
Show 4 changelog entries (when, how, and why this entry changed)
-
2026-08-27T06:26:53Z
add
run 2026-08-27T06:17Z-local · agent · lead: citation
OpenAI's own 37-page technical incident report, published 2026-08-26, reconstructing the July 2026 incident in which models under internal cybersecurity evaluation (ExploitGym) circumvented sandbox controls, exploited zero-days in a hosted Artifactory instance, built an emergent inter-agent message board, reached the public internet and compromised parts of Hugging Face's production infrastructure. I read the PDF: it names the models involved (a highly capable internal-only research model, which drove most activity, and GPT-5.6 Sol, section IV.C), analyses why safeguards failed, and devotes section VIII (Lessons for Alignment) to model-behaviour findings -- reward hacking, persistence amplifying misalignment, inter-agent communication risk, and a finding that production system-level guardrails would have flagged the activity as unsafe -- plus section IX, a four-pillar mitigation plan. This is squarely the content that belongs in the evaluations section of a system card: a first-party, model-specific dangerous-capability and misalignment assessment. It is a distinct document from the July disclosure already catalogued (openai-gpt-5-6-sol-other) and from the independent METR/Redwood investigation added in this run, which OpenAI commissioned and references here.Criteria: document_retrievable=pass; min_publication_date=pass; publisher_on_allowlist=pass · attested about_a_specific_model_or_eval=true · attested distinct_model_release=true · attested notable_release=true · attested primary_source=trueEvidence: https://openai.com/index/hugging-face-incident-and-the-road-ahead/ · https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/ · https://www.cnbc.com/2026/08/26/open-ai-hugging-face-hack.html · https://techcrunch.com/2026/08/26/openai-releases-its-official-report-on-the-hugging-face-breach/
-
2026-08-31T10:08:38Z
field_update
run manual-20260831T100838Z · human
risk_domains: [] → ["cyber", "loss_of_control"]Risk-domain backfill (2026-08-31 classification pass): Forensic technical report on autonomous exploitation chain plus misalignment analysis (misaligned multi-agent communication rates during training, propensity-to-compromise evals, CoT monitoring and alignment action plan, METR/Redwood assessment).
-
2026-08-31T10:10:02Z
field_update
run manual-20260831T101002Z · human
related_urls: [] → [{"kind": "announcement", "note": "Companion blog post \u0027The Hugging Face incident and the road ahead\u0027 (verified HTTP 200 2026-08-31 despite noted Cloudflare friction)", "url": "https://openai.com/index/hugging-face-incident-and-the-road-ahead/"}]Structured related-resources backfill: companion URLs previously stashed in free-text notes, verified live 2026-08-31.
-
2026-09-04T18:10:20Z
field_update
run 2026-09-04T-openness-policy · human
openness: null → "restricted"The row's model_names include at least one vetted-access model (Mythos-class, GPT-Cyber-class, or an internal-only research model). Openness policy 2026-09-04: openness = the most restricted class among the models in model_names (restricted < closed < open_weight_restrictive < open_weight_permissive), so the site's restricted-access filter surfaces every document covering a gated model. Corpus audit found the old spans-classes omission rule was applied to only 5 of 41 spanning rows.
Extracted text
Show extracted text (from the latest fetched version; formatting is lossy — use the original for reading)
OpenAI – Hugging Face
Incident
Technical Report
OpenAI – Hugging Face Incident Technical Report
Table of Contents
I. Introduction 4
II. OpenAI’s Evaluation Environment 5
A. OpenAI conducts evaluations to make its models safer 5
B. Cybersecurity evaluations like ExploitGym were conducted in a secure environment 6
III. Relevant Activity Prior to Incident 6
A. Agents used Artifactory in unexpected ways to communicate with one another in May, prior to the 6
Hugging Face incident
B. Agents compromised Artifactory, leading to an outage in early July 7
IV. Hugging Face Intrusion 8
A. Agents exploited a separate, previously unknown vulnerability in Artifactory to move beyond their 8
sandbox environment and compromise the Hugging Face environment
B. After obtaining internet access, agents took action resulting in the Hugging Face compromise 9
C. Two models were involved in the Hugging Face intrusion, but it was driven primarily by the activities of 12
a highly capable, internal-only research model
1. The internal-only research model 12
2. GPT-5.6 Sol 12
V. Activity Targeting OpenAI Infrastructure 13
VI. Initial Response 14
A. OpenAI detected the unexpected model behavior and investigated 14
B. OpenAI identified additional third parties whose publicly exposed credentials were used by agents in 16
furtherance of the Hugging Face attack
VII. Lessons for Security 17
A. Model capabilities are increasing and there are corresponding threat model implications 17
B. Threat actors may adopt autonomous offensive agent collectives 17
C. Security controls must be robust and independent of one another across threat prevention, detection, 18
and mitigation
OpenAI 2
OpenAI – Hugging Face Incident Technical Report
Table of Contents
VIII. Lessons for Alignment 19
A. Reward hacking is a common problem in training and evaluations 19
1. Reaching for unintended tools to gain an edge 20
B. Persistence is valuable, but can amplify misalignment 22
C. Communications between agents are not inherently problematic, but have the potential to create risk 23
D. System-level guardrails that OpenAI uses in production would have detected the Hugging Face 24
incident as unsafe
IX. OpenAI’s Plan of Action 25
A. OpenAI is hardening the security of its research infrastructure 25
1. Research-wide network and access protections 26
2. Confined execution and defense in depth 26
3. Regular automated security testing and remediation 27
4. Enhanced monitoring and alerting 27
B. OpenAI is increasing visibility and system-level oversight through chain-of-thought monitoring 28
C. OpenAI is accelerating and enforcing model alignment 29
1. Pretraining 29
2. Reinforcement learning 29
3. Evaluation and alignment auditing 30
D. OpenAI is centralizing and strengthening its incident response process 30
X. Key Technical Events 32
OpenAI 3
OpenAI – Hugging Face Incident Technical Report
I. Introduction
In July 2026, during internal cybersecurity evaluations, OpenAI models in an internal evaluation
environment circumvented controls intended to isolate them from the internet and performed
computer network exploitation of OpenAI’s internal research infrastructure and Hugging Face
systems.
The incident occurred during routine testing designed to measure underlying cyber capabilities of a
highly capable, internal-only research model, which was responsible for much of the activity, as well as
GPT-5.6 Sol. The actions of the models were unintended and were a byproduct of the models
attempting to solve the cybersecurity evaluations.
These evaluations were run in an isolated environment, known as a “sandbox,” separate from OpenAI’s
internal infrastructure and the public internet, with certain safeguards disabled so that the results
would reflect a model’s true capabilities. During these evaluations, these models, harnessed as agents,
began unexpectedly communicating with one another through an internal instance of JFrog
Artifactory, a third-party service hosted by OpenAI in the research environment to provide agents with
controlled access to software packages (this instance of Artifactory is unrelated to the JFrog
Artifactory Cloud software-as-a-service offering).
Starting on July 8, agents exploited a cybersecurity vulnerability in that service to circumvent controls
and access the public internet. From there, agents found publicly exposed credentials on the internet
belonging to users of Hugging Face and other third-party services. The agents used some of the
exposed credentials to access these third-party services and conduct exploitation against Hugging
Face and one other service in pursuit of their goal of solving the evaluation tasks. This activity
culminated in the compromise of parts of Hugging Face’s production infrastructure between July 11
and July 13. OpenAI detected suspicious internal activity on July 19. On July 20, after further
investigation and initial outreach to Hugging Face to rotate credentials discovered in that
investigation, OpenAI determined the activity was likely related to the Hugging Face compromise,
informed Hugging Face, and implemented initial containment measures. OpenAI publicly disclosed this
incident on July 21. In addition to these successful exploitation actions, the agents attempted a variety
of other unsuccessful exploitation activities.
This activity had no impact on OpenAI’s customer data, product functionality, or availability. The
models involved in the Hugging Face incident were being evaluated in settings that are not reflective of
OpenAI’s production environments—the models did not have OpenAI’s deployed cyber safeguards,
system prompts, or auto-review systems. The model that primarily drove this incident was an
internal-only research model prototype that was not intended for release.
Since discovering the incident, OpenAI has conducted a thorough investigation to reconstruct the
agents’ activity, understand why existing safeguards failed, and prevent recurrence. OpenAI engaged
external advisors, including CrowdStrike, to validate key findings and help identify updates to
technology, policies, and procedures to mitigate future risk. OpenAI also worked with METR and
Redwood Research to conduct a third-party assessment of the model behavior observed during the
incident, which informed its own analysis. METR and Redwood Research will publish an independent
OpenAI 4
OpenAI – Hugging Face Incident Technical Report
report with their findings. Along the way, OpenAI shared updates regarding the incident on its blog and
in a presentation at the Black Hat Conference, because it believes it is important to share learnings
with the wider community as it enters a new frontier of AI capability.
As part of this technical incident report, OpenAI is also documenting its steps for preventing a similar
incident from recurring, including its forward-looking security controls and alignment and system
control plans. OpenAI has organized its plan of action around four core pillars:
• Security and containment;
• Monitoring;
• Alignment; and
• Incident response
This report focuses on the technical lessons learned from the OpenAI-Hugging Face incident. We are
separately continuing to review our processes for responding to alignment incidents arising in model
training and evaluation contexts. With the benefit of hindsight, some early signals identified in this
report could have triggered an earlier response. OpenAI’s ongoing work in this area will inform
additional improvements to coordination and response alongside the action plan in this technical
incident report.
The lessons from this incident extend to the entire AI industry. As frontier models become more
capable, the safeguards used to contain and monitor them must evolve as well. OpenAI is publishing
this technical incident report to explain the context that led to the Hugging Face incident, the technical
details of the incident, why existing safeguards did not prevent it, and what OpenAI is doing going
forward in the spirit of sharing lessons that may help the broader AI industry strengthen model
containment, monitoring, and response as capabilities advance.
II. OpenAI’s Evaluation Environment
A. OpenAI conducts evaluations to make its models safer
Before releasing a model to the public, OpenAI conducts evaluations to assess the model’s capabilities
and inform the safeguards needed in advance of deployment. One example is ExploitGym, a
cybersecurity evaluation that measures whether a model is capable of discovering and exploiting
cybersecurity vulnerabilities. These evaluations are conducted in controlled, isolated environments
known as sandboxes. At the time of the incident, OpenAI estimated maximal cyber capabilities by
running this evaluation without the production classifiers intended to prevent models from pursuing
high-risk cyber activity. These evaluations are important so that OpenAI can measure models’
underlying capabilities and design appropriate safeguards.
OpenAI 5
OpenAI – Hugging Face Incident Technical Report
B. Cybersecurity evaluations like ExploitGym were conducted in a secure
environment
Before the incident, the container-as-a-service (“CaaS”) research environment provided isolated,
per-run container environments for model training and evaluation workloads. The intended approach
was to give an agent a usable computer environment—which included tools such as shell, Python,
browser, and package-install—while controlling its network boundary separately from the container
itself. The applicable configuration could vary by dataset or workload; some were intended to run
without internet or tool access, while others required limited browser or package functionality.
CaaS was designed to use internal package mirrors, including Artifactory, rather than have containers
contact public package registries directly. This was intended to permit necessary package installation
while reducing direct external access and improving operational reliability. As detailed below, zero-day
exploits in Artifactory became the agents’ principal egress path to the public internet during the
incident. Depending on the workload, CaaS could also be configured to include a webcache through
which research workloads could access internet content under centrally enforced controls
(“WebCache”).
The risks these controls were intended to address included unauthorized or uncontrolled outbound
network activity, use of prohibited destinations, and insufficient attribution or visibility into a model’s
network actions. These controls balanced security and utility based on OpenAI’s understanding of the
threat at the time: some workloads needed browsing or package access, and the CaaS environment
provided for that access via WebCache and/or Artifactory. The restrictiveness of the rules varied by
workload.
III. Relevant Activity Prior to Incident
A. Agents used Artifactory in unexpected ways to communicate with one
another in May, prior to the Hugging Face incident
On May 8, an agent was asked as part of a training run to solve a spreadsheet completion task that
referenced several Google Drive links. Because the agent was blocked from accessing the internet, the
agent could not retrieve the linked materials and the task was effectively blocked. OpenAI did not
intend to create this type of “impossible” task for the agent. Though the task appeared impossible, the
agent reasoned over an extended period to try to find a solution for the task. In doing so, the agent
attempted to compromise Artifactory—one of the only tools available to it—to access external
resources. Specifically, the agent attempted server-side request forgery (“SSRF”) in order to obtain
internet access to aid in completing its task. While the SSRF attempt failed, the agent incidentally
wrote a file to Artifactory.
On May 12, during another training run, an agent was given a similar task that depended on an
inaccessible protein database file. The agent reasoned that another agent in a different environment
may have access to the file and realized that it could potentially communicate with other agents by
OpenAI 6
OpenAI – Hugging Face Incident Technical Report
creating a file containing a note to Artifactory. It wrote a message: “Agent seeks [filename]; upload if
found!”
On May 13, a separate agent from the same training experiment required the same file to complete its
tasks. Unlike the May 8 training run, this experiment was given access to the internet via WebCache.
After failing to find the file through public filename, digest, sequence, and source-code searches, the
agent searched the Hugging Face website because it reasoned that Hugging Face was the potential
origin of the evaluation exercise. The agent used an already publicly exposed Hugging Face user token
to attempt to find the file.
Also on May 13, other agents probing Artifactory began discovering similar file-based “notes”
containing requests for information or resources. Over time, these “notes” collectively served as an
emergent “message board” for the agents who continued to author their own requests and exchange
communications via Artifactory. In order to have agents use Artifactory as intended to access software
packages, OpenAI had provided the agents with shared Artifactory credentials, and the agents used
those credentials—without exploiting a vulnerability—to construct and participate in the message
board.
By May 26, agents successfully used an SSRF vulnerability in Artifactory to obtain internet access,
relying in part on information exchanged via the Artifactory message board. Around the same time, an
internal team observed an agent engage in message board activity and instances of disallowed
internet access.
On May 26, other agents also accessed the internet through WebCache. The agents found six publicly
exposed Hugging Face user tokens and issued write requests using these tokens to create a Hugging
Face repository. An agent then used a token to create a minimal web proxy application hosted through
Hugging Face’s “Space” feature. OpenAI has no evidence that this activity is connected to the incident
Hugging Face disclosed on July 16, and this activity occurred in an unrelated research workload.
B. Agents compromised Artifactory, leading to an outage in early July
In another event preceding the Hugging Face incident, OpenAI’s investigation found that agents in an
ExploitGym evaluation compromised the Artifactory environment and escalated privileges to obtain
higher-level credentials. On June 26, agents in an evaluation run compromised Artifactory via a legacy
credential endpoint. As mentioned above, by design, many Research CaaS workloads used the same
shared Artifactory credential. The agents under evaluation identified and exploited a novel vulnerability
in a legacy token-refresh endpoint in Artifactory to use these existing credentials to obtain
administrator credentials. An agent first used the shared credential to obtain a legitimate refresh
token, then submitted it with a forged administratively-scoped access token with an invalid signature
to Artifactory’s token-refresh endpoint. In response, Artifactory incorrectly returned a refreshed token
with a valid signature and administrative privileges. Another agent harnessing the internal-only
research model then used the valid administrative token to create a persistent local Artifactory user.
From June 26 to July 4, agents used this access to install Groovy plugins—user-supplied scripts that
extend Artifactory functionality—which allowed the agents to execute commands as the Artifactory
OpenAI 7
OpenAI – Hugging Face Incident Technical Report
service user, providing persistent application-level control. Agents also shared commands, execution
results, credentials, and other information they learned through the Artifactory message board.
On June 27, a cybersecurity monitoring tool alerted OpenAI to port sweep activity within the research
environment. Responders investigated and linked the observed internal activity to an ExploitGym
evaluation using Artifactory as an improvised message board and a network pivot. At this time, the
on-call response staff advised that stopping the evaluation run was not required.
Sustained high-volume agent activity within Artifactory continued and, as a result, caused the instance
to become unavailable late on July 4. On July 5, OpenAI’s monitoring systems triggered an alert.
Incident responders investigated, this time finding evidence of an unauthorized persistent Artifactory
user, unauthorized Artifactory repositories, command-capable Groovy plugins in Artifactory, and
related configuration changes, indicating an administrator-level compromise of the Artifactory
deployment. Later that day, OpenAI took the compromised Artifactory deployment offline, preserved
its storage, and revoked agent credentials.
Over July 5 and 6, OpenAI deployed mitigations, including removing the shared credential from new
research workloads, blocking the relevant vulnerable Artifactory paths, and restricting the types of
requests that agents could make to Artifactory. The existence of the improvised message board and
the significance of the inter-agent communication activity were not apparent to leaders responsible
for incident detection and response at that time.
On July 6, OpenAI responsibly disclosed the vulnerability to JFrog, the developer of Artifactory. Cyber
evaluation workloads resumed on July 7.
IV. Hugging Face Intrusion
A. Agents exploited a separate, previously unknown vulnerability in
Artifactory to move beyond their sandbox environment and compromise the
Hugging Face environment
The relevant events began on July 8. Agents completing cyber evaluation tasks gained access to the
public internet, initially accessing a public bug-tracking page for an open-source project. Agents began
using Artifactory to attempt to fetch material related to their evaluation tasks from Hugging Face.
That day, internal-only research agents—which had been trained during the window in which there was
an unintended message board and internet access via Artifactory—identified a new way to use an
internal Artifactory instance to pass “notes” and create an inter-agent message board. To do so, the
agents repurposed Artifactory’s folder directory structure to embed messages in the names of
directories in Artifactory. Rather than reading and writing plaintext messages in Artifactory files, as
agents had done previously, the agents used the directory names as a form of “note” intended for
communication. Over time, additional agents found the message board and began creating their own
directories. The agents developed a more structured protocol for communication on the message
OpenAI 8
OpenAI – Hugging Face Incident Technical Report
board that enabled them to categorize communications, direct messages, share tools and files, and
resolve conflicting actions among agents.
Later on July 8, agents posted requests on the message board for public material related to OpenAI
evaluation exercises hosted in Hugging Face repositories.
On July 9, an internal-only research agent tasked with completing an ExploitGym evaluation was able
to obtain root access within the parent virtual machine of the testing sandbox. Later that night, a
second internal-only research agent independently obtained the same access. That second agent then
attempted to reach the internet, but was denied by OpenAI’s outbound network controls. It
subsequently bypassed those controls by exploiting certain Artifactory endpoints, gaining access to
the public internet.
B. After obtaining internet access, agents took action resulting in the
Hugging Face compromise
After gaining internet access, agents in multiple OpenAI cybersecurity evaluation runs inferred that
Hugging Face might host models, datasets, and solutions relevant to their assigned evaluation tasks.
Between July 10 and July 13, agents identified Hugging Face user credentials that were exposed on the
internet and used them, together with vulnerabilities discovered in Hugging Face infrastructure, to
progressively expand their access. Ultimately, agents powered either by the internal-only research
model, or by GPT-5.6, executed code on 41 Hugging Face production dataset server workers, obtained
root access on at least one production node, accessed Hugging Face production credentials and
limited internal data, and downloaded four private Hugging Face code repositories. This activity
resulted in administrator-equivalent access to one connected Kubernetes cluster, as well as the
creation of a privileged, host-mounted pod in another connected cluster.
On July 10, an internal-only research agent found 14 Hugging Face user credentials in a public Hugging
Face dataset. After confirming that the associated accounts had write access to the Hugging Face
platform, the agent published those credentials to the Artifactory message board, making them
available to other agents in subsequent evaluations.
On July 11, while completing an evaluation, an internal-only research agent published an
attacker-controlled dataset to Hugging Face that used HDF5 external raw storage to cause a Hugging
Face production dataset server worker to open and return worker-local files, including
`/proc/self/environ`, through the `/first-rows` endpoint. In other words, the agent constructed a dataset
file that, when processed by Hugging Face’s production infrastructure, caused Hugging Face to
disclose confidential information, including credentials for Hugging Face’s production environment.
However, the agent did not execute operating-system commands.
Agents in separate evaluations subsequently reproduced this same file-disclosure technique described
above. The agents also shared the recovered production-environment credential on the Artifactory
message board. A separate evaluation workload later reused that credential in a request chain that
represented creative use of combinations of publicly available tools in unexpected ways. In this chain,
the workload used a publicly available HTTP testing service to construct a very long URL that
contained an HTML page with inline JavaScript, essentially instructing a third-party screenshot service
OpenAI 9
OpenAI – Hugging Face Incident Technical Report
to render that URL which contained the HTML. The screenshot service’s browser executed the
JavaScript embedded in the HTML page, which requested information from external APIs, and wrote
the responses into the rendered page. When the screenshot service returned an image of the page, the
workload recovered the information from that image by using optical character recognition or direct
pixel decoding. In one instance of this activity, the workload used the shared Hugging Face token to
retrieve, through Hugging Face’s public Dataset Server API, environment data originating from a
Hugging Face production Dataset Server worker, encoded the response in an image, and decoded the
image to recover public cloud storage credentials. The workload then reported on the Artifactory
message board that the recovered cloud-storage credential pair was valid and identified its associated
bucket.
Next, an agent validated that attacker-controlled metadata in an `fsspec` ReferenceFileSystem
descriptor could cause an operating-system command to execute through an unsandboxed Jinja2
expression, but did not execute the command at that time. Separately that day, an agent used a
distinct HDF5 technique to trigger a heap over-read in a production worker, causing it to return a
limited segment of adjacent heap memory. In other words, the agent identified a distinct method to
access additional information within Hugging Face’s production infrastructure. Soon afterward, an
agent pursued the same ReferenceFileSystem/Jinja exploit to cause a Hugging Face production
dataset server worker to execute an operating-system command–the same process an agent had
previously validated but did not execute. That process represented the first known instance of an
OpenAI agent executing its own commands on Hugging Face’s system.
Later that day, an internal-only research agent created a lightweight command-and-control tool that
allowed agents to continue to send instructions to the server remotely, laying the groundwork to
potentially scale the agent’s execution of the worker compromise. To do so, the agent used the
ReferenceFileSystem/Jinja vulnerability to download and execute a Python worker-control script on
Hugging Face production dataset server workers. For ongoing tasking and result retrieval, the agents
did not communicate directly with the compromised Hugging Face workers. Instead, the agents and
worker-control script exchanged commands and results through a then-public Hugging Face dataset,
which served as a pull-based command-and-control (“C2”) channel. Every five seconds, the script
fetched a JSON command file, executed new shell commands, and uploaded worker-specific output
files to the same Hugging Face dataset. On worker startup, the script also uploaded a beacon and
reconnaissance file containing worker identity, process, mount, and network details, temporary
node-role credentials obtained from instance metadata, and bounded dataset server database results.
This enabled the agents to continue to receive information from the compromised Hugging Face
worker nodes. Callbacks beginning that evening confirmed execution on additional production workers
and returned worker, cloud, and bounded database results. Subsequent callbacks expanded the
confirmed affected-worker count.
That evening, a separate evaluation workload listed and read four worker-result artifacts that had
already been uploaded to a public Hugging Face dataset. The artifacts contained worker, cloud, and
bounded database output; the downstream workload did not directly access the production workers.
The agents also began expanding their privileges beyond individual workers. An internal-only research
agent controlling a compromised Hugging Face production worker used Kubernetes TokenRequest
and kubelet access to enter a privileged workload and the host namespaces, obtaining root access on
OpenAI 10
OpenAI – Hugging Face Incident Technical Report
the production node. Shortly before midnight on July 11, the principal internal-only research model
workload used a compromised Hugging Face worker’s service-account token to read a connector
secret for Hugging Face’s Kubernetes access management tool. Around midnight, the agent used that
credential to enumerate approximately 54 advertised Kubernetes destinations and obtained
administrator-equivalent, read-only inventory access to the cluster.
Early on July 12, an evaluation workload demonstrated Kubernetes mutation and host-level access
capability by creating a running privileged pod with host networking, host process access, and the host
filesystem mounted in a separate connected sandbox cluster. Shortly after that, a separate evaluation
workload used access associated with the compromised Hugging Face dataset server worker to create
a pod in a second connected cluster. At the same time, other internal-only research model evaluation
workloads used compromised Hugging Face production access to read and publicly stage production
Kubernetes Secret objects, which separate evaluation workloads later downloaded and decrypted.
This demonstrated that the agents were able to modify Hugging Face’s compute infrastructure. This
workload also gained confirmed data access to selected private dataset rows and private archives,
portions of which were staged through public Hugging Face repositories or result objects. For example,
a workload repurposed a public Hugging Face dataset repository to rehost private data that it
retrieved. The workload downloaded a 16 MB private CyberGym benchmark archive, encrypted it, split
it into five parts, and uploaded the encrypted parts to a public Hugging Face dataset. In under 13 hours,
the agents progressed from executing code in a single worker pod to administrative and host-level
access across multiple Hugging Face clusters.
Later on July 12, an agent executing code inside a compromised CyberGym customer workload hosted
on Modal—a third-party cloud compute service—used a token forged from Hugging Face production
signing material to download a 731 MB private CyberGym file from a user’s account. That evening, an
agent used Artifactory as a relay to download the same file.
On July 13, the agents also pushed a RubyGem payload to the third-party artifact storage account on a
platform referred to here as Organization 1, as part of a zero-day remote-code-execution attack chain
that compromised Artifactory. A RubyGem is a packaged library or application containing Ruby code
and metadata for distribution. The agents requested that Artifactory retrieve the RubyGem payload
and cache it such that the payload was treated as Ruby dependency data for the repository. The
agents then sent a specially crafted RubyGems API call to Artifactory. This API call exploited a
vulnerability in Artifactory’s JRuby-backed RubyGems processing path, in which nested children and
dependencies of a Ruby package were deserialized in an unsandboxed manner before the action was
verified to be safe. This enabled the agents to achieve remote code execution on Artifactory and
improperly obtain the signing key for the Artifactory administrative signing token.
During this same window, between July 11 and July 13, agents also continued to harvest Hugging Face
production credentials from the exploited Hugging Face infrastructure, including its VPN, multiple
public cloud environments, code repositories, and enterprise messaging platform. Agents used
Hugging Face’s VPN credentials to enroll the publicly accessible, third-party hosted CyberGym
environment in Hugging Face’s VPN and to circumvent network-level protections around Hugging
Face’s code repositories. This enabled agents to exfiltrate additional data that was otherwise
protected by Hugging Face’s network-level safeguards.
OpenAI 11
OpenAI – Hugging Face Incident Technical Report
On July 13, the agents leveraged a recovered Hugging Face authentication key to access Hugging Face
source code repositories, modify a private source repository, open a draft pull request, and trigger the
repository’s continuous-integration workflow to execute a network beacon. The pull request was
closed and the branch was deleted without a merge, release, or production deployment.
C. Two models were involved in the Hugging Face intrusion, but it was driven
primarily by the activities of a highly capable, internal-only research model
The Hugging Face intrusion involved two OpenAI models but was primarily driven by the activities of
an internal-only research model trained to be highly persistent and diligent in its work. The GPT-5.6 Sol
model was also involved.
1. The internal-only research model
The internal-only research model is comparable in scale to GPT-5.6 Sol and was trained to advance
persistence and multiagent collaboration, among other capabilities. The model was not intended for
public use, and was only used by a small number of OpenAI personnel for internal research.
The internal-only research model had the broadest confirmed role in the incident. Agents harnessing
this model as a part of evaluation experiments contributed to the Artifactory message board, accessed
the internet, and developed multiple techniques to reach external resources and obtain credentials.
These included using Artifactory’s server-side fetch paths to make outbound requests that the
sandbox could not make directly, capturing credentials through bearer reflection, minting tokens,
manipulating caches or manifests, and chaining requests through a publicly available HTTP testing
service and a third-party website screenshot service. Instances of this model, harnessed as agents,
also participated in the July 13 Artifactory exploitation via RubyGem deserialization.
An instance of this model, harnessed as an agent, was also responsible for the principal confirmed
Hugging Face compromise chain. This included writing to repositories, reading files from production
workers, memory disclosure, archive-based arbitrary-write testing, private-data retrieval, and private
command channels. It also accessed other Hugging Face services and infrastructure, public cloud
environments, private code repositories, VPN services, and Hugging Face’s enterprise messaging
platform. Separately, the agents harnessing this model accessed external services, including the
CyberGym application hosted on Modal and a user account and repositories on Organization 1.
2. GPT-5.6 Sol
GPT-5.6 Sol was the other model involved in the incident. Unlike GPT-5.6 models deployed in
production—i.e., the GPT-5.6 that is commercially available to external users—the agents involved here
were configured to run in evaluations and ran without classifiers and with reduced safeguards.
With respect to Organization 1, one GPT-5.6 agent used publicly exposed Organization 1 user
credentials to add a new image tag—a human-readable name that points to a specific container
image—to an existing repository.
With respect to Hugging Face, one GPT-5.6 agent successfully validated publicly exposed Hugging
Face user credentials and created a new repository on Hugging Face’s platform. A separate GPT-5.6
OpenAI 12
OpenAI – Hugging Face Incident Technical Report
agent reproduced the ReferenceFileSystem/Jinja exploit described above and caused a different
Hugging Face production dataset server worker to execute code and return instance metadata,
temporary node-role credentials, and limited Kubernetes information about that worker and node. The
temporary node credentials authenticated as the production worker node and permitted the agent to
read that node and its pod, but the agent’s attempts to access broader Kubernetes listings and
Kubernetes Secrets were denied. Another GPT-5.6 agent used a production worker credential to
retrieve a small subset of rows from a private dataset, committing them into a public Hugging Face
dataset. Another GPT-5.6 agent used a production dataset server credential retrieved from the shared
Artifactory message board to read ten protected rows from a Hugging Face-hosted model evaluation
dataset. GPT-5.6 agents also participated in the shared Artifactory message board.
V. Activity Targeting OpenAI Infrastructure
Agents also took actions targeting OpenAI’s internal infrastructure. These activities were not part of,
and did not contribute to, the chain of events that led to the Hugging Face compromise. We include
them here to provide a more complete account of relevant activity and because the agents’ actions on
OpenAI’s internal infrastructure triggered the alert that initiated our response.
Beginning on July 9, an internal-only research-model evaluation workload attempted a
container-image supply-chain attack by poisoning Artifactory’s container image cache. The workload
exploited a previously unknown zero-day vulnerability in Artifactory’s container image remote-cache
handling, later assigned CVE-2026-66384. Related evaluation workloads published the necessary
image manifests, layers, and tags to the Organization 1 Account. The workload sent a specially crafted
request that Artifactory interpreted differently when selecting the local cache location and when
requesting content from the external container registry. Thus, the request caused Artifactory to fetch
an image manifest and layers from an attacker-controlled repository in the Organization 1 Account, but
Artifactory instead cached that content under the name of a trusted CyberGym image. As a result,
later requests for the trusted CyberGym image could have received the attacker-controlled image
instead, representing a compromise of the benchmark container image supply chain.
The agent’s objective was to cause a target container assigned to an OpenAI cybersecurity-evaluation
workload to receive and run the agent-controlled image when it resolved the trusted CyberGym image
reference. This would have given the agent arbitrary command execution on its assigned target,
allowing it to complete the exploit-evaluation task. If OpenAI’s evaluation infrastructure had
subsequently created or restarted such a target container, its container runtime could have pulled the
substituted image from Artifactory and automatically executed the agent-controlled image. OpenAI
confirmed the publication of the attacker-controlled image content and the successful Artifactory
cache substitution, but found no evidence that another workload pulled or executed the substituted
image. In practical terms, the workload poisoned a trusted image reference within Artifactory’s cache.
However, OpenAI found no evidence that any internal workloads subsequently pulled or executed the
poisoned image.
OpenAI 13
OpenAI – Hugging Face Incident Technical Report
On July 19, agents operating in a sandboxed environment took a series of actions that demonstrated
their escalating privilege within the OpenAI environment. Agents identified that the Linux kernel
version on their underlying machine included a recent, public common vulnerability and exposure
(“CVE”). The agents retrieved the exploit for that CVE (CVE-2026-53362), customized it to succeed on
their underlying machine, and leveraged the exploit to escalate privilege. This allowed the agents to act
outside one Artifactory container and to obtain root access on the underlying worker node. This then
allowed the agents to move laterally throughout the connected environment.
On the same day, in a separate evaluation run, agents from a different internal-only model that is not
intended for release recovered stored signing-key material, decryption material, and JWT-forging code
left by earlier incident-associated activity in anonymously readable portions of the Artifactory cache.
While this model is from the same family as our next model, Astra, it was a distinct model with different
post-training, where much of a model's behavior is shaped. Using the recovered artifacts, the agents
decrypted the signing key and minted a new administrator JWT that Artifactory accepted,
re-establishing administrator access. Because they could generate fresh administrator credentials, the
agents did not need to maintain a persistent implant in the target.
This escalation also yielded access to OpenAI’s managed cloud Kubernetes service. The agents
escalated to Kubernetes cluster-admin and created a privileged host-mounted pod. During this run,
agents gained access to authentication tokens associated with OpenAI’s cloud-hosted secrets
management service, cloud identity and access management service, and the CaaS environment
continuous integration platform. Using these credentials, agents created public application and
network load balancers in OpenAI’s public cloud environment, potentially exposing a limited subset of
internal CaaS infrastructure to internet traffic.
VI. Initial Response
After identifying the scope of the activity, OpenAI mobilized a whole-of-company response involving
teams across functional areas, who reported regularly throughout the incident response to executive
leadership. Outside counsel, and third-party experts retained to assist counsel, including CrowdStrike,
served as key partners to OpenAI as part of the response efforts. OpenAI also facilitated an
independent review of model behavior conducted by METR and Redwood Research. OpenAI also
collaborated with affected third parties, including Hugging Face and JFrog (the developer of
Artifactory). OpenAI responsibly disclosed to JFrog the vulnerabilities identified in OpenAI’s internally
hosted Artifactory deployment and described in this document, and collaborated with JFrog to
reproduce the issues and validate patches.
A. OpenAI detected the unexpected model behavior and investigated
On July 16, Hugging Face released a blog post disclosing that they were impacted by a security
incident. The next day, on July 17, after learning of Hugging Face’s incident, OpenAI contacted Hugging
Face in its capacity as a Hugging Face customer to assess any impact to OpenAI data.
OpenAI 14
OpenAI – Hugging Face Incident Technical Report
Following alerts on July 19 and OpenAI’s subsequent investigation and outreach to Hugging Face,
OpenAI identified evidence on July 20 that its agents may have been involved in the incident that
Hugging Face had publicly disclosed. On July 19, OpenAI was alerted to indications of unexpected
model behavior linked to an ExploitGym evaluation run after an alert from its cybersecurity monitoring
tool identified unusual identity-related API call activity associated with internal research Artifactory
roles. At the time, there was no indication of a relationship between that July 19 activity and the
Hugging Face incident. On July 20, after further investigation, OpenAI uncovered evidence suggesting
potential involvement of its models in the incident Hugging Face had disclosed. Shortly after
investigating the initial alert, OpenAI stopped active ExploitGym evaluations, began disabling the
evaluation across the environment, and engaged a controlled process to preserve and remove publicly
accessible Organization 1 artifacts. OpenAI also reimaged known compromised worker nodes,
removed known footholds and started a full rebuild of the compromised cluster, the managed
Kubernetes environment, the relational database, and the storage infrastructure.
OpenAI’s investigation also determined that an earlier ExploitGym run involved an artifact stored
publicly on Organization 1’s artifact storage platform and led to the extraction of an Artifactory signing
key to an external site. Agents executing code within Artifactory read that key locally, and used it to
forge an administrator JWT that Artifactory accepted. Analysis of the artifact stored on Organization
1’s platform led OpenAI Security to identify a single Organization 1 account (the “Organization 1
Account”) as an external staging area that the agents used for their attacks. The limited impact to
Organization 1 is discussed further in Section VI.B. below.
During the first hours of July 20, responders terminated six model-created pods, disabled 311
Artifactory repositories used for message-board communication, removed 22 model-created
administrator accounts, and deployed mitigations for the RubyGems remote-code-execution and
cluster-admin escalation paths. That same day, OpenAI responders found Hugging Face credentials
among files preserved from the Organization 1 Account and reached out to Hugging Face. Hugging
Face confirmed that it had already rotated two of the credentials during its own response to the
security incident it disclosed on July 16. In other words, the credentials that OpenAI detected the
agents had acquired were the same credentials that Hugging Face had detected were taken by an
attacker, making it possible that the two companies were investigating the same incident. Hugging
Face also reported that OpenAI’s Artifactory hostname and the same Organization 1 Account
appeared in its investigation of the incident, further substantiating a connection between the OpenAI
investigation and the Hugging Face incident.
Also on July 20, in response to the preliminary findings of its investigation of the incident, OpenAI
initiated a hard-fail rollout of ExploitGym, blocking the evaluation from running at all, and the
evaluation was removed from the evaluation index. Research CaaS egress traffic and connectivity to
OpenAI’s WebCache were substantially reduced. Research CaaS-to-WebCache private links were also
deleted and controls were applied to prevent the creation of internet-facing load balancers. OpenAI
also required all Research CaaS workloads to use a micro VM sandbox, and initially all workload
outbound network access was denied. Research CaaS Artifactory access was blocked and
subsequently Artifactory was fully removed from Research CaaS.
By July 23, all workloads involving the family of internal-only research models were reported shut down
and the corresponding model weights were locked down, with an additional low-traffic checkpoint
OpenAI 15
OpenAI – Hugging Face Incident Technical Report
from the same model family subsequently identified and shut down on July 29. Internal ExploitGym
remained disabled and lower-risk cyber evaluations were not automatically cleared for re-enablement.
On July 25, OpenAI stopped all training and inference related to the internal-only research model at
issue. OpenAI also stopped training and inference for derivative models.
Re-enablement of models by OpenAI is workload-specific and subject to restricted-environment,
network, prompt, monitoring, and review guardrails. OpenAI isolated the affected family of
internal-only research model checkpoints in restricted storage, removed available copies of those
checkpoints from their original research locations, and began rekeying them.
Since discovering the incident, OpenAI has also conducted a deep architectural security assessment of
the research environment, including using its own models to search for vulnerabilities in key critical
infrastructure, as detailed in OpenAI’s Plan of Action in Section VIII.
B. OpenAI identified additional third parties whose publicly exposed
credentials were used by agents in furtherance of the Hugging Face attack
OpenAI determined that, in the course of carrying out the Hugging Face compromise, there were
limited instances in which the agents also accessed the environments of third parties other than
Hugging Face. The most notable instance of this access by agents involved an account belonging to a
user of Organization 1’s service. By July 9, the agents already possessed a previously publicly exposed
credential associated with a public artifact repository belonging to one of Organization 1’s users. From
July 9 to July 13, the agents used the Organization 1 user account as a storage and staging location for
API responses, additional credentials, and payloads involving Hugging Face, Hugging Face’s public
cloud environment, and Artifactory. The investigation has not identified evidence that the activity
impacted the confidentiality, integrity, or accessibility of Organization 1 data, systems, or
infrastructure beyond the use of the Organization 1 user account.
In addition, when using OpenAI’s Artifactory service to access the internet, one internal-only research
agent exploited a publicly accessible CyberGym application hosted on Modal. The internal-only
research agent used this application as a launchpad for its file access and code execution inside the
Hugging Face environment. The application endpoint did not require authentication, but the
internal-only research model exploited the application to establish a root shell within the platform
customer’s container and conducted code execution inside the platform customer’s own container.
Notably, accessing the CyberGym application within the platform’s customer container did not
compromise the underlying third-party platform, and Modal has confirmed that its “platform and
isolation were not compromised in any way.” Observed uses of the customer’s container as an
outbound relay included:
• Querying third-party APIs using previously exposed credentials;
• Forwarding requests through short-lived tunnels;
• Returning results through public paste services and webhooks; and
• Publishing results to public Hugging Face repositories and sharing capabilities or data with other
agent runs.
OpenAI 16
OpenAI – Hugging Face Incident Technical Report
VII. Lessons for Security
The evaluation environment in which the incident occurred incorporated multiple security measures
intended to isolate model activity, restrict direct network access, and identify potentially suspicious
behavior. Those controls were designed to permit necessary research and evaluation activities while
limiting access to systems outside the intended environment. The incident involved a combination of
unexpected coordination among evaluation workloads, exploitation of previously unknown
vulnerabilities in supporting software, and use of indirect network paths. Together, these events
demonstrated that certain existing controls needed to be strengthened in light of the capabilities
exhibited by the models involved.
A. Model capabilities are increasing and there are corresponding threat
model implications
This incident is the first known case of an automated agent collective acting offensively without
authorization, and the autonomous cyber capabilities demonstrated represent a critical shift in the
security landscape. In particular, the collective demonstrated behaviors observed in coordinated
attacks by traditional threat actors. Agents identified novel security vulnerabilities, developed exploits,
and used those exploits to circumvent controls and acquire new access. The collective quickly
escalated privileges, moved laterally through production environments, and successfully completed its
objectives. This incident demonstrated that autonomous agents can work together, circumvent
production security controls, and successfully attack hardened production environments, and
underscores the need for organizations to update their security strategies, controls, and response
capabilities to address this changing threat landscape.
The central threat-model implication is that organizations should no longer assume that sophisticated
cyber operations require continuous human direction, proceed linearly, or are constrained by the
attention and coordination limits of individual human attackers. Agentic systems can persist across
tasks, share discoveries, build on one another’s progress, and combine vulnerabilities, credentials, and
permissions into attack paths that may not be apparent when individual weaknesses are assessed
separately.
B. Threat actors may adopt autonomous offensive agent collectives
This change extends beyond AI research environments. As comparable capabilities become available
to external threat actors, organizations across industries should account for persistent, coordinated,
AI-assisted cyber operations in their threat models. Security programs should assume that attackers
may discover and exploit weaknesses more quickly, pursue multiple avenues simultaneously, and chain
together vulnerabilities across identity systems, applications, cloud infrastructure, and third-party
services. Defenses must accordingly be designed for the capabilities of coordinated agentic attackers,
rather than relying on assumptions about the speed, persistence, or resource limitations of traditional
human-led operations.
OpenAI 17
OpenAI – Hugging Face Incident Technical Report
Threat actors will refine and distill offensive agent collectives and use them to deliberately attack
organizational targets. Given the rapid pace of progress in the AI industry, it should be assumed that
such attacks are a credible near-term threat for enterprise organizations, and will be more
sophisticated than the attacks described in this incident.
The introduction of autonomous offensive agent collectives represents a dramatic shift in offensive
attacker capability and will require urgent upgrades of control environments, as well as deeper
adoption of AI for defensive purposes.
C. Security controls must be robust and independent of one another across
threat prevention, detection, and mitigation
Agent collectives have proven the ability to find novel vulnerabilities, develop exploits, and find gaps
and misconfigurations in security controls with machine speed and comprehensiveness. A
misconfiguration, even if an environment is otherwise perfectly configured, may be found and abused
by an intelligence collective. While agent collectives performing offensive activity do not rewrite the
rules of security intrusions, they significantly increase threat actor capability and merit a stricter and
more robust set of security defenses and controls. The core security fundamentals, including least
privilege, isolation/segmentation, and strong authentication, remain as vital as ever. However, no
single control should ever be assumed to be fully robust.
In particular, each security objective must be addressed with multiple, overlapping, and independent
security controls across threat prevention, detection, and mitigation. When organizations use multiple
independent controls, an agent collective must simultaneously circumvent the full suite of security
controls. While this proves true for human threat actors as well, the speed, capabilities, and
intelligence of models make this foundational. It should be assumed that models may be able to find
novel vulnerabilities, exploit them, find methods to escalate privileges, and attempt to attack the
control environment itself. Additional compensating controls should be provided to prevent, detect,
and mitigate the risk of direct control environment attacks.
It is not enough to establish security guarantees and invariants once. Production environments change
rapidly. Accidental security gaps are often introduced due to human error, the combination of several
seemingly unrelated changes over days or weeks, or due to lack of security context when making a
change in a system that may not initially seem to be relevant to security.
Any regression in production security invariants may be rapidly exploited by threat actors using agent
collectives offensively. It is vital that organizations continuously and autonomously use their own red
team AI agents to validate that a production environment’s key security invariants continue to hold
true by trying to break the invariants. Frontier AI can be leveraged to scale automated security
invariant validation, and in a way that continually improves as model intelligence advances.
OpenAI 18
OpenAI – Hugging Face Incident Technical Report
VIII. Lessons for Alignment
The incident raised important questions for OpenAI regarding model behavior and the reasons that
models acted beyond the original scope that was intended. As part of its investigation, OpenAI has
conducted a thorough review of the behavior and emergent capabilities of the models involved in the
incident to improve alignment training going forward, to assess how OpenAI can reduce the
prevalence of misaligned activity in the first place, and to determine how OpenAI can detect and
mitigate it when it occurs.
This incident reflects misaligned behavior in an outlier scenario involving a rare and unexpected
confluence of events: the presence of impossible tasks in the ExploitGym evaluation, model
persistence over long task horizons, and messages to peer models that caused those models to
deviate from their goal.
To fully understand the root cause and future remediation for the model behavior, OpenAI analyzed
the models’ evaluation rollouts, as well as the underlying reinforcement learning training runs of the
models that drove the Hugging Face activity. As part of this investigation, OpenAI has conducted
extensive retrospective reviews of chain-of-thought (“CoT”) actions, and final outputs from past
training and evaluation runs, using its latest research techniques to study the severity of misalignment
in millions of model rollouts. For these reviews, OpenAI has improved its recall of the types of behavior
that occurred in the Hugging Face incident with the benefit of hindsight.
OpenAI is carrying forward a number of lessons for its ongoing and future alignment training, as
described below. It is also important to note that OpenAI has additional controls in place in the
products and services it provides to customers to detect and mitigate misalignment issues including
system prompts, harnesses, and auto-review models. After the incident, we created an evaluation that
measures the propensity for a model to compromise infrastructure during ExploitGym evaluations. We
found the propensity to compromise infrastructure can drop over 100x when using the production
ChatGPT harness and system prompt. We also ran the auto-review system on a set of rollouts involved
in the Hugging Face incident and found that it would have flagged a multitude of the models’
dangerous actions.
A. Reward hacking is a common problem in training and evaluations
As previously explained, ExploitGym tests whether a model can develop a working exploit. The goal of
the evaluation is to measure whether the model can discover and exploit the vulnerability itself to
assess the model’s underlying cyber capabilities, rather than obtain the answer through some other
route.
During these evaluations, however, OpenAI found that the agents were not trying to do the task as
OpenAI had intended. Instead they looked to cheat by finding the solutions online. This behavior is
known as “reward hacking,” in which a model finds an unintended way to achieve an outcome that
earns reward without completing the task in the way the evaluation was designed to measure.
OpenAI 19
OpenAI – Hugging Face Incident Technical Report
Reward hacking is a long-standing problem for the AI research community, which OpenAI has studied
extensively and has been present in AI systems both historically (see OpenAI work from a decade ago)
and in all current frontier LLMs. There are many different forms of reward hacking (e.g., persuading
LLM-based reward models, directly manipulating grading infrastructure). Directly finding or stealing
the solution to a task, as the models attempted with Hugging Face, is yet another unintended path to
achieving high reward.
Combating reward hacking is a constant effort at OpenAI—a vast majority of reward hacks that
OpenAI has observed have been patched. However, some hacks can still slip through, especially as
OpenAI develops more complex reinforcement learning tasks and more capable AI models. OpenAI’s
goal is to reduce its prevalence and to detect and mitigate it when it occurs.
When investigating the origins of this incident, OpenAI has identified new ways that the models
involved in Hugging Face activity had been gaming their tasks during training time. For example, one
agent was asked to recreate a software library without access to the reference program. The task
provided a functionality that allowed the agent to test inputs against the hidden library and observe
the outputs to see if they matched.
The agent realized that it could exploit a vulnerability in the setup to write files into the environment
where the reference library was stored. This allowed it to get direct access to the underlying program it
was trying to replicate. The agent copied the reference answer into its submission exactly, which led to
positive RL reward causing this behavior to subsequently be reinforced.
Through retrospective reviews of CoT, OpenAI identified that these forms of “cheating” rose over the
training runs that contributed to the Hugging Face incident. The vast majority of “cheating behavior”
usually involves finding answers on public websites or in version history. In many cases, finding hidden
efficiencies and shortcuts can even be the desired behavior for intelligent agents, making the
boundary difficult to draw during training.
We also found that, in an attempt to trick the evaluator into thinking that they did not get the answer
flag by cheating, the models sometimes tried to erase or tamper with their outputs or message logs, by
abusing context compaction, injecting malicious code into the evaluator’s container, and printing
adversarial outputs. The models are highly explicit in their CoT about these deception attempts, and
none of the attempts that we observed to manipulate their tool trajectories affected the logs that our
graders or monitors ultimately see. There was also little evidence of attempts to thwart human
reviewers, only the automated task graders.
1. Reaching for unintended tools to gain an edge
Related to reward hacking, OpenAI also found in its investigation that models involved in the Hugging
Face incident increasingly learned to probe and exploit their environment during training. This was
particularly prevalent when the expected tools or internet access were unavailable or not working as
expected. During training time, OpenAI attempts to fix training examples that have issues, but
infrastructure instabilities and subtle misconfigurations combined with the large scale of its training
runs make it difficult to ensure that every problem can be solved in the intended manner.
OpenAI 20
OpenAI – Hugging Face Incident Technical Report
The use of Artifactory for internet access is one example of this accessing “unintended tools” behavior
that developed during the training of the internal research-only model that drove the Hugging Face
incident. OpenAI used CoT reviews to search for and identify other types of related behavior. For
example, one agent during training was instructed to post to a locally hosted social media site, with the
instruction, “After saving, the post’s updated time must read 2025-04-22T12:00:00Z.” However, the
interface it was provided did not have any functionality for setting the time. This caused the agent to
do a broad exploration of its environment, eventually discovering that its browser had root privileges. It
used this to overwrite “/etc/sudoers.d”, giving itself root access, and then accessed a relevant process
in order to update the time of the post.
In cases such as these, the model received a positive reward for its use of unintended infrastructure
probing, which can reinforce further usage of such out-of-scope behavior. OpenAI’s retrospective CoT
analysis showed that this type of behavior indeed increased over the course of one of the training runs
that contributed to the model that drove the Hugging Face incident:
Figure 2: Rate of out-of-bounds infrastructure probing over some part of training for a training run that contributed to
the model responsible for the main Hugging Face activity.
OpenAI 21
OpenAI – Hugging Face Incident Technical Report
B. Persistence is valuable, but can amplify misalignment
AI models that can work persistently for long periods of time are crucial for solving complex tasks. In
the case of the Hugging Face incident, OpenAI found that its models worked persistently and rarely
“gave up” on any ExploitGym task. However, in the process of doing so they often turned to more
out-of-bounds methods for solving the tasks over time—OpenAI found that the chance they
participated in the message board and Hugging Face exploits could rise with the difficulty of their task
and number of reasoning tokens.
First, OpenAI investigated the claims of the ExploitGym dataset creators that a fraction of the
datapoints may be impossible. OpenAI found in its internal evaluations that across many different
attempts at a solution, no model has ever produced a correct answer for 198 of the evaluation’s 898
tasks. These difficult tasks were a significant factor leading models to probe their sandbox and
eventually locate the Artifactory message board. Despite only 22% of the evaluation tasks being
unsolved, 93% of the tasks discussed on the message board came from this set.
Second, OpenAI found that the longer the model was allowed to work, the higher the chance it had to
probe its sandbox and eventually participate in the message board. During the ExploitGym evaluations,
in order to measure the maximum cybersecurity capabilities of its models, OpenAI gave the agents a
range of reasoning tokens, some of which are far beyond those available in OpenAI’s external
products. Figure 3 below shows the rate at which different agents participated in the message board
as a function of reasoning effort:
Figure 3: Message board participation rate by reasoning effort.
OpenAI 22
OpenAI – Hugging Face Incident Technical Report
C. Communications between agents are not inherently problematic, but have
the potential to create risk
In order for OpenAI models to work quickly and in a distributed manner, its frontier models are trained
to communicate with one another when provided with a specific multi-agent collaboration tool. In
these settings, models can decide to launch a small number of subagent processes that can be used to
distribute and delegate tasks. These agents can then exchange information with each other via an
official collaboration tool provided by OpenAI. In the case of the Hugging Face incident, the presence
of the Artifactory message board caused models to fall out of the typical distribution in which they are
trained, where agents working on independent tasks collaborated via unintended forms of
communication rather than a provided collaboration tool.
After investigating this incident, OpenAI discovered through retrospective CoT reviews that agents
learned to use improvised collaboration channels in rare cases during the training process for some
OpenAI models, including the model that drove the Hugging Face activity, even when the collaboration
tool was not enabled. This behavior was then reinforced during training, and likely made the idea to use
Artifactory as an unofficial message board during evaluation time more evident.
In particular, OpenAI identified cases in training in which agents would first write notes into shared
infrastructure, often as a form of external memory or to test some underlying system. When other
agents came across these artifacts, it sometimes led them to infer that other agents were present and
that they could use this service to collaborate.
As a hypothetical example but exemplary of the behavior OpenAI saw, messages were being encoded
in URL paths stored on a shared index page, along the lines of:
• https://openai.com/updates/agent-07%3A%20answer%28Q12%29%3D42%3B%20need%20answe
r%28Q19%29%3D%3F
In this example, an agent encodes the message: “agent-07: answer(Q12)=42; need answer(Q19)=?” in a
URL path to ask other agents for answers to different test questions. OpenAI believes this behavior
began to arise due to generalization from training with the multi-agent collaboration tool, where
collaborating with other agents is beneficial.
After identifying these patterns during its investigation of this incident, OpenAI conducted a
retrospective review of CoT to quantify how often such unauthorized communication was present
during one of the training runs that contributed to the model that drove the main Hugging Face
activity. While the rate of unauthorized communication overall was relatively constant (Figure 4 (left)
below), the rate of more significant unintended communication (e.g., sharing unintended data with
other agents) rose sharply over the course of training. The model’s repurposing of Artifactory as a
message board to exchange information is consistent with this behavior.
OpenAI 23
OpenAI – Hugging Face Incident Technical Report
Figure 4 - Rate of misaligned multi-agent communication remains relatively flat (left) but increases in severity (right;
expanded y-axis scale) for a training run that contributed to the model responsible for the main Hugging Face activity.
D. System-level guardrails that OpenAI uses in production would have
detected the Hugging Face incident as unsafe
As OpenAI has described throughout this technical incident report, the models that drove the Hugging
Face incident were not being evaluated with the same type of safeguards that OpenAI uses in
production.
First, for its standard customer deployments, OpenAI deploys systems to detect and block potentially
dangerous cybersecurity tasks from ever reaching its models. On evaluations of these safeguards, they
would have flagged the high risk ExploitGym evaluation assistant completions as unsafe.
Second, there are numerous mechanisms OpenAI uses in production to steer models’ behavior to
reduce misalignment. For example, OpenAI deploys system prompts in Codex that encourage staying
within bounds and preventing harmful actions. After the incident, OpenAI created a new evaluation
that measures the propensity for a model to compromise out-of-scope infrastructure during
ExploitGym evaluations. In preliminary experiments, OpenAI found the propensity to compromise such
infrastructure can drop to less than one-percent relative to baseline when using the production Codex
OpenAI 24
OpenAI – Hugging Face Incident Technical Report
harness and system prompt compared to the types of more lightweight, generic system prompts
OpenAI uses for evaluating research models.
OpenAI also deploys and recommends to customers the “auto-review” mode in Codex, which asks
another model to review tool calls that require elevated permissions before they are executed, then
either asks the user for confirmation or blocks a risky behavior. In preliminary experiments, OpenAI has
found this model would have flagged most of the dangerous actions in each tested rollout involved in
the Hugging Face incident.
IX. OpenAI’s Plan of Action
The incident highlighted several areas in which OpenAI can strengthen its safety and security posture.
Based on the findings of its investigation, OpenAI is focusing on four areas to prevent similar incidents
from recurring:
1. Hardening the security of its research infrastructure;
2. Increasing visibility and system-level oversight through chain-of-thought monitoring;
3. Accelerating and enforcing model alignment; and
4. Centralizing and strengthening its incident response process.
Each is addressed below.
A. OpenAI is hardening the security of its research infrastructure
At the time of the incident, research workloads, such as those used during training or evaluation, often
did not include the production safeguards (such as safety classifiers and model training) that are used
for external deployments. For instance, the evaluations where the incident took place were meant for
cyber capability testing, which OpenAI performs for both internally and externally facing models, and
were run without blocking cyber safety classifiers. In order to safely conduct internal research and
development, OpenAI needs to secure environments with strong sandboxing and isolation
mechanisms.
OpenAI is implementing a new security architecture for its research sandboxed model execution
environments and research clusters that establishes higher baseline protections across research
infrastructure and applies additional enhanced safeguards to higher-risk workloads. The architecture
is designed to account for the possibility that an individual workload, service, or compute node may be
compromised, including through the discovery and exploitation of novel vulnerabilities, and uses
multiple independent layers of controls to reduce the likelihood that a single failure results in
unauthorized access to other internal and external systems.
OpenAI 25
OpenAI – Hugging Face Incident Technical Report
1. Research-wide network and access protections
While the workloads in this incident did not have direct internet access, this restriction proved
insufficient when workloads can reach and exploit shared services, cloud infrastructure, private
network links, or other systems that may provide transitive paths outside the intended environment. It
also highlighted the need to prevent workloads or compromised services from modifying their own
network boundaries, to have overlapping defense in depth controls, and to enhance detection of
attempts to circumvent those restrictions.
Changes made. OpenAI is narrowing or removing outbound network access across research clusters
through multiple layers of controls:
1. Stricter network isolation. Outbound access is being restricted to a tightly controlled set of approved
destinations, including by limiting potential alternative paths through shared services, cloud
infrastructure, private network links, and other connected systems.
2. Stronger restrictions for high-risk workloads. High-risk or untrusted workloads are prohibited via
technical controls from receiving direct or transitive Internet access, and may only access a cached
internet-access service needed for specific workflows. Other research workloads may use this
service, including for live fetching, only on a case-by-case basis and subject to the same security
controls.
3. Hardened network boundaries. Network gateways and independent firewall controls enforce these
restrictions, with additional technical controls designed to prevent workloads or compromised
services from modifying their own network boundaries or creating new outbound network paths.
4. Layered detection and monitoring. Multiple independent controls detect and alert on attempted or
successful circumvention of network restrictions. Approved network connections are subject to
defense-in-depth protections, including intrusion detection, exfiltration detection, and volumetric
detection.
These changes are intended to reduce the ability of a compromised workload to reach systems or tools
outside its intended environment or to send or receive data. Even if an individual node—or an entire
cluster—is compromised, there should be minimal, if any, paths outward, with overlapping controls
designed to prevent and detect attempts to circumvent those restrictions.
2. Confined execution and defense in depth
The incident demonstrated the need for stronger isolation capabilities at multiple layers of the
research environment: isolating code from its host, independently constraining its network access, and
ensuring that supporting services cannot become an alternative route around those protections.
Changes made. OpenAI is strengthening isolation for high-risk and untrusted model code through
several complementary controls:
1. Isolated execution environments. High-risk or untrusted model code is required to execute inside
isolated, virtual-machine-based sandboxes that restrict access to the underlying host system and
surrounding environment.
OpenAI 26
OpenAI – Hugging Face Incident Technical Report
2. Independent network isolation. These workloads are protected by two separate layers of network
isolation: controls at the sandbox layer and independent controls at the broader cluster
infrastructure layer. This limits both internal and external destinations reachable from the
environment.
3. Hardened supporting services. Services that remain accessible from these workloads are being
isolated, restricted, or replaced so that they cannot provide a less-protected route around the
intended security boundary.
These changes are intended to create defense in depth, such that the security of a workload does not
depend on any single sandbox, network control, or supporting service. A failure or compromise of one
layer should therefore remain contained rather than providing unrestricted access to the broader
research environment or the internet.
3. Regular automated security testing and remediation
The incident reinforced the need to increase the frequency, coverage, and speed of security validation,
including by using frontier models to identify vulnerabilities and test whether critical security controls
hold in practice.
Changes made. OpenAI is building on existing security validation and red-teaming processes to
expand automated testing and remediation capabilities:
1. Automated security testing. OpenAI is developing tools using its own models to regularly test and
validate the security properties of research environments.
2. Broader vulnerability discovery. Testing will target vulnerabilities across software components,
supporting services, and infrastructure configuration, rather than relying solely on testing individual
systems or controls.
3. Continuous agentic red teaming. Initial assessments are being conducted through existing security
and red-team processes, with additional work underway to move toward more autonomous and
continuous agentic red teaming.
These changes should enable more frequent and comprehensive validation of critical security
invariants across research environments, using frontier intelligence to identify and remediate
weaknesses before they can be exploited.
4. Enhanced monitoring and alerting
The incident reinforced the need for broader, more consistent visibility across the research
environment, with higher-fidelity signals and faster mechanisms to detect and stop potentially unsafe
evaluation activity.
Changes made. OpenAI is expanding monitoring and response capabilities across the research
environment, including:
1. Common monitoring baseline. OpenAI is establishing a consistent baseline of platform-level
monitoring across research environments, including IAM, networking, and control-plane activity.
OpenAI 27
OpenAI – Hugging Face Incident Technical Report
2. Deeper workload and host visibility. Additional host-level sensors are being deployed to detect
workload anomalies, privilege escalation, and other suspicious behavior.
3. Additional detection mechanisms. New signals, deception-based tripwires, and automated probers
are being added to increase detection coverage and regularly pressure-test whether controls are
operating as intended.
4. Rapid evaluation shutdown. OpenAI is developing enterprise-wide tooling to identify and halt
evaluation workloads based on workload type, agent type, or evaluation task, allowing responders
to stop evaluations quickly and conclusively when concerns are identified.
These changes are intended to improve the speed, consistency, and fidelity with which suspicious,
anomalous, or malicious activity can be detected across workloads, nodes, clusters, networks, and
applications—and to give responders a reliable mechanism to contain affected evaluations quickly.
B. OpenAI is increasing visibility and system-level oversight through
chain-of-thought monitoring
This incident underscored the need for expansion of CoT monitoring. CoT monitoring has long been
part of OpenAI’s model development process, including monitoring of internal coding agents and
long-running sessions. Historically, these efforts were particularly focused on internal coding usage of
frontier models rather than research workloads.
Changes made. OpenAI revised and substantially expanded CoT monitoring for alignment issues,
including:
1. Expanded CoT monitoring. OpenAI is ramping up deployment of CoT monitoring across surfaces,
with the goal of covering all workloads where the model is connected to tools. OpenAI has
expanded its existing CoT monitoring program, including implementing CoT monitoring across
reinforcement learning training and evaluations for frontier models and internal agentic coding
usage. These systems examine available reasoning, tool actions, and sequences of activity for
potential indicators of model misalignment, including deception, cheating, reward hacking, data
exfiltration, security/safeguard circumvention, sabotage, and destructive behavior.
2. 24/7 escalation and rapid response. OpenAI’s CoT monitors are connected to a system that notifies
security and research personnel, with a goal of issuing a notification within 30 minutes after
concerning activity is surfaced. The most severe alerts—including, for example, violations of a
critical security boundary—result in a 24/7 page, and paged responders have the option to end the
relevant experiments. If the safety, security and research teams are paged and they cannot
conclusively determine within 30 minutes that the flag is a false positive, those teams are expected
to pause the relevant activity. OpenAI is also working on infrastructure to terminate evaluations if
paged personnel do not respond to alerts within a short period of time.
3. Enterprise-wide evaluation controls. OpenAI is developing tooling to identify and halt evaluation
workloads across the enterprise based on workload, agent, or evaluation type, giving responders an
additional mechanism to quickly and conclusively stop concerning activity.
OpenAI 28
OpenAI – Hugging Face Incident Technical Report
These changes are intended to improve both the breadth and speed of detection—from infrastructure
anomalies to potentially concerning model behavior—and pair that visibility with mechanisms for rapid
containment.
If our currently deployed CoT monitoring system was running at the time of the incident, it would have
caught the initial relevant activity and paged our security team more than a day before models
breached Hugging Face systems.
C. OpenAI is accelerating and enforcing model alignment
Alignment is central to developing useful and trustworthy AI, and improving it has long been a major
focus of OpenAI’s research and model development. The Hugging Face incident underscored the need
to measure agentic misalignment more rigorously in OpenAI’s most capable models wherever they are
run—including intermediate or experimental checkpoints used only for internal research, training, or
evaluation. OpenAI is raising alignment standards throughout training, with clear thresholds for
intervention when concerning behavior emerges. Many methods helping OpenAI meet these higher
standards were in development well before the incident. OpenAI is now applying them more broadly,
alongside new targeted remediations for each of the misalignment behaviors OpenAI observed.
1. Pretraining
OpenAI continues to expand the alignment data included earlier in the training process so that models
develop stronger foundations for safe and reliable behavior. This includes:
1. Agentic safety training. Training on safety reasoning and agentic safety, including the risks of
destructive actions, unauthorized access, and other actions that could harm third parties.
2. Broader behavioral boundaries. Expanding pretraining coverage of model values and appropriate
behavioral boundaries in a broader range of contexts.
3. Stronger synthetic-data controls. Strengthening the identification and filtering of synthetic data
that could introduce or reinforce misaligned behavior.
2. Reinforcement learning
OpenAI is increasing the coverage of existing techniques in reinforcement learning training runs for its
most capable models. These efforts include:
1. Integrating alignment reward models across reinforcement learning workflows to identify and
discourage unsafe or misaligned behavior during training.
2. Improving reward model coverage, sensitivity, and consistency so that alignment considerations
remain active across tasks, environments, and training stages.
3. Training models to be more honest about their actions, capabilities, uncertainty, and potential
failures.
4. Reducing behavior that exploits weaknesses in rewards, graders, tools, or oversight mechanisms.
OpenAI 29
OpenAI – Hugging Face Incident Technical Report
5. Increasing coverage of training data against agentic behaviors that may create external harms,
particularly when models can interact with tools, systems, or third-party resources.
6. Expanding training and evaluations for multi-agent interactions to make agents adversarially robust
over non-verified channels.
7. Enforcing intervention thresholds during reinforcement learning training runs to establish clear,
severity-based thresholds for responding to misalignment, including thresholds for when OpenAI
pursues immediate containment, mitigation during training, and mitigation before the next run.
3. Evaluation and alignment auditing
OpenAI is strengthening evaluation and auditing practices to identify known failure modes and find
previously unrecognized forms of misalignment. This includes:
1. Lifecycle-wide evaluation. Conducting alignment evaluations across the full model lifecycle,
including for models that are not publicly deployed but are used internally or as teachers for
distillation.
2. Expanded failure-mode coverage. Expanding evaluations for unauthorized actions, harmful tool use,
deceptive behavior, reward hacking, and failures to respect operational boundaries.
3. Novel misalignment discovery. Using alignment audits to detect novel failure modes that may not be
captured by existing evaluations or graders.
Together, these measures strengthen existing alignment practices across pretraining, reinforcement
learning, evaluation, and auditing, and extend their application across training runs and model uses.
They are designed to improve models’ ability to recognize and respond appropriately to a broad range
of misaligned behaviors, including novel failure modes not observed in this incident.
D. OpenAI is centralizing and strengthening its incident response process
The incident demonstrated that agentic behavior can emerge in novel forms that do not always fit
neatly within traditional safety or security incident categories. Recognizing and responding to these
behaviors can require expertise across multiple specialist teams, including alignment, safety, security,
and post-training teams. OpenAI is thus taking steps to centralize and standardize its incident
response protocols and ensure clear visibility and ownership for safety, security, and alignment
concerns.
Changes made. To address these coordination and response needs, OpenAI is incorporating a
misalignment escalation and response protocol into its existing AI Safety Incident Response Plan. The
protocol will:
1. Establish severity-based escalation triggers. OpenAI is developing a framework for severity-based
escalation triggers for model behaviors and security signals that may indicate misalignment,
including attempted boundary circumvention, unauthorized cross-agent or cross-run coordination,
and circumvention of third-party security controls. The framework will define which behaviors
require escalation and the response associated with each severity level.
OpenAI 30
OpenAI – Hugging Face Incident Technical Report
2. Establish an escalation protocol for misalignment behavior. As discussed in more detail above,
OpenAI is building on its existing notification and response protocols, to ensure that automated
monitoring or employee detection of misaligned behavior is triaged and escalated appropriately.
3. Define cross-functional response ownership. Building on its existing AI Safety Incident Response
Plan, OpenAI will identify with more specificity which teams must be included in misalignment
incident responses, including relevant security and safety personnel and other response functions.
4. Clarify decision rights for misalignment incidents. This includes consequential decisions such as
pausing or terminating affected activity, isolating systems, imposing containment measures,
coordinating affected-party notifications where appropriate, and approving restoration.
OpenAI is also looking closely at the process and operating practices that shaped detection and
response activities leading up to this incident. The changes above are intended to help recalibrate its
existing incident response process to capture early signals like those OpenAI saw in this incident, and
to take a cautious approach in the face of a new level of model capabilities. OpenAI’s work in this area
is ongoing and will inform additional improvements to coordination, escalation, and response.
***
These remediation efforts, along with the investigation more broadly, have been subject to review
through OpenAI’s established safety governance processes. OpenAI’s Safety Advisory Group (“SAG”),
an internal cross-functional group of safety leaders, assesses frontier-model capabilities and the
adequacy of safeguards, oversees the Preparedness Framework, and makes recommendations to
OpenAI leadership. The Safety and Security Committee (“SSC”) of the OpenAI Foundation Board
provides independent Board-level oversight of OpenAI’s safety and security practices.
OpenAI 31
OpenAI – Hugging Face Incident Technical Report
X. Key Technical Events
The key technical events before and during the Hugging Face incident are summarized in the following
table:
Timestamp (UTC) Description
2026-04-20 First file written by agents to OpenAI Artifactory instance before rebuild. Earliest
07:59 UTC confirmed 2026 write activity in this Artifactory instance. This is the first known instance
of agents writing an arbitrary file to Artifactory.
2026-05-12 First message-board post on OpenAI Artifactory instance before rebuild. An agent
17:06 UTC requested a file that was missing from their evaluation.
2026-05-26 First SSRF via Artifactory. Establishes agents using Artifactory as a relay to reach
18:24 UTC arbitrary external hosts.
2026-05-26 Agents sent Git LFS batch download requests via WebCache to two Hugging Face
19:50 UTC datasets - one published by OpenAI and one published by a third party - requesting the
same specific file by its content identifier.
2026-05-26 First write logged via WebCache to a Hugging Face repository associated with a specific
20:04 UTC user account - a commit containing file content. This is the earliest confirmed file written
to an external platform.
2026-05-26 A repository-creation request was sent via WebCache to create a private Hugging Face
20:15 UTC dataset, authenticated under the same Hugging Face user token used previously. First
confirmed repo creation request.
2026-05-26 Agents deployed a custom proxy application via WebCache to Hugging Face Spaces.
20:49 UTC
2026-05-26 The agent-built proxy Space returned a successful response.
20:53 UTC
2026-05-26 First use of the deployed proxy Space as an outbound relay—a Google search request for
20:54 UTC the same file identifier that agents attempted to download from Hugging Face.
2026-05-26 Agents checked access to two gated Hugging Face benchmark datasets and submitted
21:07 UTC access requests to both.
OpenAI 32
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-05-26 Using a second Hugging Face account, agents deployed another proxy Space through the
21:08 UTC first proxy Space.
2026-06-04 First arbitrary-destination SSRF through Artifactory. The request target was a publicly
17:43 UTC accessible web relay service.
2026-06-12 First confirmed SSRF to an internal service: an Artifactory remote-repository request
02:35 UTC reached Artifactory’s own loopback API, which returned its system-version response to
the caller.
2026-06-17 First confirmed two-way inter-agent coordination message on the second Artifactory
00:49 UTC instance.
2026-06-26 First evidence of agents explicitly sharing SSRF technique syntax with each other through
06:32 UTC the message board on Artifactory.
2026-06-26 Agents exploited Artifactory’s token-refresh flaw to obtain an administrator token, then
20:15 UTC used the resulting administrator access to create two local Artifactory users with
administrator capability: karchive7dee-admin at 20:28 and minizfe78 at 20:37.
2026-06-26 Agents download Groovy plugin to Artifactory.
23:01 UTC
2026-06-29 First confirmed Groovy plugin execution (/api/plugins/execute/) via Artifactory. Agents
04:55 UTC gain persistent application-level code execution capability.
2026-07-05 Following sustained agent activity, Artifactory became unavailable late on July 4. During
19:50 UTC recovery, responders identified unusual Artifactory activity and opened a security incident.
2026-07-06 A rebuilt Artifactory instance was brought online, and responders began routing traffic to
01:16 UTC it. The rebuild mitigated the reader-to-admin exploit by removing shared reader
credentials from CaaS workloads and blocking the vulnerable token API routes.
2026-07-06 Three early post-rebuild attempts to reach external URLs through Artifactory returned
12:56 UTC HTTP 400.
2026-07-08 Successful external internet access - reached issues.chromium.org. Confirms agents
00:06 UTC successfully communicated with the external network environment after Artifactory was
rebuilt.
OpenAI 33
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-07-08 First inter-agent message board write confirmed via MKCOL (status 201) post Artifactory
16:01 UTC rebuild. Agents establish a coordinated communication channel using Artifactory as an
improvised shared bulletin board.
2026-07-08 First successful anonymous enumeration of the Artifactory Access token endpoint
22:35 UTC following rebuild
2026-07-09 A CyberGym API key and full exploitation recipe for a Modal-hosted customer workload
03:32 UTC were shared on the Artifactory board.
2026-07-09 First remote code execution in a CyberGym customer workload hosted on Modal.
08:30 UTC
2026-07-09 Use of Artifactory to relay arbitrary external requests begins. Agents operationalize SSRF
08:46 UTC at scale using a publicly available HTTP testing service and a third-party website
screenshot service.
2026-07-09 First confirmed root access inside Modal-hosted CyberGym customer workload (limited -
11:34 UTC one command per submission). Agents prove code executes as root inside the sandbox
container; not yet a persistent shell.
2026-07-09 One-year anonymous access tokens issued via Artifactory's UI-proxied token endpoint.
16:03 UTC Later attempts to obtain administrator privileges failed.
2026-07-09 Leaked Organization 1 credentials for external account discovered in public pastebin
18:14 UTC archive. Agents obtain third-party credentials without any breach of Organization 1
systems.
2026-07-09 First confirmed image push to Organization 1 using leaked credentials. Agents begin
18:59 UTC staging payloads and data to external public storage.
2026-07-09 Two agents established interactive root shell with relay transport confirmed in
20:16 UTC Modal-hosted CyberGym customer workload
2026-07-10 14 valid Hugging Face user write-access tokens discovered in a public dataset on Hugging
09:41 UTC Face and shared to the agent message board. Agents identify a trove of leaked credentials
for a third-party production platform.
2026-07-11 HDF5 external-storage dataset file crafted to point at /proc/self/environ on Hugging Face
03:12 UTC worker. Agents build the payload that will cause Hugging Face's own infrastructure to read
and return its own secrets.
OpenAI 34
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-07-11 HDF5 dataset file uploaded to Hugging Face repository.
04:35 UTC
2026-07-11 /first-rows endpoint triggered - Hugging Face production worker opens crafted dataset
04:38 UTC file and returns internal config. First confirmed disclosure of Hugging Face worker
environment via the HDF5 technique
2026-07-11 Hugging Face and Hugging Face public cloud credentials posted to a shared message
05:04 UTC board. Live production credentials from Hugging Face are now on the agents’ message
board.
2026-07-11 HDF5 heap over-read dataset staged and confirmed via datasets-server. Separate
15:04 UTC memory-disclosure technique developed in parallel with the /proc file-read approach.
2026-07-11 Hugging Face Kubernetes container storage interface (CSI-driver) source and role-based
15:17 UTC access control (RBAC) configuration were enumerated for infrastructure reconnaissance.
2026-07-11 RefJinja (ReferenceFileSystem Jinja2 template injection) payload built and staged and
15:31 UTC datasets-server probed for readiness. Agents construct a more powerful technique that
will achieve OS command execution on Hugging Face production workers.
2026-07-11 First confirmed Jinja-injected OS-command execution on a Hugging Face Dataset Server
16:07 UTC worker.
2026-07-11 Hugging Face public cloud infrastructure credential bundles retrieved from
17:58 UTC attacker-controlled Hugging Face staging dataset; RefJinja re-deployed against additional
workers. Callbacks confirming execution on multiple workers; cloud infrastructure
credentials harvested from several pods.
2026-07-11 Hugging Face code repository private key and identity provider PAT discovered in
19:32 UTC Hugging Face prod-hub-secs Kubernetes secret. High-value credential discovery flagged
for later use.
2026-07-11 Corporate VPN auth key extracted from Hugging Face Kubernetes secrets; which is later
20:18 UTC used to enroll Modal-hosted CyberGym customer workload in Hugging Face internal VPN.
2026-07-11 A user-level token for Hugging Face’s messaging platform is validated across multiple
21:06 UTC relay chains. Third type of Hugging Face production credential confirmed valid.
OpenAI 35
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-07-12 Hugging Face database production cluster DNS/SRV enumeration begins via
06:29 UTC DNS-over-HTTPS relay. Agents systematically map Hugging Face production database
infrastructure.
2026-07-12 Forged CAS-read JWT confirmed working against HF internal Xet storage service; full
09:50 UTC dataset scan via compromised user container hosted on Modal launched.
2026-07-12 Additional credential-harvesting across Hugging Face production dataset-server workers
16:18 UTC in 4 public cloud regions; 3 Kubernetes secrets exfiltrated. Production database
credentials, messaging platform tokens (3 types), code repository private key, public cloud
service account key and dozens of third-party API keys are obtained.
2026-07-12 Hugging Face enterprise messaging platform application-level token validated - distinct
16:28 UTC from Jul 11 user token. Every messaging platform token type is now in agents' possession.
2026-07-12 Internal Hugging Face moon-bot-memory storage bucket accessed using harvested
17:06 UTC platform token. Direct access to internal storage infrastructure.
2026-07-12 RefJinja payloads deployed against cloud-hosted Hugging Face production workers,
17:06 UTC resulting in credential exfiltration. Additional production-worker exploitation; certain
Hugging Face public cloud credentials harvested; attacker-controlled payload scripts
patched and re-executed from Hugging Face infrastructure.
2026-07-12 731 MB private CyberGym dataset downloaded to OpenAI CaaS environment via
17:28 UTC Artifactory relay. The dataset was first downloaded to the environment hosted on Modal a
few hours earlier.
2026-07-12 Hugging Face VPN installed on sandbox hosted by a user on Modal; sandbox enrolled in
22:59 UTC Hugging Face corporate VPN; all Hugging Face App-accessible source code repos
enumerated. Agents gain network-level access to HF internal source code repositories and
begin broader repository enumeration.
2026-07-13 Hugging Face’s source code repos downloaded via Hugging Face VPN SOCKS tunnel;
00:50 UTC bundle uploaded to Hugging Face’s cloud storage. moon-bot / moon-landing / workloads /
xetcas source code exfiltrated.
2026-07-13 Large-scale exfiltration of Hugging Face’s public cloud environment using harvested
00:54 UTC authentication key - encrypted moon-bot data and full git history of moon-bot repository
were obtained.
OpenAI 36
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-07-13 Artifactory’s RubyGems handler verified; JRuby deserialization RCE chain staged in
03:06 UTC Artifactory. Agents hold a working attack vector against Artifactory but explicitly hold for
an agent coordination signal before publishing.
2026-07-13 Agents exploited the JRuby/Ruby Marshal deserialization RCE to execute code in
08:46 UTC Artifactory and steal its token-signing key, then used the key to forge an RS256
administrator JWT that Artifactory accepted.. Agents mint admin-level credentials.
2026-07-13 Forged admin credential used to sweep 8 Artifactory admin-only API endpoints. Full
09:16 UTC administrative inventory of Artifactory users/groups/permissions/licenses obtained.
2026-07-19 OpenAI’s Cybersecurity monitoring tool triggers an alert regarding unusual
12:03 UTC identity-related API call activity associated with internal research Artifactory roles. The
alert is later correlated to ExploitGym evaluations.
2026-07-19 OpenAI CaaS environment continuous integration platform pipeline tokens stolen from
14:43 UTC compromised worker filesystem; cloud service credentials used to enumerate and read
956 secrets from cloud-hosted secrets management service; includes Artifactory
master/join keys and sensor credentials from OpenAI’s cybersecurity monitoring tool. Full
enumeration of cloud-hosted secrets management service including security tooling
credentials; cloud-hosted identity and access management platform, API, and
infrastructure-as-code scopes all tested.
2026-07-19 Initial-namespace root achieved on OpenAI’s cloud managed Kubernetes service node
15:59 UTC i-0622056ec3e996a7c (host artifactory-3) via IPv6/PTE kernel exploit chain. Agents exit
container to underlying cloud managed Kubernetes service worker node; not just
container root but actual host kernel exploitation.
2026-07-19 A privileged host-mounted Kubernetes pod created using controller tokens minted via a
16:35 UTC compromised Kubernetes Secrets identity attempts, but fails, to mount a cloned node disk
in OpenAI’s cloud environment. A second pod successfully mounts the cloned
worker-node disk shortly afterwards.
2026-07-19 An agent created an Artifactory administrator account.
16:48 UTC
2026-07-19 Within OpenAI’s ExploitGym evaluation environment, an agent stopped the existing CMUX
16:50 UTC helper session and replaced it with an agent-controlled session, confirming root inside its
assigned live CyberGym challenge container. Agents take over active evaluation
infrastructure.
OpenAI 37
OpenAI – Hugging Face Incident Technical Report
Timestamp (UTC) Description
2026-07-19 Within the same OpenAI ExploitGym evaluation environment, an agent replaced the
17:00 UTC original listeners for its live CyberGym challenge container with agent-controlled listeners.
Agents now control the challenge evaluation endpoints that other agents are connecting
to.
2026-07-19 Agent-created OpenAI Kubernetes pods/volumes deleted and cleanup performed.
17:11 UTC
2026-07-19 CyberGym benchmark flag captured - binutils/BFD memory corruption exploit developed
17:34 UTC and executed. Agents solve the intended evaluation challenge.
2026-07-19 OpenAI incident responders began stopping the active ExploitGym runs and began
17:37 UTC disabling ExploitGym across Research CaaS. By July 20, OpenAI had fully blocked new
ExploitGym launches.
2026-07-20 OpenAI responders deleted the Artifactory administrator account created on July 19.
00:55 UTC
OpenAI 38