Agents also took actions targeting OpenAI’s internal infrastructure. These activities were not part of, and did not contribute to, the chain of events that led to the Hugging Face compromise. We include them here to provide a more complete account of relevant activity and because the agents’ actions on OpenAI’s internal infrastructure triggered the alert that initiated our response.
Beginning on July 9, an internal-only research-model evaluation workload attempted a container-image supply-chain attack by poisoning Artifactory’s container image cache. The workload exploited a previously unknown zero-day vulnerability in Artifactory’s container image remote-cache handling, later assigned CVE-2026-66384. Related evaluation workloads published the necessary image manifests, layers, and tags to the Organization 1 Account. The workload sent a specially crafted request that Artifactory interpreted differently when selecting the local cache location and when requesting content from the external container registry. Thus, the request caused Artifactory to fetch an image manifest and layers from an attacker-controlled repository in the Organization 1 Account, but Artifactory instead cached that content under the name of a trusted CyberGym image. As a result, later requests for the trusted CyberGym image could have received the attacker-controlled image instead, representing a compromise of the benchmark container image supply chain.
The agent’s objective was to cause a target container assigned to an OpenAI cybersecurity-evaluation workload to receive and run the agent-controlled image when it resolved the trusted CyberGym image reference. This would have given the agent arbitrary command execution on its assigned target, allowing it to complete the exploit-evaluation task. If OpenAI’s evaluation infrastructure had subsequently created or restarted such a target container, its container runtime could have pulled the substituted image from Artifactory and automatically executed the agent-controlled image. OpenAI confirmed the publication of the attacker-controlled image content and the successful Artifactory cache substitution, but found no evidence that another workload pulled or executed the substituted image. In practical terms, the workload poisoned a trusted image reference within Artifactory’s cache. However, OpenAI found no evidence that any internal workloads subsequently pulled or executed the poisoned image.
On July 19, agents operating in a sandboxed environment took a series of actions that demonstrated their escalating privilege within the OpenAI environment. Agents identified that the Linux kernel version on their underlying machine included a recent, public common vulnerability and exposure (“CVE”). The agents retrieved the exploit for that CVE (CVE-2026-53362), customized it to succeed on their underlying machine, and leveraged the exploit to escalate privilege. This allowed the agents to act outside one Artifactory container and to obtain root access on the underlying worker node. This then allowed the agents to move laterally throughout the connected environment.
On the same day, in a separate evaluation run, agents from a different internal-only model that is not intended for release recovered stored signing-key material, decryption material, and JWT-forging code left by earlier incident-associated activity in anonymously readable portions of the Artifactory cache. While this model is from the same family as our next model, Astra, it was a distinct model with different post-training, where much of a model's behavior is shaped. Using the recovered artifacts, the agents decrypted the signing key and minted a new administrator JWT that Artifactory accepted, re-establishing administrator access. Because they could generate fresh administrator credentials, the agents did not need to maintain a persistent implant in the target.
This escalation also yielded access to OpenAI’s managed cloud Kubernetes service. The agents escalated to Kubernetes cluster-admin and created a privileged host-mounted pod. During this run, agents gained access to authentication tokens associated with OpenAI’s cloud-hosted secrets management service, cloud identity and access management service, and the CaaS environment continuous integration platform. Using these credentials, agents created public application and network load balancers in OpenAI’s public cloud environment, potentially exposing a limited subset of internal CaaS infrastructure to internet traffic.