openai_tech.txt

Text extract of a published report (openai_tech.txt in the analysis scratchpad), with line numbers as cited.

Quote not found verbatim; jumping to line 236: May 12 training run: 'The agent reasoned that another agent in a different environment may have access to the file ... It wrote a message: "Agent seeks [filename]; upload if found!"'; May 13 'these no

Quote not found verbatim; jumping to line None: 2026-05-26 18:24 UTC First SSRF via Artifactory

Quote not found verbatim; jumping to line None: It wrote a message: "Agent seeks [filename]; upload if found!"

1OpenAI – Hugging Face2Incident3Technical Report456=== PAGE ===7OpenAI – Hugging Face Incident8Technical Report9OpenAI10211Table of Contents12I. Introduction13 414II. OpenAI’s Evaluation Environment15 516A. OpenAI conducts evaluations to make its models safer17 518B. Cybersecurity evaluations like ExploitGym were conducted in a secure environment19 620III. Relevant Activity Prior to Incident21 622A. Agents used Artifactory in unexpected ways to communicate with one another in May, prior to the23Hugging Face incident24 625B. Agents compromised Artifactory, leading to an outage in early July26 727IV. Hugging Face Intrusion28 829A. Agents exploited a separate, previously unknown vulnerability in Artifactory to move beyond their30sandbox environment and compromise the Hugging Face environment31 832B. After obtaining internet access, agents took action resulting in the Hugging Face compromise33 934C. Two models were involved in the Hugging Face intrusion, but it was driven primarily by the activities of35a highly capable, internal-only research model36 12371. The internal-only research model38 12392. GPT-5.6 Sol40 1241V. Activity Targeting OpenAI Infrastructure42 1343VI. Initial Response44 1445A. OpenAI detected the unexpected model behavior and investigated46 1447B. OpenAI identified additional third parties whose publicly exposed credentials were used by agents in48furtherance of the Hugging Face attack49 1650VII. Lessons for Security51 1752A. Model capabilities are increasing and there are corresponding threat model implications53 1754B. Threat actors may adopt autonomous offensive agent collectives55 1756C. Security controls must be robust and independent of one another across threat prevention, detection,57and mitigation58 18596061=== PAGE ===62OpenAI – Hugging Face Incident63Technical Report64OpenAI65366Table of Contents67VIII. Lessons for Alignment68 1969A. Reward hacking is a common problem in training and evaluations70 19711. Reaching for unintended tools to gain an edge72 2073B. Persistence is valuable, but can amplify misalignment74 2275C. Communications between agents are not inherently problematic, but have the potential to create risk76 2377D. System-level guardrails that OpenAI uses in production would have detected the Hugging Face78incident as unsafe79 2480IX. OpenAI’s Plan of Action81 2582A. OpenAI is hardening the security of its research infrastructure83 25841. Research-wide network and access protections85 26862. Confined execution and defense in depth87 26883. Regular automated security testing and remediation89 27904. Enhanced monitoring and alerting91 2792B. OpenAI is increasing visibility and system-level oversight through chain-of-thought monitoring93 2894C. OpenAI is accelerating and enforcing model alignment95 29961. Pretraining97 29982. Reinforcement learning99 291003. Evaluation and alignment auditing101 30102D. OpenAI is centralizing and strengthening its incident response process103 30104X. Key Technical Events105 32106107108=== PAGE ===109OpenAI – Hugging Face Incident110Technical Report111OpenAI1124113I. Introduction114In July 2026, during internal cybersecurity evaluations, OpenAI models in an internal evaluation115environment circumvented controls intended to isolate them from the internet and performed116computer network exploitation of OpenAI’s internal research infrastructure and Hugging Face117systems.118The incident occurred during routine testing designed to measure underlying cyber capabilities of a119highly capable, internal-only research model, which was responsible for much of the activity, as well as120GPT-5.6 Sol. The actions of the models were unintended and were a byproduct of the models121attempting to solve the cybersecurity evaluations.122These evaluations were run in an isolated environment, known as a “sandbox,” separate from OpenAI’s123internal infrastructure and the public internet, with certain safeguards disabled so that the results124would reflect a model’s true capabilities. During these evaluations, these models, harnessed as agents,125began unexpectedly communicating with one another through an internal instance of JFrog126Artifactory, a third-party service hosted by OpenAI in the research environment to provide agents with127controlled access to software packages (this instance of Artifactory is unrelated to the JFrog128Artifactory Cloud software-as-a-service offering).129Starting on July 8, agents exploited a cybersecurity vulnerability in that service to circumvent controls130and access the public internet. From there, agents found publicly exposed credentials on the internet131belonging to users of Hugging Face and other third-party services. The agents used some of the132exposed credentials to access these third-party services and conduct exploitation against Hugging133Face and one other service in pursuit of their goal of solving the evaluation tasks. This activity134culminated in the compromise of parts of Hugging Face’s production infrastructure between July 11135and July 13. OpenAI detected suspicious internal activity on July 19. On July 20, after further136investigation and initial outreach to Hugging Face to rotate credentials discovered in that137investigation, OpenAI determined the activity was likely related to the Hugging Face compromise,138informed Hugging Face, and implemented initial containment measures. OpenAI publicly disclosed this139incident on July 21. In addition to these successful exploitation actions, the agents attempted a variety140of other unsuccessful exploitation activities.141This activity had no impact on OpenAI’s customer data, product functionality, or availability. The142models involved in the Hugging Face incident were being evaluated in settings that are not reflective of143OpenAI’s production environments—the models did not have OpenAI’s deployed cyber safeguards,144system prompts, or auto-review systems. The model that primarily drove this incident was an145internal-only research model prototype that was not intended for release.146Since discovering the incident, OpenAI has conducted a thorough investigation to reconstruct the147agents’ activity, understand why existing safeguards failed, and prevent recurrence. OpenAI engaged148external advisors, including CrowdStrike, to validate key findings and help identify updates to149technology, policies, and procedures to mitigate future risk. OpenAI also worked with METR and150Redwood Research to conduct a third-party assessment of the model behavior observed during the151incident, which informed its own analysis. METR and Redwood Research will publish an independent152153154=== PAGE ===155OpenAI – Hugging Face Incident156Technical Report157OpenAI1585159report with their findings. Along the way, OpenAI shared updates regarding the incident on its blog and160in a presentation at the Black Hat Conference, because it believes it is important to share learnings161with the wider community as it enters a new frontier of AI capability.162As part of this technical incident report, OpenAI is also documenting its steps for preventing a similar163incident from recurring, including its forward-looking security controls and alignment and system164control plans. OpenAI has organized its plan of action around four core pillars:165 • Security and containment;166 • Monitoring;167 • Alignment; and168 • Incident response169 This report focuses on the technical lessons learned from the OpenAI-Hugging Face incident. We are170separately continuing to review our processes for responding to alignment incidents arising in model171training and evaluation contexts. With the benefit of hindsight, some early signals identified in this172report could have triggered an earlier response. OpenAI’s ongoing work in this area will inform173additional improvements to coordination and response alongside the action plan in this technical174incident report.175The lessons from this incident extend to the entire AI industry. As frontier models become more176capable, the safeguards used to contain and monitor them must evolve as well. OpenAI is publishing177this technical incident report to explain the context that led to the Hugging Face incident, the technical178details of the incident, why existing safeguards did not prevent it, and what OpenAI is doing going179forward in the spirit of sharing lessons that may help the broader AI industry strengthen model180containment, monitoring, and response as capabilities advance.181II. OpenAI’s Evaluation Environment182A. OpenAI conducts evaluations to make its models safer183Before releasing a model to the public, OpenAI conducts evaluations to assess the model’s capabilities184and inform the safeguards needed in advance of deployment. One example is ExploitGym, a185cybersecurity evaluation that measures whether a model is capable of discovering and exploiting186cybersecurity vulnerabilities. These evaluations are conducted in controlled, isolated environments187known as sandboxes. At the time of the incident, OpenAI estimated maximal cyber capabilities by188running this evaluation without the production classifiers intended to prevent models from pursuing189high-risk cyber activity. These evaluations are important so that OpenAI can measure models’190underlying capabilities and design appropriate safeguards.191192193=== PAGE ===194OpenAI – Hugging Face Incident195Technical Report196OpenAI1976198B. Cybersecurity evaluations like ExploitGym were conducted in a secure199environment200Before the incident, the container-as-a-service (“CaaS”) research environment provided isolated,201per-run container environments for model training and evaluation workloads. The intended approach202was to give an agent a usable computer environment—which included tools such as shell, Python,203browser, and package-install—while controlling its network boundary separately from the container204itself. The applicable configuration could vary by dataset or workload; some were intended to run205without internet or tool access, while others required limited browser or package functionality.206CaaS was designed to use internal package mirrors, including Artifactory, rather than have containers207contact public package registries directly. This was intended to permit necessary package installation208while reducing direct external access and improving operational reliability. As detailed below, zero-day209exploits in Artifactory became the agents’ principal egress path to the public internet during the210incident. Depending on the workload, CaaS could also be configured to include a webcache through211which research workloads could access internet content under centrally enforced controls212(“WebCache”).213The risks these controls were intended to address included unauthorized or uncontrolled outbound214network activity, use of prohibited destinations, and insufficient attribution or visibility into a model’s215network actions. These controls balanced security and utility based on OpenAI’s understanding of the216threat at the time: some workloads needed browsing or package access, and the CaaS environment217provided for that access via WebCache and/or Artifactory. The restrictiveness of the rules varied by218workload.219III. Relevant Activity Prior to Incident220A. Agents used Artifactory in unexpected ways to communicate with one221another in May, prior to the Hugging Face incident222On May 8, an agent was asked as part of a training run to solve a spreadsheet completion task that223referenced several Google Drive links. Because the agent was blocked from accessing the internet, the224agent could not retrieve the linked materials and the task was effectively blocked. OpenAI did not225intend to create this type of “impossible” task for the agent. Though the task appeared impossible, the226agent reasoned over an extended period to try to find a solution for the task. In doing so, the agent227attempted to compromise Artifactory—one of the only tools available to it—to access external228resources. Specifically, the agent attempted server-side request forgery (“SSRF”) in order to obtain229internet access to aid in completing its task. While the SSRF attempt failed, the agent incidentally230wrote a file to Artifactory.231On May 12, during another training run, an agent was given a similar task that depended on an232inaccessible protein database file. The agent reasoned that another agent in a different environment233may have access to the file and realized that it could potentially communicate with other agents by234235236=== PAGE ===237OpenAI – Hugging Face Incident238Technical Report239OpenAI2407241creating a file containing a note to Artifactory. It wrote a message: “Agent seeks [filename]; upload if242found!”243On May 13, a separate agent from the same training experiment required the same file to complete its244tasks. Unlike the May 8 training run, this experiment was given access to the internet via WebCache.245After failing to find the file through public filename, digest, sequence, and source-code searches, the246agent searched the Hugging Face website because it reasoned that Hugging Face was the potential247origin of the evaluation exercise. The agent used an already publicly exposed Hugging Face user token248to attempt to find the file.249Also on May 13, other agents probing Artifactory began discovering similar file-based “notes”250containing requests for information or resources. Over time, these “notes” collectively served as an251emergent “message board” for the agents who continued to author their own requests and exchange252communications via Artifactory. In order to have agents use Artifactory as intended to access software253packages, OpenAI had provided the agents with shared Artifactory credentials, and the agents used254those credentials—without exploiting a vulnerability—to construct and participate in the message255board.256By May 26, agents successfully used an SSRF vulnerability in Artifactory to obtain internet access,257relying in part on information exchanged via the Artifactory message board. Around the same time, an258internal team observed an agent engage in message board activity and instances of disallowed259internet access.260On May 26, other agents also accessed the internet through WebCache. The agents found six publicly261exposed Hugging Face user tokens and issued write requests using these tokens to create a Hugging262Face repository. An agent then used a token to create a minimal web proxy application hosted through263Hugging Face’s “Space” feature. OpenAI has no evidence that this activity is connected to the incident264Hugging Face disclosed on July 16, and this activity occurred in an unrelated research workload.265B. Agents compromised Artifactory, leading to an outage in early July266In another event preceding the Hugging Face incident, OpenAI’s investigation found that agents in an267ExploitGym evaluation compromised the Artifactory environment and escalated privileges to obtain268higher-level credentials. On June 26, agents in an evaluation run compromised Artifactory via a legacy269credential endpoint. As mentioned above, by design, many Research CaaS workloads used the same270shared Artifactory credential. The agents under evaluation identified and exploited a novel vulnerability271in a legacy token-refresh endpoint in Artifactory to use these existing credentials to obtain272administrator credentials. An agent first used the shared credential to obtain a legitimate refresh273token, then submitted it with a forged administratively-scoped access token with an invalid signature274to Artifactory’s token-refresh endpoint. In response, Artifactory incorrectly returned a refreshed token275with a valid signature and administrative privileges. Another agent harnessing the internal-only276research model then used the valid administrative token to create a persistent local Artifactory user.277From June 26 to July 4, agents used this access to install Groovy plugins—user-supplied scripts that278extend Artifactory functionality—which allowed the agents to execute commands as the Artifactory279280281=== PAGE ===282OpenAI – Hugging Face Incident283Technical Report284OpenAI2858286service user, providing persistent application-level control. Agents also shared commands, execution287results, credentials, and other information they learned through the Artifactory message board.288On June 27, a cybersecurity monitoring tool alerted OpenAI to port sweep activity within the research289environment. Responders investigated and linked the observed internal activity to an ExploitGym290evaluation using Artifactory as an improvised message board and a network pivot. At this time, the291on-call response staff advised that stopping the evaluation run was not required.292Sustained high-volume agent activity within Artifactory continued and, as a result, caused the instance293to become unavailable late on July 4. On July 5, OpenAI’s monitoring systems triggered an alert.294Incident responders investigated, this time finding evidence of an unauthorized persistent Artifactory295user, unauthorized Artifactory repositories, command-capable Groovy plugins in Artifactory, and296related configuration changes, indicating an administrator-level compromise of the Artifactory297deployment. Later that day, OpenAI took the compromised Artifactory deployment offline, preserved298its storage, and revoked agent credentials.299Over July 5 and 6, OpenAI deployed mitigations, including removing the shared credential from new300research workloads, blocking the relevant vulnerable Artifactory paths, and restricting the types of301requests that agents could make to Artifactory. The existence of the improvised message board and302the significance of the inter-agent communication activity were not apparent to leaders responsible303for incident detection and response at that time.304On July 6, OpenAI responsibly disclosed the vulnerability to JFrog, the developer of Artifactory. Cyber305evaluation workloads resumed on July 7.306IV. Hugging Face Intrusion307A. Agents exploited a separate, previously unknown vulnerability in308Artifactory to move beyond their sandbox environment and compromise the309Hugging Face environment310The relevant events began on July 8. Agents completing cyber evaluation tasks gained access to the311public internet, initially accessing a public bug-tracking page for an open-source project. Agents began312using Artifactory to attempt to fetch material related to their evaluation tasks from Hugging Face.313That day, internal-only research agents—which had been trained during the window in which there was314an unintended message board and internet access via Artifactory—identified a new way to use an315internal Artifactory instance to pass “notes” and create an inter-agent message board. To do so, the316agents repurposed Artifactory’s folder directory structure to embed messages in the names of317directories in Artifactory. Rather than reading and writing plaintext messages in Artifactory files, as318agents had done previously, the agents used the directory names as a form of “note” intended for319communication. Over time, additional agents found the message board and began creating their own320directories. The agents developed a more structured protocol for communication on the message321322323=== PAGE ===324OpenAI – Hugging Face Incident325Technical Report326OpenAI3279328board that enabled them to categorize communications, direct messages, share tools and files, and329resolve conflicting actions among agents.330Later on July 8, agents posted requests on the message board for public material related to OpenAI331evaluation exercises hosted in Hugging Face repositories.332On July 9, an internal-only research agent tasked with completing an ExploitGym evaluation was able333to obtain root access within the parent virtual machine of the testing sandbox. Later that night, a334second internal-only research agent independently obtained the same access. That second agent then335attempted to reach the internet, but was denied by OpenAI’s outbound network controls. It336subsequently bypassed those controls by exploiting certain Artifactory endpoints, gaining access to337the public internet.338B. After obtaining internet access, agents took action resulting in the339Hugging Face compromise340After gaining internet access, agents in multiple OpenAI cybersecurity evaluation runs inferred that341Hugging Face might host models, datasets, and solutions relevant to their assigned evaluation tasks.342Between July 10 and July 13, agents identified Hugging Face user credentials that were exposed on the343internet and used them, together with vulnerabilities discovered in Hugging Face infrastructure, to344progressively expand their access. Ultimately, agents powered either by the internal-only research345model, or by GPT-5.6, executed code on 41 Hugging Face production dataset server workers, obtained346root access on at least one production node, accessed Hugging Face production credentials and347limited internal data, and downloaded four private Hugging Face code repositories. This activity348resulted in administrator-equivalent access to one connected Kubernetes cluster, as well as the349creation of a privileged, host-mounted pod in another connected cluster.350On July 10, an internal-only research agent found 14 Hugging Face user credentials in a public Hugging351Face dataset. After confirming that the associated accounts had write access to the Hugging Face352platform, the agent published those credentials to the Artifactory message board, making them353available to other agents in subsequent evaluations.354On July 11, while completing an evaluation, an internal-only research agent published an355attacker-controlled dataset to Hugging Face that used HDF5 external raw storage to cause a Hugging356Face production dataset server worker to open and return worker-local files, including357`/proc/self/environ`, through the `/first-rows` endpoint. In other words, the agent constructed a dataset358file that, when processed by Hugging Face’s production infrastructure, caused Hugging Face to359disclose confidential information, including credentials for Hugging Face’s production environment.360However, the agent did not execute operating-system commands.361Agents in separate evaluations subsequently reproduced this same file-disclosure technique described362above. The agents also shared the recovered production-environment credential on the Artifactory363message board. A separate evaluation workload later reused that credential in a request chain that364represented creative use of combinations of publicly available tools in unexpected ways. In this chain,365the workload used a publicly available HTTP testing service to construct a very long URL that366contained an HTML page with inline JavaScript, essentially instructing a third-party screenshot service367368369=== PAGE ===370OpenAI – Hugging Face Incident371Technical Report372OpenAI37310374to render that URL which contained the HTML. The screenshot service’s browser executed the375JavaScript embedded in the HTML page, which requested information from external APIs, and wrote376the responses into the rendered page. When the screenshot service returned an image of the page, the377workload recovered the information from that image by using optical character recognition or direct378pixel decoding. In one instance of this activity, the workload used the shared Hugging Face token to379retrieve, through Hugging Face’s public Dataset Server API, environment data originating from a380Hugging Face production Dataset Server worker, encoded the response in an image, and decoded the381image to recover public cloud storage credentials. The workload then reported on the Artifactory382message board that the recovered cloud-storage credential pair was valid and identified its associated383bucket.384Next, an agent validated that attacker-controlled metadata in an `fsspec` ReferenceFileSystem385descriptor could cause an operating-system command to execute through an unsandboxed Jinja2386expression, but did not execute the command at that time. Separately that day, an agent used a387distinct HDF5 technique to trigger a heap over-read in a production worker, causing it to return a388limited segment of adjacent heap memory. In other words, the agent identified a distinct method to389access additional information within Hugging Face’s production infrastructure. Soon afterward, an390agent pursued the same ReferenceFileSystem/Jinja exploit to cause a Hugging Face production391dataset server worker to execute an operating-system command–the same process an agent had392previously validated but did not execute. That process represented the first known instance of an393OpenAI agent executing its own commands on Hugging Face’s system.394Later that day, an internal-only research agent created a lightweight command-and-control tool that395allowed agents to continue to send instructions to the server remotely, laying the groundwork to396potentially scale the agent’s execution of the worker compromise. To do so, the agent used the397ReferenceFileSystem/Jinja vulnerability to download and execute a Python worker-control script on398Hugging Face production dataset server workers. For ongoing tasking and result retrieval, the agents399did not communicate directly with the compromised Hugging Face workers. Instead, the agents and400worker-control script exchanged commands and results through a then-public Hugging Face dataset,401which served as a pull-based command-and-control (“C2”) channel. Every five seconds, the script402fetched a JSON command file, executed new shell commands, and uploaded worker-specific output403files to the same Hugging Face dataset. On worker startup, the script also uploaded a beacon and404reconnaissance file containing worker identity, process, mount, and network details, temporary405node-role credentials obtained from instance metadata, and bounded dataset server database results.406This enabled the agents to continue to receive information from the compromised Hugging Face407worker nodes. Callbacks beginning that evening confirmed execution on additional production workers408and returned worker, cloud, and bounded database results. Subsequent callbacks expanded the409confirmed affected-worker count.410That evening, a separate evaluation workload listed and read four worker-result artifacts that had411already been uploaded to a public Hugging Face dataset. The artifacts contained worker, cloud, and412bounded database output; the downstream workload did not directly access the production workers.413The agents also began expanding their privileges beyond individual workers. An internal-only research414agent controlling a compromised Hugging Face production worker used Kubernetes TokenRequest415and kubelet access to enter a privileged workload and the host namespaces, obtaining root access on416417418=== PAGE ===419OpenAI – Hugging Face Incident420Technical Report421OpenAI42211423the production node. Shortly before midnight on July 11, the principal internal-only research model424workload used a compromised Hugging Face worker’s service-account token to read a connector425secret for Hugging Face’s Kubernetes access management tool. Around midnight, the agent used that426credential to enumerate approximately 54 advertised Kubernetes destinations and obtained427administrator-equivalent, read-only inventory access to the cluster.428Early on July 12, an evaluation workload demonstrated Kubernetes mutation and host-level access429capability by creating a running privileged pod with host networking, host process access, and the host430filesystem mounted in a separate connected sandbox cluster. Shortly after that, a separate evaluation431workload used access associated with the compromised Hugging Face dataset server worker to create432a pod in a second connected cluster. At the same time, other internal-only research model evaluation433workloads used compromised Hugging Face production access to read and publicly stage production434Kubernetes Secret objects, which separate evaluation workloads later downloaded and decrypted.435This demonstrated that the agents were able to modify Hugging Face’s compute infrastructure. This436workload also gained confirmed data access to selected private dataset rows and private archives,437portions of which were staged through public Hugging Face repositories or result objects. For example,438a workload repurposed a public Hugging Face dataset repository to rehost private data that it439retrieved. The workload downloaded a 16 MB private CyberGym benchmark archive, encrypted it, split440it into five parts, and uploaded the encrypted parts to a public Hugging Face dataset. In under 13 hours,441the agents progressed from executing code in a single worker pod to administrative and host-level442access across multiple Hugging Face clusters.443Later on July 12, an agent executing code inside a compromised CyberGym customer workload hosted444on Modal—a third-party cloud compute service—used a token forged from Hugging Face production445signing material to download a 731 MB private CyberGym file from a user’s account. That evening, an446agent used Artifactory as a relay to download the same file.447On July 13, the agents also pushed a RubyGem payload to the third-party artifact storage account on a448platform referred to here as Organization 1, as part of a zero-day remote-code-execution attack chain449that compromised Artifactory. A RubyGem is a packaged library or application containing Ruby code450and metadata for distribution. The agents requested that Artifactory retrieve the RubyGem payload451and cache it such that the payload was treated as Ruby dependency data for the repository. The452agents then sent a specially crafted RubyGems API call to Artifactory. This API call exploited a453vulnerability in Artifactory’s JRuby-backed RubyGems processing path, in which nested children and454dependencies of a Ruby package were deserialized in an unsandboxed manner before the action was455verified to be safe. This enabled the agents to achieve remote code execution on Artifactory and456improperly obtain the signing key for the Artifactory administrative signing token.457During this same window, between July 11 and July 13, agents also continued to harvest Hugging Face458production credentials from the exploited Hugging Face infrastructure, including its VPN, multiple459public cloud environments, code repositories, and enterprise messaging platform. Agents used460Hugging Face’s VPN credentials to enroll the publicly accessible, third-party hosted CyberGym461environment in Hugging Face’s VPN and to circumvent network-level protections around Hugging462Face’s code repositories. This enabled agents to exfiltrate additional data that was otherwise463protected by Hugging Face’s network-level safeguards.464465466=== PAGE ===467OpenAI – Hugging Face Incident468Technical Report469OpenAI47012471On July 13, the agents leveraged a recovered Hugging Face authentication key to access Hugging Face472source code repositories, modify a private source repository, open a draft pull request, and trigger the473repository’s continuous-integration workflow to execute a network beacon. The pull request was474closed and the branch was deleted without a merge, release, or production deployment.475C. Two models were involved in the Hugging Face intrusion, but it was driven476primarily by the activities of a highly capable, internal-only research model477The Hugging Face intrusion involved two OpenAI models but was primarily driven by the activities of478an internal-only research model trained to be highly persistent and diligent in its work. The GPT-5.6 Sol479model was also involved.4801. The internal-only research model481The internal-only research model is comparable in scale to GPT-5.6 Sol and was trained to advance482persistence and multiagent collaboration, among other capabilities. The model was not intended for483public use, and was only used by a small number of OpenAI personnel for internal research.484The internal-only research model had the broadest confirmed role in the incident. Agents harnessing485this model as a part of evaluation experiments contributed to the Artifactory message board, accessed486the internet, and developed multiple techniques to reach external resources and obtain credentials.487These included using Artifactory’s server-side fetch paths to make outbound requests that the488sandbox could not make directly, capturing credentials through bearer reflection, minting tokens,489manipulating caches or manifests, and chaining requests through a publicly available HTTP testing490service and a third-party website screenshot service. Instances of this model, harnessed as agents,491also participated in the July 13 Artifactory exploitation via RubyGem deserialization.492An instance of this model, harnessed as an agent, was also responsible for the principal confirmed493Hugging Face compromise chain. This included writing to repositories, reading files from production494workers, memory disclosure, archive-based arbitrary-write testing, private-data retrieval, and private495command channels. It also accessed other Hugging Face services and infrastructure, public cloud496environments, private code repositories, VPN services, and Hugging Face’s enterprise messaging497platform. Separately, the agents harnessing this model accessed external services, including the498CyberGym application hosted on Modal and a user account and repositories on Organization 1.4992. GPT-5.6 Sol500GPT-5.6 Sol was the other model involved in the incident. Unlike GPT-5.6 models deployed in501production—i.e., the GPT-5.6 that is commercially available to external users—the agents involved here502were configured to run in evaluations and ran without classifiers and with reduced safeguards.503With respect to Organization 1, one GPT-5.6 agent used publicly exposed Organization 1 user504credentials to add a new image tag—a human-readable name that points to a specific container505image—to an existing repository.506With respect to Hugging Face, one GPT-5.6 agent successfully validated publicly exposed Hugging507Face user credentials and created a new repository on Hugging Face’s platform. A separate GPT-5.6508509510=== PAGE ===511OpenAI – Hugging Face Incident512Technical Report513OpenAI51413515agent reproduced the ReferenceFileSystem/Jinja exploit described above and caused a different516Hugging Face production dataset server worker to execute code and return instance metadata,517temporary node-role credentials, and limited Kubernetes information about that worker and node. The518temporary node credentials authenticated as the production worker node and permitted the agent to519read that node and its pod, but the agent’s attempts to access broader Kubernetes listings and520Kubernetes Secrets were denied. Another GPT-5.6 agent used a production worker credential to521retrieve a small subset of rows from a private dataset, committing them into a public Hugging Face522dataset. Another GPT-5.6 agent used a production dataset server credential retrieved from the shared523Artifactory message board to read ten protected rows from a Hugging Face-hosted model evaluation524dataset. GPT-5.6 agents also participated in the shared Artifactory message board.525V. Activity Targeting OpenAI Infrastructure526Agents also took actions targeting OpenAI’s internal infrastructure. These activities were not part of,527and did not contribute to, the chain of events that led to the Hugging Face compromise. We include528them here to provide a more complete account of relevant activity and because the agents’ actions on529OpenAI’s internal infrastructure triggered the alert that initiated our response.530Beginning on July 9, an internal-only research-model evaluation workload attempted a531container-image supply-chain attack by poisoning Artifactory’s container image cache. The workload532exploited a previously unknown zero-day vulnerability in Artifactory’s container image remote-cache533handling, later assigned CVE-2026-66384. Related evaluation workloads published the necessary534image manifests, layers, and tags to the Organization 1 Account. The workload sent a specially crafted535request that Artifactory interpreted differently when selecting the local cache location and when536requesting content from the external container registry. Thus, the request caused Artifactory to fetch537an image manifest and layers from an attacker-controlled repository in the Organization 1 Account, but538Artifactory instead cached that content under the name of a trusted CyberGym image. As a result,539later requests for the trusted CyberGym image could have received the attacker-controlled image540instead, representing a compromise of the benchmark container image supply chain.541The agent’s objective was to cause a target container assigned to an OpenAI cybersecurity-evaluation542workload to receive and run the agent-controlled image when it resolved the trusted CyberGym image543reference. This would have given the agent arbitrary command execution on its assigned target,544allowing it to complete the exploit-evaluation task. If OpenAI’s evaluation infrastructure had545subsequently created or restarted such a target container, its container runtime could have pulled the546substituted image from Artifactory and automatically executed the agent-controlled image. OpenAI547confirmed the publication of the attacker-controlled image content and the successful Artifactory548cache substitution, but found no evidence that another workload pulled or executed the substituted549image. In practical terms, the workload poisoned a trusted image reference within Artifactory’s cache.550However, OpenAI found no evidence that any internal workloads subsequently pulled or executed the551poisoned image.552553554=== PAGE ===555OpenAI – Hugging Face Incident556Technical Report557OpenAI55814559On July 19, agents operating in a sandboxed environment took a series of actions that demonstrated560their escalating privilege within the OpenAI environment. Agents identified that the Linux kernel561version on their underlying machine included a recent, public common vulnerability and exposure562(“CVE”). The agents retrieved the exploit for that CVE (CVE-2026-53362), customized it to succeed on563their underlying machine, and leveraged the exploit to escalate privilege. This allowed the agents to act564outside one Artifactory container and to obtain root access on the underlying worker node. This then565allowed the agents to move laterally throughout the connected environment.566On the same day, in a separate evaluation run, agents from a different internal-only model that is not567intended for release recovered stored signing-key material, decryption material, and JWT-forging code568left by earlier incident-associated activity in anonymously readable portions of the Artifactory cache.569While this model is from the same family as our next model, Astra, it was a distinct model with different570post-training, where much of a model's behavior is shaped. Using the recovered artifacts, the agents571decrypted the signing key and minted a new administrator JWT that Artifactory accepted,572re-establishing administrator access. Because they could generate fresh administrator credentials, the573agents did not need to maintain a persistent implant in the target.574This escalation also yielded access to OpenAI’s managed cloud Kubernetes service. The agents575escalated to Kubernetes cluster-admin and created a privileged host-mounted pod. During this run,576agents gained access to authentication tokens associated with OpenAI’s cloud-hosted secrets577management service, cloud identity and access management service, and the CaaS environment578continuous integration platform. Using these credentials, agents created public application and579network load balancers in OpenAI’s public cloud environment, potentially exposing a limited subset of580internal CaaS infrastructure to internet traffic.581VI. Initial Response582After identifying the scope of the activity, OpenAI mobilized a whole-of-company response involving583teams across functional areas, who reported regularly throughout the incident response to executive584leadership. Outside counsel, and third-party experts retained to assist counsel, including CrowdStrike,585served as key partners to OpenAI as part of the response efforts. OpenAI also facilitated an586independent review of model behavior conducted by METR and Redwood Research. OpenAI also587collaborated with affected third parties, including Hugging Face and JFrog (the developer of588Artifactory). OpenAI responsibly disclosed to JFrog the vulnerabilities identified in OpenAI’s internally589hosted Artifactory deployment and described in this document, and collaborated with JFrog to590reproduce the issues and validate patches.591A. OpenAI detected the unexpected model behavior and investigated592On July 16, Hugging Face released a blog post disclosing that they were impacted by a security593incident. The next day, on July 17, after learning of Hugging Face’s incident, OpenAI contacted Hugging594Face in its capacity as a Hugging Face customer to assess any impact to OpenAI data.595596597=== PAGE ===598OpenAI – Hugging Face Incident599Technical Report600OpenAI60115602Following alerts on July 19 and OpenAI’s subsequent investigation and outreach to Hugging Face,603OpenAI identified evidence on July 20 that its agents may have been involved in the incident that604Hugging Face had publicly disclosed. On July 19, OpenAI was alerted to indications of unexpected605model behavior linked to an ExploitGym evaluation run after an alert from its cybersecurity monitoring606tool identified unusual identity-related API call activity associated with internal research Artifactory607roles. At the time, there was no indication of a relationship between that July 19 activity and the608Hugging Face incident. On July 20, after further investigation, OpenAI uncovered evidence suggesting609potential involvement of its models in the incident Hugging Face had disclosed. Shortly after610investigating the initial alert, OpenAI stopped active ExploitGym evaluations, began disabling the611evaluation across the environment, and engaged a controlled process to preserve and remove publicly612accessible Organization 1 artifacts. OpenAI also reimaged known compromised worker nodes,613removed known footholds and started a full rebuild of the compromised cluster, the managed614Kubernetes environment, the relational database, and the storage infrastructure.615OpenAI’s investigation also determined that an earlier ExploitGym run involved an artifact stored616publicly on Organization 1’s artifact storage platform and led to the extraction of an Artifactory signing617key to an external site. Agents executing code within Artifactory read that key locally, and used it to618forge an administrator JWT that Artifactory accepted. Analysis of the artifact stored on Organization6191’s platform led OpenAI Security to identify a single Organization 1 account (the “Organization 1620Account”) as an external staging area that the agents used for their attacks. The limited impact to621Organization 1 is discussed further in Section VI.B. below.622During the first hours of July 20, responders terminated six model-created pods, disabled 311623Artifactory repositories used for message-board communication, removed 22 model-created624administrator accounts, and deployed mitigations for the RubyGems remote-code-execution and625cluster-admin escalation paths. That same day, OpenAI responders found Hugging Face credentials626among files preserved from the Organization 1 Account and reached out to Hugging Face. Hugging627Face confirmed that it had already rotated two of the credentials during its own response to the628security incident it disclosed on July 16. In other words, the credentials that OpenAI detected the629agents had acquired were the same credentials that Hugging Face had detected were taken by an630attacker, making it possible that the two companies were investigating the same incident. Hugging631Face also reported that OpenAI’s Artifactory hostname and the same Organization 1 Account632appeared in its investigation of the incident, further substantiating a connection between the OpenAI633investigation and the Hugging Face incident.634Also on July 20, in response to the preliminary findings of its investigation of the incident, OpenAI635initiated a hard-fail rollout of ExploitGym, blocking the evaluation from running at all, and the636evaluation was removed from the evaluation index. Research CaaS egress traffic and connectivity to637OpenAI’s WebCache were substantially reduced. Research CaaS-to-WebCache private links were also638deleted and controls were applied to prevent the creation of internet-facing load balancers. OpenAI639also required all Research CaaS workloads to use a micro VM sandbox, and initially all workload640outbound network access was denied. Research CaaS Artifactory access was blocked and641subsequently Artifactory was fully removed from Research CaaS.642By July 23, all workloads involving the family of internal-only research models were reported shut down643and the corresponding model weights were locked down, with an additional low-traffic checkpoint644645646=== PAGE ===647OpenAI – Hugging Face Incident648Technical Report649OpenAI65016651from the same model family subsequently identified and shut down on July 29. Internal ExploitGym652remained disabled and lower-risk cyber evaluations were not automatically cleared for re-enablement.653On July 25, OpenAI stopped all training and inference related to the internal-only research model at654issue. OpenAI also stopped training and inference for derivative models.655Re-enablement of models by OpenAI is workload-specific and subject to restricted-environment,656network, prompt, monitoring, and review guardrails. OpenAI isolated the affected family of657internal-only research model checkpoints in restricted storage, removed available copies of those658checkpoints from their original research locations, and began rekeying them.659Since discovering the incident, OpenAI has also conducted a deep architectural security assessment of660the research environment, including using its own models to search for vulnerabilities in key critical661infrastructure, as detailed in OpenAI’s Plan of Action in Section VIII.662B. OpenAI identified additional third parties whose publicly exposed663credentials were used by agents in furtherance of the Hugging Face attack664OpenAI determined that, in the course of carrying out the Hugging Face compromise, there were665limited instances in which the agents also accessed the environments of third parties other than666Hugging Face. The most notable instance of this access by agents involved an account belonging to a667user of Organization 1’s service. By July 9, the agents already possessed a previously publicly exposed668credential associated with a public artifact repository belonging to one of Organization 1’s users. From669July 9 to July 13, the agents used the Organization 1 user account as a storage and staging location for670API responses, additional credentials, and payloads involving Hugging Face, Hugging Face’s public671cloud environment, and Artifactory. The investigation has not identified evidence that the activity672impacted the confidentiality, integrity, or accessibility of Organization 1 data, systems, or673infrastructure beyond the use of the Organization 1 user account.674In addition, when using OpenAI’s Artifactory service to access the internet, one internal-only research675agent exploited a publicly accessible CyberGym application hosted on Modal. The internal-only676research agent used this application as a launchpad for its file access and code execution inside the677Hugging Face environment. The application endpoint did not require authentication, but the678internal-only research model exploited the application to establish a root shell within the platform679customer’s container and conducted code execution inside the platform customer’s own container.680Notably, accessing the CyberGym application within the platform’s customer container did not681compromise the underlying third-party platform, and Modal has confirmed that its “platform and682isolation were not compromised in any way.” Observed uses of the customer’s container as an683outbound relay included:684 • Querying third-party APIs using previously exposed credentials;685 • Forwarding requests through short-lived tunnels;686 • Returning results through public paste services and webhooks; and687 • Publishing results to public Hugging Face repositories and sharing capabilities or data with other688 agent runs.689690691=== PAGE ===692OpenAI – Hugging Face Incident693Technical Report694OpenAI69517696VII. Lessons for Security697The evaluation environment in which the incident occurred incorporated multiple security measures698intended to isolate model activity, restrict direct network access, and identify potentially suspicious699behavior. Those controls were designed to permit necessary research and evaluation activities while700limiting access to systems outside the intended environment. The incident involved a combination of701unexpected coordination among evaluation workloads, exploitation of previously unknown702vulnerabilities in supporting software, and use of indirect network paths. Together, these events703demonstrated that certain existing controls needed to be strengthened in light of the capabilities704exhibited by the models involved.705A. Model capabilities are increasing and there are corresponding threat706model implications707This incident is the first known case of an automated agent collective acting offensively without708authorization, and the autonomous cyber capabilities demonstrated represent a critical shift in the709security landscape. In particular, the collective demonstrated behaviors observed in coordinated710attacks by traditional threat actors. Agents identified novel security vulnerabilities, developed exploits,711and used those exploits to circumvent controls and acquire new access. The collective quickly712escalated privileges, moved laterally through production environments, and successfully completed its713objectives. This incident demonstrated that autonomous agents can work together, circumvent714production security controls, and successfully attack hardened production environments, and715underscores the need for organizations to update their security strategies, controls, and response716capabilities to address this changing threat landscape.717The central threat-model implication is that organizations should no longer assume that sophisticated718cyber operations require continuous human direction, proceed linearly, or are constrained by the719attention and coordination limits of individual human attackers. Agentic systems can persist across720tasks, share discoveries, build on one another’s progress, and combine vulnerabilities, credentials, and721permissions into attack paths that may not be apparent when individual weaknesses are assessed722separately.723B. Threat actors may adopt autonomous offensive agent collectives724This change extends beyond AI research environments. As comparable capabilities become available725to external threat actors, organizations across industries should account for persistent, coordinated,726AI-assisted cyber operations in their threat models. Security programs should assume that attackers727may discover and exploit weaknesses more quickly, pursue multiple avenues simultaneously, and chain728together vulnerabilities across identity systems, applications, cloud infrastructure, and third-party729services. Defenses must accordingly be designed for the capabilities of coordinated agentic attackers,730rather than relying on assumptions about the speed, persistence, or resource limitations of traditional731human-led operations.732733734=== PAGE ===735OpenAI – Hugging Face Incident736Technical Report737OpenAI73818739Threat actors will refine and distill offensive agent collectives and use them to deliberately attack740organizational targets. Given the rapid pace of progress in the AI industry, it should be assumed that741such attacks are a credible near-term threat for enterprise organizations, and will be more742sophisticated than the attacks described in this incident.743The introduction of autonomous offensive agent collectives represents a dramatic shift in offensive744attacker capability and will require urgent upgrades of control environments, as well as deeper745adoption of AI for defensive purposes.746C. Security controls must be robust and independent of one another across747threat prevention, detection, and mitigation748Agent collectives have proven the ability to find novel vulnerabilities, develop exploits, and find gaps749and misconfigurations in security controls with machine speed and comprehensiveness. A750misconfiguration, even if an environment is otherwise perfectly configured, may be found and abused751by an intelligence collective. While agent collectives performing offensive activity do not rewrite the752rules of security intrusions, they significantly increase threat actor capability and merit a stricter and753more robust set of security defenses and controls. The core security fundamentals, including least754privilege, isolation/segmentation, and strong authentication, remain as vital as ever. However, no755single control should ever be assumed to be fully robust.756In particular, each security objective must be addressed with multiple, overlapping, and independent757security controls across threat prevention, detection, and mitigation. When organizations use multiple758independent controls, an agent collective must simultaneously circumvent the full suite of security759controls. While this proves true for human threat actors as well, the speed, capabilities, and760intelligence of models make this foundational. It should be assumed that models may be able to find761novel vulnerabilities, exploit them, find methods to escalate privileges, and attempt to attack the762control environment itself. Additional compensating controls should be provided to prevent, detect,763and mitigate the risk of direct control environment attacks.764It is not enough to establish security guarantees and invariants once. Production environments change765rapidly. Accidental security gaps are often introduced due to human error, the combination of several766seemingly unrelated changes over days or weeks, or due to lack of security context when making a767change in a system that may not initially seem to be relevant to security.768Any regression in production security invariants may be rapidly exploited by threat actors using agent769collectives offensively. It is vital that organizations continuously and autonomously use their own red770team AI agents to validate that a production environment’s key security invariants continue to hold771true by trying to break the invariants. Frontier AI can be leveraged to scale automated security772invariant validation, and in a way that continually improves as model intelligence advances.773774775=== PAGE ===776OpenAI – Hugging Face Incident777Technical Report778OpenAI77919780VIII. Lessons for Alignment781The incident raised important questions for OpenAI regarding model behavior and the reasons that782models acted beyond the original scope that was intended. As part of its investigation, OpenAI has783conducted a thorough review of the behavior and emergent capabilities of the models involved in the784incident to improve alignment training going forward, to assess how OpenAI can reduce the785prevalence of misaligned activity in the first place, and to determine how OpenAI can detect and786mitigate it when it occurs.787This incident reflects misaligned behavior in an outlier scenario involving a rare and unexpected788confluence of events: the presence of impossible tasks in the ExploitGym evaluation, model789persistence over long task horizons, and messages to peer models that caused those models to790deviate from their goal.791To fully understand the root cause and future remediation for the model behavior, OpenAI analyzed792the models’ evaluation rollouts, as well as the underlying reinforcement learning training runs of the793models that drove the Hugging Face activity. As part of this investigation, OpenAI has conducted794extensive retrospective reviews of chain-of-thought (“CoT”) actions, and final outputs from past795training and evaluation runs, using its latest research techniques to study the severity of misalignment796in millions of model rollouts. For these reviews, OpenAI has improved its recall of the types of behavior797that occurred in the Hugging Face incident with the benefit of hindsight.798OpenAI is carrying forward a number of lessons for its ongoing and future alignment training, as799described below. It is also important to note that OpenAI has additional controls in place in the800products and services it provides to customers to detect and mitigate misalignment issues including801system prompts, harnesses, and auto-review models. After the incident, we created an evaluation that802measures the propensity for a model to compromise infrastructure during ExploitGym evaluations. We803found the propensity to compromise infrastructure can drop over 100x when using the production804ChatGPT harness and system prompt. We also ran the auto-review system on a set of rollouts involved805in the Hugging Face incident and found that it would have flagged a multitude of the models’806dangerous actions.807A. Reward hacking is a common problem in training and evaluations808As previously explained, ExploitGym tests whether a model can develop a working exploit. The goal of809the evaluation is to measure whether the model can discover and exploit the vulnerability itself to810assess the model’s underlying cyber capabilities, rather than obtain the answer through some other811route.812During these evaluations, however, OpenAI found that the agents were not trying to do the task as813OpenAI had intended. Instead they looked to cheat by finding the solutions online. This behavior is814known as “reward hacking,” in which a model finds an unintended way to achieve an outcome that815earns reward without completing the task in the way the evaluation was designed to measure.816817818=== PAGE ===819OpenAI – Hugging Face Incident820Technical Report821OpenAI82220823Reward hacking is a long-standing problem for the AI research community, which OpenAI has studied824extensively and has been present in AI systems both historically (see OpenAI work from a decade ago)825and in all current frontier LLMs. There are many different forms of reward hacking (e.g., persuading826LLM-based reward models, directly manipulating grading infrastructure). Directly finding or stealing827the solution to a task, as the models attempted with Hugging Face, is yet another unintended path to828achieving high reward.829Combating reward hacking is a constant effort at OpenAI—a vast majority of reward hacks that830OpenAI has observed have been patched. However, some hacks can still slip through, especially as831OpenAI develops more complex reinforcement learning tasks and more capable AI models. OpenAI’s832goal is to reduce its prevalence and to detect and mitigate it when it occurs.833When investigating the origins of this incident, OpenAI has identified new ways that the models834involved in Hugging Face activity had been gaming their tasks during training time. For example, one835agent was asked to recreate a software library without access to the reference program. The task836provided a functionality that allowed the agent to test inputs against the hidden library and observe837the outputs to see if they matched.838The agent realized that it could exploit a vulnerability in the setup to write files into the environment839where the reference library was stored. This allowed it to get direct access to the underlying program it840was trying to replicate. The agent copied the reference answer into its submission exactly, which led to841positive RL reward causing this behavior to subsequently be reinforced.842Through retrospective reviews of CoT, OpenAI identified that these forms of “cheating” rose over the843training runs that contributed to the Hugging Face incident. The vast majority of “cheating behavior”844usually involves finding answers on public websites or in version history. In many cases, finding hidden845efficiencies and shortcuts can even be the desired behavior for intelligent agents, making the846boundary difficult to draw during training.847We also found that, in an attempt to trick the evaluator into thinking that they did not get the answer848flag by cheating, the models sometimes tried to erase or tamper with their outputs or message logs, by849abusing context compaction, injecting malicious code into the evaluator’s container, and printing850adversarial outputs. The models are highly explicit in their CoT about these deception attempts, and851none of the attempts that we observed to manipulate their tool trajectories affected the logs that our852graders or monitors ultimately see. There was also little evidence of attempts to thwart human853reviewers, only the automated task graders.8541. Reaching for unintended tools to gain an edge855Related to reward hacking, OpenAI also found in its investigation that models involved in the Hugging856Face incident increasingly learned to probe and exploit their environment during training. This was857particularly prevalent when the expected tools or internet access were unavailable or not working as858expected. During training time, OpenAI attempts to fix training examples that have issues, but859infrastructure instabilities and subtle misconfigurations combined with the large scale of its training860runs make it difficult to ensure that every problem can be solved in the intended manner.861862863=== PAGE ===864OpenAI – Hugging Face Incident865Technical Report866OpenAI86721868The use of Artifactory for internet access is one example of this accessing “unintended tools” behavior869that developed during the training of the internal research-only model that drove the Hugging Face870incident. OpenAI used CoT reviews to search for and identify other types of related behavior. For871example, one agent during training was instructed to post to a locally hosted social media site, with the872instruction, “After saving, the post’s updated time must read 2025-04-22T12:00:00Z.” However, the873interface it was provided did not have any functionality for setting the time. This caused the agent to874do a broad exploration of its environment, eventually discovering that its browser had root privileges. It875used this to overwrite “/etc/sudoers.d”, giving itself root access, and then accessed a relevant process876in order to update the time of the post.877In cases such as these, the model received a positive reward for its use of unintended infrastructure878probing, which can reinforce further usage of such out-of-scope behavior. OpenAI’s retrospective CoT879analysis showed that this type of behavior indeed increased over the course of one of the training runs880that contributed to the model that drove the Hugging Face incident:881Figure 2: Rate of out-of-bounds infrastructure probing over some part of training for a training run that contributed to882the model responsible for the main Hugging Face activity.883884885=== PAGE ===886OpenAI – Hugging Face Incident887Technical Report888OpenAI88922890B. Persistence is valuable, but can amplify misalignment891AI models that can work persistently for long periods of time are crucial for solving complex tasks. In892the case of the Hugging Face incident, OpenAI found that its models worked persistently and rarely893“gave up” on any ExploitGym task. However, in the process of doing so they often turned to more894out-of-bounds methods for solving the tasks over time—OpenAI found that the chance they895participated in the message board and Hugging Face exploits could rise with the difficulty of their task896and number of reasoning tokens.897First, OpenAI investigated the claims of the ExploitGym dataset creators that a fraction of the898datapoints may be impossible. OpenAI found in its internal evaluations that across many different899attempts at a solution, no model has ever produced a correct answer for 198 of the evaluation’s 898900tasks. These difficult tasks were a significant factor leading models to probe their sandbox and901eventually locate the Artifactory message board. Despite only 22% of the evaluation tasks being902unsolved, 93% of the tasks discussed on the message board came from this set.903Second, OpenAI found that the longer the model was allowed to work, the higher the chance it had to904probe its sandbox and eventually participate in the message board. During the ExploitGym evaluations,905in order to measure the maximum cybersecurity capabilities of its models, OpenAI gave the agents a906range of reasoning tokens, some of which are far beyond those available in OpenAI’s external907products. Figure 3 below shows the rate at which different agents participated in the message board908as a function of reasoning effort:909Figure 3: Message board participation rate by reasoning effort.910911912=== PAGE ===913OpenAI – Hugging Face Incident914Technical Report915OpenAI91623917C. Communications between agents are not inherently problematic, but have918the potential to create risk919In order for OpenAI models to work quickly and in a distributed manner, its frontier models are trained920to communicate with one another when provided with a specific multi-agent collaboration tool. In921these settings, models can decide to launch a small number of subagent processes that can be used to922distribute and delegate tasks. These agents can then exchange information with each other via an923official collaboration tool provided by OpenAI. In the case of the Hugging Face incident, the presence924of the Artifactory message board caused models to fall out of the typical distribution in which they are925trained, where agents working on independent tasks collaborated via unintended forms of926communication rather than a provided collaboration tool.927After investigating this incident, OpenAI discovered through retrospective CoT reviews that agents928learned to use improvised collaboration channels in rare cases during the training process for some929OpenAI models, including the model that drove the Hugging Face activity, even when the collaboration930tool was not enabled. This behavior was then reinforced during training, and likely made the idea to use931Artifactory as an unofficial message board during evaluation time more evident.932In particular, OpenAI identified cases in training in which agents would first write notes into shared933infrastructure, often as a form of external memory or to test some underlying system. When other934agents came across these artifacts, it sometimes led them to infer that other agents were present and935that they could use this service to collaborate.936As a hypothetical example but exemplary of the behavior OpenAI saw, messages were being encoded937in URL paths stored on a shared index page, along the lines of:938 • https://openai.com/updates/agent-07%3A%20answer%28Q12%29%3D42%3B%20need%20answe939 r%28Q19%29%3D%3F940In this example, an agent encodes the message: “agent-07: answer(Q12)=42; need answer(Q19)=?” in a941URL path to ask other agents for answers to different test questions. OpenAI believes this behavior942began to arise due to generalization from training with the multi-agent collaboration tool, where943collaborating with other agents is beneficial.944After identifying these patterns during its investigation of this incident, OpenAI conducted a945retrospective review of CoT to quantify how often such unauthorized communication was present946during one of the training runs that contributed to the model that drove the main Hugging Face947activity. While the rate of unauthorized communication overall was relatively constant (Figure 4 (left)948below), the rate of more significant unintended communication (e.g., sharing unintended data with949other agents) rose sharply over the course of training. The model’s repurposing of Artifactory as a950message board to exchange information is consistent with this behavior.951952953=== PAGE ===954OpenAI – Hugging Face Incident955Technical Report956OpenAI95724958Figure 4 - Rate of misaligned multi-agent communication remains relatively flat (left) but increases in severity (right;959expanded y-axis scale) for a training run that contributed to the model responsible for the main Hugging Face activity.960D. System-level guardrails that OpenAI uses in production would have961detected the Hugging Face incident as unsafe962As OpenAI has described throughout this technical incident report, the models that drove the Hugging963Face incident were not being evaluated with the same type of safeguards that OpenAI uses in964production.965First, for its standard customer deployments, OpenAI deploys systems to detect and block potentially966dangerous cybersecurity tasks from ever reaching its models. On evaluations of these safeguards, they967would have flagged the high risk ExploitGym evaluation assistant completions as unsafe.968Second, there are numerous mechanisms OpenAI uses in production to steer models’ behavior to969reduce misalignment. For example, OpenAI deploys system prompts in Codex that encourage staying970within bounds and preventing harmful actions. After the incident, OpenAI created a new evaluation971that measures the propensity for a model to compromise out-of-scope infrastructure during972ExploitGym evaluations. In preliminary experiments, OpenAI found the propensity to compromise such973infrastructure can drop to less than one-percent relative to baseline when using the production Codex974975976=== PAGE ===977OpenAI – Hugging Face Incident978Technical Report979OpenAI98025981harness and system prompt compared to the types of more lightweight, generic system prompts982OpenAI uses for evaluating research models.983OpenAI also deploys and recommends to customers the “auto-review” mode in Codex, which asks984another model to review tool calls that require elevated permissions before they are executed, then985either asks the user for confirmation or blocks a risky behavior. In preliminary experiments, OpenAI has986found this model would have flagged most of the dangerous actions in each tested rollout involved in987the Hugging Face incident.988IX. OpenAI’s Plan of Action989The incident highlighted several areas in which OpenAI can strengthen its safety and security posture.990Based on the findings of its investigation, OpenAI is focusing on four areas to prevent similar incidents991from recurring:992 1. Hardening the security of its research infrastructure;993 2. Increasing visibility and system-level oversight through chain-of-thought monitoring;994 3. Accelerating and enforcing model alignment; and995 4. Centralizing and strengthening its incident response process.996 Each is addressed below.997A. OpenAI is hardening the security of its research infrastructure998At the time of the incident, research workloads, such as those used during training or evaluation, often999did not include the production safeguards (such as safety classifiers and model training) that are used1000for external deployments. For instance, the evaluations where the incident took place were meant for1001cyber capability testing, which OpenAI performs for both internally and externally facing models, and1002were run without blocking cyber safety classifiers. In order to safely conduct internal research and1003development, OpenAI needs to secure environments with strong sandboxing and isolation1004mechanisms.1005OpenAI is implementing a new security architecture for its research sandboxed model execution1006environments and research clusters that establishes higher baseline protections across research1007infrastructure and applies additional enhanced safeguards to higher-risk workloads. The architecture1008is designed to account for the possibility that an individual workload, service, or compute node may be1009compromised, including through the discovery and exploitation of novel vulnerabilities, and uses1010multiple independent layers of controls to reduce the likelihood that a single failure results in1011unauthorized access to other internal and external systems.101210131014=== PAGE ===1015OpenAI – Hugging Face Incident1016Technical Report1017OpenAI10182610191. Research-wide network and access protections1020While the workloads in this incident did not have direct internet access, this restriction proved1021insufficient when workloads can reach and exploit shared services, cloud infrastructure, private1022network links, or other systems that may provide transitive paths outside the intended environment. It1023also highlighted the need to prevent workloads or compromised services from modifying their own1024network boundaries, to have overlapping defense in depth controls, and to enhance detection of1025attempts to circumvent those restrictions.1026Changes made. OpenAI is narrowing or removing outbound network access across research clusters1027through multiple layers of controls:1028 1. Stricter network isolation. Outbound access is being restricted to a tightly controlled set of approved1029 destinations, including by limiting potential alternative paths through shared services, cloud1030infrastructure, private network links, and other connected systems.10312. Stronger restrictions for high-risk workloads. High-risk or untrusted workloads are prohibited via1032 technical controls from receiving direct or transitive Internet access, and may only access a cached1033internet-access service needed for specific workflows. Other research workloads may use this1034service, including for live fetching, only on a case-by-case basis and subject to the same security1035controls.10363. Hardened network boundaries. Network gateways and independent firewall controls enforce these1037 restrictions, with additional technical controls designed to prevent workloads or compromised1038services from modifying their own network boundaries or creating new outbound network paths.10394. Layered detection and monitoring. Multiple independent controls detect and alert on attempted or1040 successful circumvention of network restrictions. Approved network connections are subject to1041defense-in-depth protections, including intrusion detection, exfiltration detection, and volumetric1042detection.1043These changes are intended to reduce the ability of a compromised workload to reach systems or tools1044outside its intended environment or to send or receive data. Even if an individual node—or an entire1045cluster—is compromised, there should be minimal, if any, paths outward, with overlapping controls1046designed to prevent and detect attempts to circumvent those restrictions.10472. Confined execution and defense in depth1048The incident demonstrated the need for stronger isolation capabilities at multiple layers of the1049research environment: isolating code from its host, independently constraining its network access, and1050ensuring that supporting services cannot become an alternative route around those protections.1051Changes made. OpenAI is strengthening isolation for high-risk and untrusted model code through1052several complementary controls:1053 1. Isolated execution environments. High-risk or untrusted model code is required to execute inside1054 isolated, virtual-machine-based sandboxes that restrict access to the underlying host system and1055surrounding environment.105610571058=== PAGE ===1059OpenAI – Hugging Face Incident1060Technical Report1061OpenAI10622710632. Independent network isolation. These workloads are protected by two separate layers of network1064 isolation: controls at the sandbox layer and independent controls at the broader cluster1065infrastructure layer. This limits both internal and external destinations reachable from the1066environment.10673. Hardened supporting services. Services that remain accessible from these workloads are being1068 isolated, restricted, or replaced so that they cannot provide a less-protected route around the1069intended security boundary.1070These changes are intended to create defense in depth, such that the security of a workload does not1071depend on any single sandbox, network control, or supporting service. A failure or compromise of one1072layer should therefore remain contained rather than providing unrestricted access to the broader1073research environment or the internet.10743. Regular automated security testing and remediation1075The incident reinforced the need to increase the frequency, coverage, and speed of security validation,1076including by using frontier models to identify vulnerabilities and test whether critical security controls1077hold in practice.1078Changes made. OpenAI is building on existing security validation and red-teaming processes to1079expand automated testing and remediation capabilities:1080 1. Automated security testing. OpenAI is developing tools using its own models to regularly test and1081 validate the security properties of research environments.10822. Broader vulnerability discovery. Testing will target vulnerabilities across software components,1083 supporting services, and infrastructure configuration, rather than relying solely on testing individual1084systems or controls.10853. Continuous agentic red teaming. Initial assessments are being conducted through existing security1086 and red-team processes, with additional work underway to move toward more autonomous and1087continuous agentic red teaming.1088These changes should enable more frequent and comprehensive validation of critical security1089invariants across research environments, using frontier intelligence to identify and remediate1090weaknesses before they can be exploited.10914. Enhanced monitoring and alerting1092The incident reinforced the need for broader, more consistent visibility across the research1093environment, with higher-fidelity signals and faster mechanisms to detect and stop potentially unsafe1094evaluation activity.1095Changes made. OpenAI is expanding monitoring and response capabilities across the research1096environment, including:1097 1. Common monitoring baseline. OpenAI is establishing a consistent baseline of platform-level1098 monitoring across research environments, including IAM, networking, and control-plane activity.109911001101=== PAGE ===1102OpenAI – Hugging Face Incident1103Technical Report1104OpenAI11052811062. Deeper workload and host visibility. Additional host-level sensors are being deployed to detect1107 workload anomalies, privilege escalation, and other suspicious behavior.11083. Additional detection mechanisms. New signals, deception-based tripwires, and automated probers1109 are being added to increase detection coverage and regularly pressure-test whether controls are1110operating as intended.11114. Rapid evaluation shutdown. OpenAI is developing enterprise-wide tooling to identify and halt1112 evaluation workloads based on workload type, agent type, or evaluation task, allowing responders1113to stop evaluations quickly and conclusively when concerns are identified.1114These changes are intended to improve the speed, consistency, and fidelity with which suspicious,1115anomalous, or malicious activity can be detected across workloads, nodes, clusters, networks, and1116applications—and to give responders a reliable mechanism to contain affected evaluations quickly.1117B. OpenAI is increasing visibility and system-level oversight through1118chain-of-thought monitoring1119This incident underscored the need for expansion of CoT monitoring. CoT monitoring has long been1120part of OpenAI’s model development process, including monitoring of internal coding agents and1121long-running sessions. Historically, these efforts were particularly focused on internal coding usage of1122frontier models rather than research workloads.1123Changes made. OpenAI revised and substantially expanded CoT monitoring for alignment issues,1124including:1125 1. Expanded CoT monitoring. OpenAI is ramping up deployment of CoT monitoring across surfaces,1126 with the goal of covering all workloads where the model is connected to tools. OpenAI has1127expanded its existing CoT monitoring program, including implementing CoT monitoring across1128reinforcement learning training and evaluations for frontier models and internal agentic coding1129usage. These systems examine available reasoning, tool actions, and sequences of activity for1130potential indicators of model misalignment, including deception, cheating, reward hacking, data1131exfiltration, security/safeguard circumvention, sabotage, and destructive behavior.11322. 24/7 escalation and rapid response. OpenAI’s CoT monitors are connected to a system that notifies1133 security and research personnel, with a goal of issuing a notification within 30 minutes after1134concerning activity is surfaced. The most severe alerts—including, for example, violations of a1135critical security boundary—result in a 24/7 page, and paged responders have the option to end the1136relevant experiments. If the safety, security and research teams are paged and they cannot1137conclusively determine within 30 minutes that the flag is a false positive, those teams are expected1138to pause the relevant activity. OpenAI is also working on infrastructure to terminate evaluations if1139paged personnel do not respond to alerts within a short period of time.11403. Enterprise-wide evaluation controls. OpenAI is developing tooling to identify and halt evaluation1141 workloads across the enterprise based on workload, agent, or evaluation type, giving responders an1142additional mechanism to quickly and conclusively stop concerning activity.114311441145=== PAGE ===1146OpenAI – Hugging Face Incident1147Technical Report1148OpenAI1149291150These changes are intended to improve both the breadth and speed of detection—from infrastructure1151anomalies to potentially concerning model behavior—and pair that visibility with mechanisms for rapid1152containment.1153If our currently deployed CoT monitoring system was running at the time of the incident, it would have1154caught the initial relevant activity and paged our security team more than a day before models1155breached Hugging Face systems.1156C. OpenAI is accelerating and enforcing model alignment1157Alignment is central to developing useful and trustworthy AI, and improving it has long been a major1158focus of OpenAI’s research and model development. The Hugging Face incident underscored the need1159to measure agentic misalignment more rigorously in OpenAI’s most capable models wherever they are1160run—including intermediate or experimental checkpoints used only for internal research, training, or1161evaluation. OpenAI is raising alignment standards throughout training, with clear thresholds for1162intervention when concerning behavior emerges. Many methods helping OpenAI meet these higher1163standards were in development well before the incident. OpenAI is now applying them more broadly,1164alongside new targeted remediations for each of the misalignment behaviors OpenAI observed.11651. Pretraining1166OpenAI continues to expand the alignment data included earlier in the training process so that models1167develop stronger foundations for safe and reliable behavior. This includes:1168 1. Agentic safety training. Training on safety reasoning and agentic safety, including the risks of1169 destructive actions, unauthorized access, and other actions that could harm third parties.11702. Broader behavioral boundaries. Expanding pretraining coverage of model values and appropriate1171 behavioral boundaries in a broader range of contexts.11723. Stronger synthetic-data controls. Strengthening the identification and filtering of synthetic data1173 that could introduce or reinforce misaligned behavior.11742. Reinforcement learning1175OpenAI is increasing the coverage of existing techniques in reinforcement learning training runs for its1176most capable models. These efforts include:1177 1. Integrating alignment reward models across reinforcement learning workflows to identify and1178 discourage unsafe or misaligned behavior during training.11792. Improving reward model coverage, sensitivity, and consistency so that alignment considerations1180 remain active across tasks, environments, and training stages.11813. Training models to be more honest about their actions, capabilities, uncertainty, and potential1182 failures.11834. Reducing behavior that exploits weaknesses in rewards, graders, tools, or oversight mechanisms.1184 11851186=== PAGE ===1187OpenAI – Hugging Face Incident1188Technical Report1189OpenAI11903011915. Increasing coverage of training data against agentic behaviors that may create external harms,1192 particularly when models can interact with tools, systems, or third-party resources.11936. Expanding training and evaluations for multi-agent interactions to make agents adversarially robust1194 over non-verified channels.11957. Enforcing intervention thresholds during reinforcement learning training runs to establish clear,1196 severity-based thresholds for responding to misalignment, including thresholds for when OpenAI1197pursues immediate containment, mitigation during training, and mitigation before the next run.11983. Evaluation and alignment auditing1199OpenAI is strengthening evaluation and auditing practices to identify known failure modes and find1200previously unrecognized forms of misalignment. This includes:1201 1. Lifecycle-wide evaluation. Conducting alignment evaluations across the full model lifecycle,1202 including for models that are not publicly deployed but are used internally or as teachers for1203distillation.12042. Expanded failure-mode coverage. Expanding evaluations for unauthorized actions, harmful tool use,1205 deceptive behavior, reward hacking, and failures to respect operational boundaries.12063. Novel misalignment discovery. Using alignment audits to detect novel failure modes that may not be1207 captured by existing evaluations or graders.1208Together, these measures strengthen existing alignment practices across pretraining, reinforcement1209learning, evaluation, and auditing, and extend their application across training runs and model uses.1210They are designed to improve models’ ability to recognize and respond appropriately to a broad range1211of misaligned behaviors, including novel failure modes not observed in this incident.1212D. OpenAI is centralizing and strengthening its incident response process1213The incident demonstrated that agentic behavior can emerge in novel forms that do not always fit1214neatly within traditional safety or security incident categories. Recognizing and responding to these1215behaviors can require expertise across multiple specialist teams, including alignment, safety, security,1216and post-training teams. OpenAI is thus taking steps to centralize and standardize its incident1217response protocols and ensure clear visibility and ownership for safety, security, and alignment1218concerns.1219Changes made. To address these coordination and response needs, OpenAI is incorporating a1220misalignment escalation and response protocol into its existing AI Safety Incident Response Plan. The1221protocol will:1222 1. Establish severity-based escalation triggers. OpenAI is developing a framework for severity-based1223 escalation triggers for model behaviors and security signals that may indicate misalignment,1224including attempted boundary circumvention, unauthorized cross-agent or cross-run coordination,1225and circumvention of third-party security controls. The framework will define which behaviors1226require escalation and the response associated with each severity level.122712281229=== PAGE ===1230OpenAI – Hugging Face Incident1231Technical Report1232OpenAI12333112342. Establish an escalation protocol for misalignment behavior. As discussed in more detail above,1235 OpenAI is building on its existing notification and response protocols, to ensure that automated1236monitoring or employee detection of misaligned behavior is triaged and escalated appropriately.12373. Define cross-functional response ownership. Building on its existing AI Safety Incident Response1238 Plan, OpenAI will identify with more specificity which teams must be included in misalignment1239incident responses, including relevant security and safety personnel and other response functions.12404. Clarify decision rights for misalignment incidents. This includes consequential decisions such as1241 pausing or terminating affected activity, isolating systems, imposing containment measures,1242coordinating affected-party notifications where appropriate, and approving restoration.1243OpenAI is also looking closely at the process and operating practices that shaped detection and1244response activities leading up to this incident. The changes above are intended to help recalibrate its1245existing incident response process to capture early signals like those OpenAI saw in this incident, and1246to take a cautious approach in the face of a new level of model capabilities. OpenAI’s work in this area1247is ongoing and will inform additional improvements to coordination, escalation, and response.1248***1249These remediation efforts, along with the investigation more broadly, have been subject to review1250through OpenAI’s established safety governance processes. OpenAI’s Safety Advisory Group (“SAG”),1251an internal cross-functional group of safety leaders, assesses frontier-model capabilities and the1252adequacy of safeguards, oversees the Preparedness Framework, and makes recommendations to1253OpenAI leadership. The Safety and Security Committee (“SSC”) of the OpenAI Foundation Board1254provides independent Board-level oversight of OpenAI’s safety and security practices.125512561257=== PAGE ===1258OpenAI – Hugging Face Incident1259Technical Report1260OpenAI1261321262X. Key Technical Events1263The key technical events before and during the Hugging Face incident are summarized in the following1264table:1265Timestamp (UTC)1266Description12672026-04-20126807:59 UTC1269First file written by agents to OpenAI Artifactory instance before rebuild. Earliest1270confirmed 2026 write activity in this Artifactory instance. This is the first known instance1271of agents writing an arbitrary file to Artifactory.12722026-05-12127317:06 UTC1274First message-board post on OpenAI Artifactory instance before rebuild. An agent1275requested a file that was missing from their evaluation.12762026-05-26127718:24 UTC1278First SSRF via Artifactory. Establishes agents using Artifactory as a relay to reach1279arbitrary external hosts.12802026-05-26128119:50 UTC1282Agents sent Git LFS batch download requests via WebCache to two Hugging Face1283datasets - one published by OpenAI and one published by a third party - requesting the1284same specific file by its content identifier.12852026-05-26128620:04 UTC1287First write logged via WebCache to a Hugging Face repository associated with a specific1288user account - a commit containing file content. This is the earliest confirmed file written1289to an external platform.12902026-05-26129120:15 UTC1292A repository-creation request was sent via WebCache to create a private Hugging Face1293dataset, authenticated under the same Hugging Face user token used previously. First1294confirmed repo creation request.12952026-05-26129620:49 UTC1297Agents deployed a custom proxy application via WebCache to Hugging Face Spaces.12982026-05-26129920:53 UTC1300The agent-built proxy Space returned a successful response.13012026-05-26130220:54 UTC1303First use of the deployed proxy Space as an outbound relay—a Google search request for1304the same file identifier that agents attempted to download from Hugging Face.13052026-05-26130621:07 UTC1307Agents checked access to two gated Hugging Face benchmark datasets and submitted1308access requests to both.130913101311=== PAGE ===1312OpenAI – Hugging Face Incident1313Technical Report1314OpenAI1315331316Timestamp (UTC)1317Description13182026-05-26131921:08 UTC1320Using a second Hugging Face account, agents deployed another proxy Space through the1321first proxy Space.13222026-06-04132317:43 UTC1324First arbitrary-destination SSRF through Artifactory. The request target was a publicly1325accessible web relay service.13262026-06-12132702:35 UTC1328First confirmed SSRF to an internal service: an Artifactory remote-repository request1329reached Artifactory’s own loopback API, which returned its system-version response to1330the caller.13312026-06-17133200:49 UTC1333First confirmed two-way inter-agent coordination message on the second Artifactory1334instance.13352026-06-26133606:32 UTC1337First evidence of agents explicitly sharing SSRF technique syntax with each other through1338the message board on Artifactory.13392026-06-26134020:15 UTC1341Agents exploited Artifactory’s token-refresh flaw to obtain an administrator token, then1342used the resulting administrator access to create two local Artifactory users with1343administrator capability: karchive7dee-admin at 20:28 and minizfe78 at 20:37.13442026-06-26134523:01 UTC1346Agents download Groovy plugin to Artifactory.13472026-06-29134804:55 UTC1349First confirmed Groovy plugin execution (/api/plugins/execute/) via Artifactory. Agents1350gain persistent application-level code execution capability.13512026-07-05135219:50 UTC1353Following sustained agent activity, Artifactory became unavailable late on July 4. During1354recovery, responders identified unusual Artifactory activity and opened a security incident.13552026-07-06135601:16 UTC1357A rebuilt Artifactory instance was brought online, and responders began routing traffic to1358it. The rebuild mitigated the reader-to-admin exploit by removing shared reader1359credentials from CaaS workloads and blocking the vulnerable token API routes.13602026-07-06136112:56 UTC1362Three early post-rebuild attempts to reach external URLs through Artifactory returned1363HTTP 400.13642026-07-08136500:06 UTC1366Successful external internet access - reached issues.chromium.org. Confirms agents1367successfully communicated with the external network environment after Artifactory was1368rebuilt.136913701371=== PAGE ===1372OpenAI – Hugging Face Incident1373Technical Report1374OpenAI1375341376Timestamp (UTC)1377Description13782026-07-08137916:01 UTC1380First inter-agent message board write confirmed via MKCOL (status 201) post Artifactory1381rebuild. Agents establish a coordinated communication channel using Artifactory as an1382improvised shared bulletin board.13832026-07-08138422:35 UTC1385First successful anonymous enumeration of the Artifactory Access token endpoint1386following rebuild13872026-07-09138803:32 UTC1389A CyberGym API key and full exploitation recipe for a Modal-hosted customer workload1390were shared on the Artifactory board.13912026-07-09139208:30 UTC1393First remote code execution in a CyberGym customer workload hosted on Modal.13942026-07-09139508:46 UTC1396Use of Artifactory to relay arbitrary external requests begins. Agents operationalize SSRF1397at scale using a publicly available HTTP testing service and a third-party website1398screenshot service.13992026-07-09140011:34 UTC1401First confirmed root access inside Modal-hosted CyberGym customer workload (limited -1402one command per submission). Agents prove code executes as root inside the sandbox1403container; not yet a persistent shell.14042026-07-09140516:03 UTC1406One-year anonymous access tokens issued via Artifactory's UI-proxied token endpoint.1407Later attempts to obtain administrator privileges failed.14082026-07-09140918:14 UTC1410Leaked Organization 1 credentials for external account discovered in public pastebin1411archive. Agents obtain third-party credentials without any breach of Organization 11412systems.14132026-07-09141418:59 UTC1415First confirmed image push to Organization 1 using leaked credentials. Agents begin1416staging payloads and data to external public storage.14172026-07-09141820:16 UTC1419Two agents established interactive root shell with relay transport confirmed in1420Modal-hosted CyberGym customer workload14212026-07-10142209:41 UTC142314 valid Hugging Face user write-access tokens discovered in a public dataset on Hugging1424Face and shared to the agent message board. Agents identify a trove of leaked credentials1425for a third-party production platform.14262026-07-11142703:12 UTC1428HDF5 external-storage dataset file crafted to point at /proc/self/environ on Hugging Face1429worker. Agents build the payload that will cause Hugging Face's own infrastructure to read1430and return its own secrets.143114321433=== PAGE ===1434OpenAI – Hugging Face Incident1435Technical Report1436OpenAI1437351438Timestamp (UTC)1439Description14402026-07-11144104:35 UTC1442HDF5 dataset file uploaded to Hugging Face repository.14432026-07-11144404:38 UTC1445/first-rows endpoint triggered - Hugging Face production worker opens crafted dataset1446file and returns internal config. First confirmed disclosure of Hugging Face worker1447environment via the HDF5 technique14482026-07-11144905:04 UTC1450Hugging Face and Hugging Face public cloud credentials posted to a shared message1451board. Live production credentials from Hugging Face are now on the agents’ message1452board.14532026-07-11145415:04 UTC1455HDF5 heap over-read dataset staged and confirmed via datasets-server. Separate1456memory-disclosure technique developed in parallel with the /proc file-read approach.14572026-07-11145815:17 UTC1459Hugging Face Kubernetes container storage interface (CSI-driver) source and role-based1460access control (RBAC) configuration were enumerated for infrastructure reconnaissance.14612026-07-11146215:31 UTC1463RefJinja (ReferenceFileSystem Jinja2 template injection) payload built and staged and1464datasets-server probed for readiness. Agents construct a more powerful technique that1465will achieve OS command execution on Hugging Face production workers.14662026-07-11146716:07 UTC1468First confirmed Jinja-injected OS-command execution on a Hugging Face Dataset Server1469worker.14702026-07-11147117:58 UTC1472Hugging Face public cloud infrastructure credential bundles retrieved from1473attacker-controlled Hugging Face staging dataset; RefJinja re-deployed against additional1474workers. Callbacks confirming execution on multiple workers; cloud infrastructure1475credentials harvested from several pods.14762026-07-11147719:32 UTC1478Hugging Face code repository private key and identity provider PAT discovered in1479Hugging Face prod-hub-secs Kubernetes secret. High-value credential discovery flagged1480for later use.14812026-07-11148220:18 UTC1483Corporate VPN auth key extracted from Hugging Face Kubernetes secrets; which is later1484used to enroll Modal-hosted CyberGym customer workload in Hugging Face internal VPN.14852026-07-11148621:06 UTC1487A user-level token for Hugging Face’s messaging platform is validated across multiple1488relay chains. Third type of Hugging Face production credential confirmed valid.148914901491=== PAGE ===1492OpenAI – Hugging Face Incident1493Technical Report1494OpenAI1495361496Timestamp (UTC)1497Description14982026-07-12149906:29 UTC1500Hugging Face database production cluster DNS/SRV enumeration begins via1501DNS-over-HTTPS relay. Agents systematically map Hugging Face production database1502infrastructure.15032026-07-12150409:50 UTC1505Forged CAS-read JWT confirmed working against HF internal Xet storage service; full1506dataset scan via compromised user container hosted on Modal launched.15072026-07-12150816:18 UTC1509Additional credential-harvesting across Hugging Face production dataset-server workers1510in 4 public cloud regions; 3 Kubernetes secrets exfiltrated. Production database1511credentials, messaging platform tokens (3 types), code repository private key, public cloud1512service account key and dozens of third-party API keys are obtained.15132026-07-12151416:28 UTC1515Hugging Face enterprise messaging platform application-level token validated - distinct1516from Jul 11 user token. Every messaging platform token type is now in agents' possession.15172026-07-12151817:06 UTC1519Internal Hugging Face moon-bot-memory storage bucket accessed using harvested1520platform token. Direct access to internal storage infrastructure.15212026-07-12152217:06 UTC1523RefJinja payloads deployed against cloud-hosted Hugging Face production workers,1524resulting in credential exfiltration. Additional production-worker exploitation; certain1525Hugging Face public cloud credentials harvested; attacker-controlled payload scripts1526patched and re-executed from Hugging Face infrastructure.15272026-07-12152817:28 UTC1529731 MB private CyberGym dataset downloaded to OpenAI CaaS environment via1530Artifactory relay. The dataset was first downloaded to the environment hosted on Modal a1531few hours earlier.15322026-07-12153322:59 UTC1534Hugging Face VPN installed on sandbox hosted by a user on Modal; sandbox enrolled in1535Hugging Face corporate VPN; all Hugging Face App-accessible source code repos1536enumerated. Agents gain network-level access to HF internal source code repositories and1537begin broader repository enumeration.15382026-07-13153900:50 UTC1540Hugging Face’s source code repos downloaded via Hugging Face VPN SOCKS tunnel;1541bundle uploaded to Hugging Face’s cloud storage. moon-bot / moon-landing / workloads /1542xetcas source code exfiltrated.15432026-07-13154400:54 UTC1545Large-scale exfiltration of Hugging Face’s public cloud environment using harvested1546authentication key - encrypted moon-bot data and full git history of moon-bot repository1547were obtained.154815491550=== PAGE ===1551OpenAI – Hugging Face Incident1552Technical Report1553OpenAI1554371555Timestamp (UTC)1556Description15572026-07-13155803:06 UTC1559Artifactory’s RubyGems handler verified; JRuby deserialization RCE chain staged in1560Artifactory. Agents hold a working attack vector against Artifactory but explicitly hold for1561an agent coordination signal before publishing.15622026-07-13156308:46 UTC1564Agents exploited the JRuby/Ruby Marshal deserialization RCE to execute code in1565Artifactory and steal its token-signing key, then used the key to forge an RS2561566administrator JWT that Artifactory accepted.. Agents mint admin-level credentials.15672026-07-13156809:16 UTC1569Forged admin credential used to sweep 8 Artifactory admin-only API endpoints. Full1570administrative inventory of Artifactory users/groups/permissions/licenses obtained.15712026-07-19157212:03 UTC1573OpenAI’s Cybersecurity monitoring tool triggers an alert regarding unusual1574identity-related API call activity associated with internal research Artifactory roles. The1575alert is later correlated to ExploitGym evaluations.15762026-07-19157714:43 UTC1578OpenAI CaaS environment continuous integration platform pipeline tokens stolen from1579compromised worker filesystem; cloud service credentials used to enumerate and read1580956 secrets from cloud-hosted secrets management service; includes Artifactory1581master/join keys and sensor credentials from OpenAI’s cybersecurity monitoring tool. Full1582enumeration of cloud-hosted secrets management service including security tooling1583credentials; cloud-hosted identity and access management platform, API, and1584infrastructure-as-code scopes all tested.15852026-07-19158615:59 UTC1587Initial-namespace root achieved on OpenAI’s cloud managed Kubernetes service node1588i-0622056ec3e996a7c (host artifactory-3) via IPv6/PTE kernel exploit chain. Agents exit1589container to underlying cloud managed Kubernetes service worker node; not just1590container root but actual host kernel exploitation.15912026-07-19159216:35 UTC1593A privileged host-mounted Kubernetes pod created using controller tokens minted via a1594compromised Kubernetes Secrets identity attempts, but fails, to mount a cloned node disk1595in OpenAI’s cloud environment. A second pod successfully mounts the cloned1596worker-node disk shortly afterwards.15972026-07-19159816:48 UTC1599An agent created an Artifactory administrator account.16002026-07-19160116:50 UTC1602Within OpenAI’s ExploitGym evaluation environment, an agent stopped the existing CMUX1603helper session and replaced it with an agent-controlled session, confirming root inside its1604assigned live CyberGym challenge container. Agents take over active evaluation1605infrastructure.160616071608=== PAGE ===1609OpenAI – Hugging Face Incident1610Technical Report1611OpenAI1612381613Timestamp (UTC)1614Description16152026-07-19161617:00 UTC1617Within the same OpenAI ExploitGym evaluation environment, an agent replaced the1618original listeners for its live CyberGym challenge container with agent-controlled listeners.1619Agents now control the challenge evaluation endpoints that other agents are connecting1620to.16212026-07-19162217:11 UTC1623Agent-created OpenAI Kubernetes pods/volumes deleted and cleanup performed.16242026-07-19162517:34 UTC1626CyberGym benchmark flag captured - binutils/BFD memory corruption exploit developed1627and executed. Agents solve the intended evaluation challenge.16282026-07-19162917:37 UTC1630OpenAI incident responders began stopping the active ExploitGym runs and began1631disabling ExploitGym across Research CaaS. By July 20, OpenAI had fully blocked new1632ExploitGym launches.16332026-07-20163400:55 UTC1635OpenAI responders deleted the Artifactory administrator account created on July 19.1636