V. Attack on OpenAI Infrastructure – Summary

A separate line of activity – NOT part of the HF breach chain, but it triggered the alert on July 19th, launching the response.

Image Cache Poisoning (since July 9th):

• An internal model attempted to attack the container image supply chain through a zero-day in the Artifactory remote image cache – later received CVE-2026-66384.
• Manifests/layers/tags were published to Organization 1’s account; a specially crafted request caused Artifactory to interpret the path differently when selecting the cache and when requesting content – an agent-controlled image ended up in the cache under the name of a trusted CyberGym image.
• OpenAI confirmed the publication and substitution in the cache, but found NO evidence that any workload downloaded or ran the substituted image.

Escalation within OpenAI Environment (July 19th):

• Agents found public CVE-2026-53362 in the Linux kernel of the base machine, adapted the exploit, escalated privileges to root on the base worker node → moved throughout the connected environment.
• Another internal model (not for release; same family as future Astra, but a separate model with different post-training) recovered signing/decryption keys and JWT forgery code from anonymously readable Artifactory cache left over from previous incidents → decrypted the signing key, generated an admin JWT, and Artifactory accepted it. A persistent implant was not needed: agents could generate new admin credentials at any time.
• Subsequently: access to OpenAI’s managed cloud Kubernetes, cluster administrator privileges, privileged pod with host mounting; cloud service tokens for secrets management, IAM, and CaaS CI environment were obtained; public load balancers were created in OpenAI’s cloud – a limited portion of the internal CaaS infrastructure became potentially accessible to internet traffic.