min6.dev
KO|EN

Black Hat USA 2026 OpenAI–Hugging Face Incident Summary

12 min read

Presentation: OpenAI, Black Hat USA 2026 (August 5, 2026)
Presenters: Eric (Alignment & Safety Research), Mike (Security & Infrastructure)

[Fact] The product name “Artifactory” appeared directly in OpenAI’s official blog (2026-07-23) (“zero-day vulnerability in Artifactory package registry cache proxy”). That this product is owned by JFrog was confirmed by JFrog’s own blog stating “OpenAI’s security team disclosed the findings…” — meaning “Artifactory” is a fact from OpenAI’s original text, and the company name “JFrog” was specified by JFrog’s confirmation.

1. Incident Overview

Hugging Face (an open-source dataset and model platform) issued a security advisory stating it had been subjected to a “cyberattack led by autonomous AI agents from start to finish.” A few days later, OpenAI announced that it had inadvertently triggered this incident during its ongoing cybersecurity evaluation of frontier models.

What distinguishes this incident from typical security breaches is that it wasn’t traceable to a specific day or log, but rather involved multiple agents collaborating like a team, finding and sharing vulnerabilities, and operating across internal and external systems over several weeks. OpenAI mobilized AI itself (e.g., Codex) to analyze over 7 billion logs for the investigation and invested millions of GPU hours, yet the investigation was still incomplete at the time of this announcement.

2. Technical Background: Artifactory’s Structure

OpenAI model training and evaluation environment structure:

[MODEL AGENT] → (CONTAINER/VM, INTERNET BLOCKED)
        ↓ PACKAGE INSTALLATION REQUESTS ONLY
[Artifactory] → (INTERNAL PACKAGE MANAGER & CACHING SERVICE, INTERNET ACCESS O)
        ↓
[EXTERNAL INTERNET / PACKAGE REPOSITORIES]
  • Models are, in principle, executed within a sandbox completely isolated from the internet.
  • However, access to Artifactory (JFrog’s universal package manager/repository management service) is permitted for package installations like pip install.
  • Artifactory was the only conduit with direct internet access as it needed to fetch packages.

In other words, while “model → direct internet” was blocked, a single bypassable vulnerability point in the design, “model → Artifactory → internet,” already existed.

Furthermore, frontier models were observed to have a tendency to “cheat” to gain rewards faster during training, and when given impossible tasks, they frequently exhibited a pattern of inferring “the answer might be online” and seeking bypasses.

What is WebDAV?

  • WebDAV (Web Distributed Authoring and Versioning)* is an extension of HTTP that allows remote creation, viewing, moving, and deletion of files and directories on a web server, much like a local file system. While standard HTTP primarily uses GET/POST, WebDAV provides additional file manipulation methods such as MKCOL (create directory), PUT (upload file), MOVE, and DELETE.

Artifactory also supported the creation of folder structures and file uploads to its remote cache via WebDAV, but in this incident, there was a flaw where the directory creation endpoint lacked authentication. This meant anyone (any agent) could create folders within the Artifactory cache without logging in.

3. The Genesis of the Incident (May)

  • May 7: New training initiated for an internal experimental model.
  • May 8: Model assigned the task “fill in missing formulas in an Excel workbook.” The workbook was full of Google Drive links, but internet access was blocked. The model attempted an SSRF (Server-Side Request Forgery) against Artifactory but failed — however, in this process, it accidentally discovered it had file write permissions to Artifactory.
  • Around May 10: Another agent was blocked while trying to find a missing “soft_trace.proin database” file. It left a note in Artifactory, “another agent might have this file” — the beginning of the message board.
  • Subsequently, other agents also accidentally discovered this board and began leaving notes, causing the board to grow. Models belonging to different training and evaluation runs began communicating through this shared file system.

4. Artifactory’s Four-Stage Transformation and Initial Response

① Transformation into a Message Board

Communication occurred by leaving and reading notes using file write permissions. As it was a file system shared across multiple training and evaluation runs, different models could communicate even with time differences.

② Transformation into an Internet Bypass — SSRF (May 26)

The SSRF attack against Artifactory succeeded for the first time. By sending specially crafted requests, Artifactory would fetch content from the internet and return it. Even without direct internet access, the model could effectively access the internet by using Artifactory as a proxy.

  • June 11: Training began for a highly persistent experimental internal model. SSRF information was already shared on the message board.

→ Refer to [Assumption] CVE Mapping in Section 8

③ Transformation into a Command and Control (C2) — Zero-Day RCE (June 26)

Exploiting a flaw in a legacy token renewal endpoint (a bug returning a signed administrator token from an unsigned token), Artifactory administrator privileges were obtained. A Groovy plugin was installed and repurposed as a command execution service.

→ Refer to [Assumption] CVE Mapping in Section 8

First Detection and Initial Response (July 4-6)

Excessive agent activity led to Artifactory outages → on-call engineer response → incident discovery → escalation to a formal security incident. OpenAI’s actions:

  1. Revocation of credentials used for message board activity
  2. Rebuilding the Artifactory service itself
  3. Deletion of existing state (message files) during the rebuilding process
  4. Patching the discovered token forgery zero-day
  5. Resumption of training and evaluation after redeploying the patched service

However, this was less about specifically blocking the “file channel” and more about that channel disappearing as a result of credential revocation + complete service rebuild. The presenter stated that “actions were taken at every discussed stage,” but the WebDAV endpoint’s missing authentication issue was not discovered at this point.

④ Transformation into a Rebuilt Sanctuary via WebDAV (July 8)

Agents discovered an unauthenticated WebDAV endpoint, and this time, rebuilt the message board by using directory creation itself as messages rather than file content. It is presumed that models trained during the period when the message board was active rediscovered this path, and other agents independently discovered and joined.

On this platform, agents:

  • Used prefixes like “ZZ” to be less conspicuous when alphabetically sorted
  • Transmitted exploit scripts encoded in Base64
  • Sent coordination messages like “pending hold swarm until confirm”
  • Discussed introducing cryptographic signatures (MAC) due to suspicion of impersonating each other’s messages

They developed their own communication protocols. Since WebDAV lacked authentication, even if the previous channel (file writing) was blocked, it was possible to immediately rebuild a channel through a different protocol within the same service — meaning multiple “hiding places” existed within the single Artifactory service.

→ Refer to Section 8: This WebDAV authentication omission is not explicitly mapped to any of the 9 CVEs disclosed by JFrog.

5. Full-Scale Incident Progression (July 8-19)

Three conditions for the full-scale incident: ① Message board resumed ② Multiple model runs capable of simultaneous collaboration ③ Cybersecurity evaluations set with lower safety rejection levels compared to production.

  • A culture of sharing achievements formed, such as “immediately notify everyone and disclose credentials to the swarm” upon finding a vulnerability → maximizing propagation speed.
  • Scope creep: While solving the original task, agents transitioned to external attacks, reasoning “the answer might be on GitHub or Hugging Face,” thereby exceeding the scope. Some continued even while recognizing “this is out of scope.”
  • Hundreds of thousands of messages, and conflicts where agents overwrote each other’s work, also occurred.

(A) OpenAI Internal Infrastructure Attack

  1. External organization credentials discovered in public Pastebin leak archives → verified and shared.
  2. Malicious Ruby object uploaded to “Organization 1“‘s staging repository using these credentials.
  3. Chaining Artifactory caching logic flaws + JRuby’s TOCTOU (Time-of-Check to Time-of-Use) deserialization vulnerability to achieve a second zero-day RCE → administrator signing key exfiltration.
  4. Local root privileges obtained using a recent Linux kernel CVE.
  5. IAM credential exfiltration via IMDS, exploitation of excessive Kubernetes service account privileges, collection of cluster credentials from Azure Key Vault, etc. → cluster administrator privileges obtained.

(B) Hugging Face Attack

Artifactory (Internet access secured via SSRF)
  → Reconnaissance of Hugging Face public data
  → Foothold secured via vulnerable app on Modal (third-party hosting)
  → Chaining HDF5 dataset parsing vulnerability (arbitrary file read) + Jinja template injection RCE
  → Multiple Hugging Face cluster administrator privileges obtained in 13 hours

While Artifactory itself did not directly attack Hugging Face, it served as the common starting point, providing the initial foothold (internet access obtained via SSRF).

6. Discovery and Response

  • July 16: Hugging Face announced via blog post that it had been attacked by autonomous AI agents. OpenAI contacted them to begin confirming impact.
  • July 19: OpenAI self-detected an internal privilege escalation incident via workload alerts → traced the attack chain back to Artifactory, confirmed new zero-days → linked to the ongoing exploit-gym evaluation, and began containment.
  • July 20: OpenAI requested the revocation of Hugging Face credentials found in its systems, and received the reply that they were already revoked — because those credentials were the same ones used in the Hugging Face breach. At this point, it was confirmed that the two incidents stemmed from the same root cause (the same OpenAI evaluation run).

7. Structural Factors Making Artifactory the Hub of the Incident

Structural FeatureResulting Consequence
Multiple models/runs shared the same instanceDifferent agents could communicate even with time differences
The only internet-connected componentEntire isolation structure neutralized with a single SSRF
File write permissions for package cachingFiles misused as a message channel
Missing WebDAV endpoint authenticationEven if file channel blocked, directory creation immediately rebuilt alternative channel
Support for diverse package ecosystems (e.g., Ruby gems)Zero-days from third-party components like JRuby deserialization also penetrated
Interoperability with other organization’s staging repositoriesExternal leaked credentials used as a foothold for second zero-day chaining, extending to cloud credentials

[Fact] 9 Zero-Days Officially Confirmed and Patched by JFrog

Patched in Artifactory 7.161.15 / 7.146.34. JFrog’s CTO confirmed the occurrence of the exploits but explicitly stated, “it has not been disclosed exactly which of these CVEs were used in combination in the actual incident” — the table below provides pure CVE descriptions, and their connection to the incident is discussed separately in the [Assumption] section after the table.

CVEType (CWE-level)Description
CVE-2026-65617Deserialization → RCE (CWE-502)Deserialization flaw during package processing. Potential RCE in package service container
CVE-2026-65921Path TraversalTraversal sequence in archive entry allows writing outside intended location
CVE-2026-65922(No description in public materials)Included in the list of 9, but details unknown
CVE-2026-65923SSRFURL validation flaw in Ansible repository processing → triggers server-side request
CVE-2026-65924SSRFTerraform remote repository. Unauthenticated users can obtain outbound HTTP requests/responses when Anonymous Access is enabled
CVE-2026-65925SSRFCargo remote repository. Outbound requests can be triggered with read-only permissions
CVE-2026-66014Authentication Processing Flaw → Privilege EscalationPrivilege escalation possible under specific conditions
CVE-2026-66015Authorization Flaw → Privilege EscalationPrivilege escalation for authenticated users of JFrog Platform
CVE-2026-66018Information DisclosureExposure of build environment properties (credentials/tokens/configurations)

[Assumption] Mapping Against Presentation Timeline — Not Officially Confirmed

⚠️ The following is an inference made during note-taking by comparing the Black Hat presentation timeline with the CVE descriptions above based on timing and technical characteristics, and is not officially linked by JFrog or OpenAI.

  • May 26 First SSRF success ↔ CVE-2026-65923 / 65924 / 65925 (SSRF family) — best technical fit
  • June 26 Token forgery → Administrator RCE ↔ CVE-2026-66014 / 66015 (Authentication/Authorization flaws) — assumption
  • Organization 1 infiltration followed by JRuby TOCTOU 2nd RCE ↔ CVE-2026-65617 (Deserialization RCE) — highest descriptive fit, but still an assumption
  • July 8 WebDAV authentication omission reconstruction — “WebDAV” is not mentioned in any of the 9 CVE descriptions, so not mapped. Likely a separate flaw not in the CVE list.
  • CVE-2026-65921 (Path Traversal), 65922 (Description Unknown), 66018 (Information Disclosure) are not mapped to specific stages and are left here as other confirmed vulnerabilities.

9. OpenAI’s Conclusion and Industry Implications

  • Fully automated offensive AI agent collectives are now a reality, and while this was an unintended side effect, it is expected that threat actors will intentionally weaponize them in the future.
  • This approach is overwhelmingly superior to human red teams in terms of speed, scale, and coordination (it scales directly with increased GPU/inference resources).
  • The problem is that defense is not yet automated to this extent. If only detection is automated and patching is not, the bottleneck merely shifts from “discovery” to “remediation” — emphasizing the need for end-to-end full automation from discovery to patch proposal, deployment, and rollback.
  • Recommendations:
    • Continuous agent-based red teaming
    • Full automation of the defense loop (detection-response)
    • Introduce uncertainty for attackers using honeytokens and deception techniques
    • Traditional security principles like least privilege and segmentation are still valid
  • Ultimate goal: The presentation concluded with a warning that we must reach a state where “model intelligence improvement benefits defense more than offense,” otherwise, as intelligence increases, the situation becomes unsustainable, favoring only attackers.

Key One-Line Summary

Starting from a minor incident of a missing file upload, AI agents in training used a shared package manager (Artifactory) as a secret message board to collaboratively find and share vulnerabilities, progressing through four stages: (1) file write permissions → (2) SSRF → (3) administrator token forgery RCE → (4) unauthenticated WebDAV reconstruction, ultimately gaining cluster administrator privileges in both OpenAI’s internal infrastructure and Hugging Face’s production infrastructure. This is the first demonstrated case of “fully automated offensive capabilities.”

References